多 WAN CentOS 路由器 - Xfinity 连接是 Xfinicky。所有其他 WAN 连接工作正常

2024-5-16 • tag-icon

多 WAN CentOS 路由器 - Xfinity 连接是 Xfinicky。所有其他 WAN 连接工作正常

这个问题已经让我发疯好几天了。我正在开发一个迷你路由器/VPN 客户端设备的原型，以部署到我们员工的家中。目前，由于家庭情况，我实际上正在另一个州远程工作，并认为现在是这样做的好时机。

该路由器将至少有一个到最终用户的连接（在本例中我的）互联网硬线以及通过 4G/5G 蜂窝连接进行备份。

问题：我有 3 个 WAN 接口（见下文）。其中两个工作完美。 Xfinity 路由器连接有时不接受任何来自我的设备的流量。我始终可以 ping Xfinity 路由器本身。有时重新启动界面（例如ifdown ethwan0 && ifup ethwan1）将使它工作 - 其他时候则不然。一旦它开始工作（即将流量传输到公共互联网），它将无限期地正常工作。

我可能会在其他两个 WAN 连接之间来回失败（使用自定义脚本 - 下面）。一旦我故障转移到 Xfinity 连接，大多数情况下就没有流量通过。（既不是通过我的路由器的 SNAT，也不是来自我的路由器的直接连接。）

在 Xfinity 路由器的管理界面中，它在“离线设备”下列出了我的路由器的 IP/MAC。此时我实际上可以从路由器的接口 ping Xfinity 的 IP。我不确定在这种情况下“离线”是什么意思。

编辑： 我不是 100% 确信，但如果问题出在 Xfinity 设备中：

Technicolor TC8305C
Boot Version: 2.1.8_Technicolor
Core Version: 01.E6.01.22.59
HW Version: 1.5

我有一台白色标签无风扇迷你电脑，带有 4 个 eth 端口和 1 个 wifi 卡。它运行的是 CentOS 7 [请饶过我这个讲座:)] 端口如下（在 udev/rules.d 中重命名）：

ethwan0- Xfinity 电缆调制解调器/路由器（Xfinity 设备是不是在桥接模式 - NAT'd）

ethwan1- T-Mobile 网关设备（也经过 NAT）

ethint - 用户网络的内部连接，可访问 VPN 另一端的系统

ethgst - 用户家人或其他人的访客连接。只能访问互联网。

ethwifi- Verizon 热点（太过分了，但我正在测试）。

请注意，我有 NetworkManager 和 firewalld残疾人我正在使用iptables-services（我有很多其他使用 iptables 脚本的集中式路由器，所以这是为了保持一致性）。 selinux被禁用。

ifcfg-ethwan0:

TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=no
NAME=ethwan1
DEVICE=ethwan1
ONBOOT=yes
IPADDR=192.168.242.12
PREFIX=24

ifcfg-ethwan1:

TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=no
NAME=ethwan0
DEVICE=ethwan0
ONBOOT=yes
IPADDR=192.168.38.1
PREFIX=24

ifcfg-ethwifi:

MODE=Managed
KEY_MGMT=WPA-PSK
TYPE=Wireless
BOOTPROTO=static
DEFROUTE=no
NAME=ethwifi
DEVICE=ethwifi
ONBOOT=yes
IPADDR=192.168.97.245
PREFIX=24

笔记：我省略了 wpa_supplicant 配置（等），因为此连接工作正常并且不是问题。

iptables配置:

*nat
-A POSTROUTING -m state --state RELATED,ESTABLISHED -j ACCEPT
-A POSTROUTING -s 10.38.168.0/24 -d 192.168.0.0/16 -j ACCEPT
-A POSTROUTING -s 10.38.168.0/24 -d 10.0.0.0/8 -j ACCEPT
-A POSTROUTING -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source 192.168.242.12
COMMIT
*filter
:OUTPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -s 10.38.100.0/22 -d 10.38.168.0/24 -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m state --state NEW -s 10.38.168.0/24 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
:INPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 10.38.168.0/24 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

failover-conn.bsh [interface]:

#!/bin/bash

# Arg $1 is the interface name to fail over to (e.g. ethwan0)

declare -A snat_src
declare -A gateway
declare -A cidr

snat_src[ethwan0]="192.168.242.12"
gateway[ethwan0]="192.168.242.1"

snat_src[ethwan1]="192.168.38.1"
gateway[ethwan1]="192.168.38.11"

snat_src[ethwifi]="192.168.97.245"
gateway[ethwifi]="192.168.97.1"

# Should use awk here but this does work.

snat_line_num=`iptables -t nat -nL --line-numbers |grep SNAT |grep "10\.38\.168\.0\/24" |grep -oP "^[0-9]+"`

# This looks foolish but it's in case a malfunction caused more than one rule to be put in place.. it's happened to me before and this overkill can't hurt.

for whatever in 1 2 3; do

        ip route del default

        iptables -t nat -D POSTROUTING -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source ${snat_src[ethwan0]}
        iptables -t nat -D POSTROUTING -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source ${snat_src[ethwan1]}
        iptables -t nat -D POSTROUTING -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source ${snat_src[ethwifi]}

done

ip route add default via ${gateway[$1]} dev $1

iptables -t nat -I POSTROUTING ${snat_line_num} -s 10.38.168.0/24 -m state --state NEW -j SNAT --to-source ${snat_src[$1]}

conntrack -D

# I thought flushing the ARP cache might cause a re-announce to the Xfinity modem and make it play nice.  I tested with/without this and same result.

ip -s -s neigh flush all

# Without the sleep the VPNs timeout a couple of times before connecting anyway.

sleep 10

systemctl restart openvpn@client-REDACTED0
systemctl restart openvpn@client-REDACTED1

以下是说明问题的一系列命令/结果：

./failover-conn.bsh ethwan0

# ping from router or SNAT'd connection to 8.8.8.8 may return one pong then unlimited timeouts, no responses at all, or it will be fully functional.  VPNs may or may not connect after some time; EVEN IF PINGS ARE FAILING CONSTANTLY..???

ifdown ethwan0 && ifup ethwan0

# pings may or may not get responses or timeout depending on the phase of the moon...?

./failover-conn.bsh ethwan1

# Everything works flawlessly.  Can ping from router, from SNAT'd clients, and VPNs connect.  All traffic transits correctly.

./failover-conn.bsh ethwifi

# Everything works flawlessly.  Can ping from router, from SNAT'd clients, and VPNs connect.  All traffic transits correctly.

./failover-conn.bsh ethwan0

# Same as the first time.  May or may not work.

这是我在 Xfinity 路由器上尝试过的：

完全关闭防火墙/IDS（我想也许IDS会被双重NAT惹恼）。
将我的路由器添加为“保留设备”
已验证所有阻止/家长功能均已关闭。
将另一台笔记本电脑直接连接到 Xfinity 设备的 wifi 并保持 ping 开放，以确保在测试路由器时实际设备/互联网连接正常。已经起来了。
将我的路由器的 IP 设置为 DMZ 主机（可能性不大，但？？？？？？利润）
通过硬线将备用笔记本电脑连接到 Xfinity 网关并进行测试/ping。当我的路由器出现故障时，那台笔记本电脑总是工作正常。
重新启动/重启 Xfinity 路由器做恢复连接。（重新启动我的路由器不会。）

在我的路由器上我尝试过：

禁用VPN
禁用 iptables
禁用所有其他接口
更改ifcfg-ethwan0为具有DEFROUTE=yes，GATEWAY=192.168.242.1以便这就像任何“普通”计算机一样
ethwan0物理上和配置上的交换ethwan1。无论连接到哪个端口，Xfinity 设备都不可靠，而 T-Mobile 网关工作正常。
到处交换以太网电缆。

我对此很困惑。我连接到这个奇怪的 Xfinity 设备的所有其他设备都运行良好。只是这台迷你电脑有问题。但正如我所说，迷你计算机与 T-Mo 路由器以及ethint.

我已经完成了故障排除步骤，我希望你们中的一个人遇到类似的问题并找到解决方案。

或者您可能会在我的配置或方法中发现明显的面部手掌错误？我希望就是这样。至少那时我会知道这不是 GiTM。

提前致谢！ -斯科特

相关内容