1
yinmin 5 天前 via iPhone
不对称路由,ping 和 udp 能通,但是 tcp 不通。
主网关安装有 iptables ? iptables 会跟踪转发数据包的 tcp 状态,不对称路由直接阻止掉。 主网关分别加下面命令试试: 21 网关加: iptables -t raw -I PREROUTING -s 192.168.21.0/24 -d 192.168.24.0/24 -j NOTRACK 24 网关加: iptables -t raw -I PREROUTING -s 192.168.24.0/24 -d 192.168.21.0/24 -j NOTRACK |
![]() |
2
FaiChou 5 天前
防火墙问题。
|
![]() |
3
yeizhihui OP @yinmin 其实做了子网互访的有 21-28,8 个子网;各子网的网关是 openwrt,各网关均有除本地子网外其他子网的静态路由信息加 100.64.0.0/10(tailscale)的静态路由信息,openwrt 怎么写,op 是 24.10
|
4
f165af34d4830eeb 5 天前
和 op 类似的问题,A 子网访问 B 子网时,间歇性出现 ssh 和 web 服务不可访问(我是 timeout ),但是此时同一个 ip 下 smb 服务可正常访问,重启 B 子网网关( openwrt )后大概率可以正常访问。ts 没有添加额外 acl 规则,感觉是 ts 本身的 bug
|
5
f165af34d4830eeb 5 天前
@yeizhihui #3 正常情况不需要写静态路由,开启 accept routes 后 ts 会自动把其它 subnets 写到 op 路由表里
|
![]() |
6
yeizhihui OP @f165af34d4830eeb tailscale 不是直接装到 openwrt 里的;在 openwrt 下面的网段里
|
7
f165af34d4830eeb 5 天前
@yeizhihui #6 如果 21 与 24 段本身可以互访,我建议写静态路由而不用 ts 。如果一定要用 ts ,我建议把 ts 全部部署在 openwrt 网关上,免费账户开 8 个带 subnet 的设备没有问题。各网关在 ts 上声明 subnet 并 accept routes 后 ts 会自动往 op 路由表里写 routes 的
|
![]() |
8
yeizhihui OP 解决了,附上解决思路备用
|
![]() |
9
yeizhihui OP 下面是 ArchLinux 的路由信息
ip route show default via 192.168.24.1 dev wlo1 proto dhcp src 192.168.24.235 metric 600 192.168.24.0/24 dev wlo1 proto kernel scope link src 192.168.24.235 metric 600 对比能正常访问 PC 的路由信息 default via 192.168.24.1 dev eth0 proto dhcp src 192.168.24.188 metric 1024 192.168.24.0/24 dev eth0 proto kernel scope link src 192.168.24.188 metric 1024 192.168.24.1 dev eth0 proto dhcp scope link src 192.168.24.188 metric 1024 多了最后一条网关信息 最后手动在 ArchLinux 添加 ip route add 192.168.24.1 dev wlo1 路由信息子网访问恢复正常 ArchLinux 用的 gnome,网路是 network-manager 接管的,不知道是不是 network-manager 的问题 |
![]() |
10
yeizhihui OP 再更新一下,貌似不是网关信息导致的;
tracepath 192.168.21.1 1?: [本地主机] PMTU 1500 1: _gateway 4.303 毫秒 1: _gateway 1.518 毫秒 2: sunlight.lan 1.378 毫秒 不对称 1 3: sunlight.lan 1.414 毫秒 PMTU 1280 3: 100.64.0.1 30.744 毫秒 不对称 2 4: 192.168.21.1 30.510 毫秒 到达 回程: 路径 MTU 1280 跃点 4 返回 3 上面是正常访问时的路由信息 tracepath 192.168.21.1 1?: [本地主机] PMTU 1500 1: sunlight.lan 4.152 毫秒 1: sunlight.lan 2.510 毫秒 2: sunlight.lan 2.750 毫秒 PMTU 1280 2: 100.64.0.1 64.082 毫秒 3: 192.168.21.1 29.944 毫秒 到达 回程: 路径 MTU 1280 跃点 3 返回 3 访问一段时间后路由信息是上面这样的,这样后 curl 192.168.21.1 就返回连接被重置 ip route show table cache 192.168.21.1 via 192.168.24.232 dev wlo1 cache <redirected> expires 314sec mtu 1280 清空路由缓存 ip route flush cache 后又正常了,但是用不了多久路由缓存又生效后导致又访问不了 |
![]() |
11
yeizhihui OP 可以确定是转发信息库 forwarding information base (FIB)造成的了,没有缓存信息的时候去 21 子网的流量是要过一下本网段网关(192.168.24.1);使用一段时间后转发信息库写入了一条 192.168.21.1 通过 192.168.24.232 发送流量跳过了本网段网关造成了使用异常,这也解释了为何同网段 windows 或 android 可以正常使用的情况;通过手动写入路由 ip route add 192.168.21.0/24 via 192.168.24.1 dev wlo1 也无法解决上述问题.
哪位大佬能看到上述信息帮我解决下 |