V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yeizhihui
V2EX  ›  宽带症候群

tialscale 子网互访问题

  •  
  •   yeizhihui · 6 天前 via Android · 1052 次点击
    遇到个问题:192.168.21.0/24 与 192.168.24.0/24 两个网段用 tailscale 做了子网互访;并在 21 、24 两个网关写入双方静态路由。

    archlinux 在 24 网段下 ping21 网段任意 ip 都通,但是访问服务的时候就访问不了,例如用 crul 访问某个 http 服务,crul 提示连接被重置;但 24 网段下其余设备( windows ,android )均能正常访问 21 网段的服务。

    archlinux 在 24 网段下 ping21 网段任意 ip 都通,但是访问服务的时候就访问不了。( archlinux 刚开机的时候 crul 192.168.21.1 有反馈,重复 5 次左右后 crul 提示连接被重置)
    12 条回复    2025-03-18 15:39:51 +08:00
    yinmin
        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
    FaiChou
        2
    FaiChou  
       5 天前
    防火墙问题。
    yeizhihui
        3
    yeizhihui  
    OP
       5 天前 via Android
    @yinmin 其实做了子网互访的有 21-28,8 个子网;各子网的网关是 openwrt,各网关均有除本地子网外其他子网的静态路由信息加 100.64.0.0/10(tailscale)的静态路由信息,openwrt 怎么写,op 是 24.10
    f165af34d4830eeb
        4
    f165af34d4830eeb  
       5 天前
    和 op 类似的问题,A 子网访问 B 子网时,间歇性出现 ssh 和 web 服务不可访问(我是 timeout ),但是此时同一个 ip 下 smb 服务可正常访问,重启 B 子网网关( openwrt )后大概率可以正常访问。ts 没有添加额外 acl 规则,感觉是 ts 本身的 bug
    f165af34d4830eeb
        5
    f165af34d4830eeb  
       5 天前
    @yeizhihui #3 正常情况不需要写静态路由,开启 accept routes 后 ts 会自动把其它 subnets 写到 op 路由表里
    yeizhihui
        6
    yeizhihui  
    OP
       5 天前
    @f165af34d4830eeb tailscale 不是直接装到 openwrt 里的;在 openwrt 下面的网段里
    f165af34d4830eeb
        7
    f165af34d4830eeb  
       5 天前
    @yeizhihui #6 如果 21 与 24 段本身可以互访,我建议写静态路由而不用 ts 。如果一定要用 ts ,我建议把 ts 全部部署在 openwrt 网关上,免费账户开 8 个带 subnet 的设备没有问题。各网关在 ts 上声明 subnet 并 accept routes 后 ts 会自动往 op 路由表里写 routes 的
    yeizhihui
        8
    yeizhihui  
    OP
       3 天前
    解决了,附上解决思路备用
    yeizhihui
        9
    yeizhihui  
    OP
       3 天前
    下面是 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 的问题
    yeizhihui
        10
    yeizhihui  
    OP
       3 天前
    再更新一下,貌似不是网关信息导致的;
    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 后又正常了,但是用不了多久路由缓存又生效后导致又访问不了
    yeizhihui
        11
    yeizhihui  
    OP
       3 天前
    可以确定是转发信息库 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 也无法解决上述问题.
    哪位大佬能看到上述信息帮我解决下
    yeizhihui
        12
    yeizhihui  
    OP
       3 天前
    @yinmin tailscale 默认启用了--snat-subnet-routes;在各子网中是没有对方网段的 ip 访问记录的(--snat-subnet-routes (仅限 Linux )禁用源 NAT 。在正常操作中,子网设备会看到来自子网路由器的流量。这简化了路由,但不允许遍历多个网络。通过禁用源 NAT ,终端机器会将原始机器的 LAN IP 地址视为源。 ),所以这个 iptables 的规则应该没用
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1163 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 23:44 · PVG 07:44 · LAX 16:44 · JFK 19:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.