☰

为什么默认网关更改为备份电路时 DNS 解析会失败？

tag-icon • tag-icon networking server dns resolv.conf
为什么默认网关更改为备份电路时 DNS 解析会失败？

我们遇到了一个奇怪的问题，希望有人能帮上忙。我们有一栋楼，里面有一条光纤线路和一条备用康卡斯特线路（同轴电缆）。

系统设置如下：

光纤 NID（cat6 电缆至交换机）Comcast（cat6 电缆至交换机）| 非托管交换机 | Unbuntu Linux Box 作为路由器（从 WAN 端口到交换机的 cat6 电缆）| LAN 端口到光纤 OLT | 4 个光纤 GPON 端口连接到许多 ONT

我们编写了一个 bash 脚本，它会每分钟检查一次主网关（光纤电路）是否启动，如果没有，它会将默认网关更改为 Comcast 路由器 10.1.10.1。一旦主网关恢复，它将自动切换回主网关。

我们在许多建筑物中都安装了相同的装置，并且它运行良好，但在几栋建筑物中，一旦默认网关切换到备份康卡斯特电路，DNS 在大多数情况下根本无法解析，有时会在大多数浏览器已经超时的 4 秒后解析。

奇怪的是，如果我们断开连接到 Linux 盒式路由器 LAN 端口的 OLT 电缆，DNS 就可以从 Linux 盒式路由器的命令行和插入 Linux 盒式路由器 LAN 端口的笔记本电脑上正常解析。

如果我们将笔记本电脑插入 OLT 上的 rj45 端口，奇怪的是它会获得一个 IPV6 地址（Comcast，即使我们先拔掉 Comcast 路由器）。从这里开始，如果我们断开光纤 GPON 端口，将居民从方程中移除，备份 Comcast 就会正确解析，一切正常，我们不会获得 ipv6 地址（我们只在局域网端使用 ipv4）。重新插入居民的光纤 GPON 端口，DNS 立即不再解析。

OLT 设置了端口隔离，因此居民无法“看到”彼此。我们尝试设置 ACL 来阻止所有 IPv6 流量以及不在 172.16.0.0/16 子网上的所有私有 ipv4，但没有成功。

/etc/resolv.conf

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 1.1.1.1

无论是在备用电路还是主电路上，/etc/resolv.conf 都是相同的。

/etc/网络/接口

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback


#The LAN (right port) network interface
allow-hotplug enp2s0
iface enp2s0 inet static
    address 172.16.1.1
    netmask 255.255.0.0

######## END LAN SETUP ####################################################

############ MAIN WAN SETUP ################################################
#WAN
allow-hotplug enp3s0
iface enp3s0 inet static
    address xxx.xxx.xxx.xxx
    netmask 255.255.255.252
    gateway xxx.xxx.xxx.xxx
    dns-nameservers 8.8.8.8 8.8.4.4 1.1.1.1

########### END MAIN WAN SETUP
#WAN backup circuit
allow-hotplug enp3s0
iface enp3s0 inet dhcp
    dns-nameservers 8.8.8.8 8.8.4.4 1.1.1.1

####### END BACKUP WAN SETUP FAILOVER ###################################

我们进行了 tcpdump，发现 LAN 端有多个“Comcast”调制解调器/路由器（我们查看了 mac 地址）。似乎有些居民拥有 Comcast 互联网，并将我们的 ONT 插入他们的 Comcast 路由器，并且它正在泄漏到系统中。如果我设置静态 IP 10.0.0.xx 并插入 ONT rj45 端口，我可以 ping 并浏览到某人的 Comcast 调制解调器/路由器。一旦我们设置了 ACL，它现在就被阻止了，但我们仍然遇到同样的问题。

总而言之，似乎有一些东西（可能是居民康卡斯特调制解调器/路由器）来自一个或多个居民 ONT，干扰了 DNS 解析，但只有当我们的系统将默认网关切换到我们的康卡斯特备用路由器时才会发生这种情况。重申一下，这种情况只发生在许多具有相同设置的建筑物中的两栋。在其他建筑物中，我们似乎没有看到任何来自居民的“康卡斯特调制解调器/路由器”被错误地连接到我们的系统。

有任何想法吗？

答案1

我从事电信行业已经有一段时间了，但我以后会再从事这个行业。

听起来好像您有一个网络环路，或者如您所说，居民造成了泄漏。当 OLT 到路由器的电缆断开时，网络会在备份启动之前找到一条通往互联网的路由。在这种情况下，它会通过居民与他们的康卡斯特路由器的连接找到一条路由。一旦这样建立了一条路由，即使在备份启动时有一条更合适的路由可用，它也不会重置路由器表（可能是因为它认为没有必要）。

这可能是因为路由优先级。

DNS 失败的问题可能是因为此端口无法通过此伪路由使用，或者其优先级太低，数据包会丢失。如果初始 DNS 查找（这里我的知识有点不准确）是通过 UDP 进行的，那么只有当它回退到 TCOP 时，它才能通过。但我真的不确定。

几十年前，我遇到过同样的问题，当时我们发现在一条故障链路上，有人安装了自动连接到外部世界的拨号链路。唯一的问题是，当主链路恢复时，它并没有关闭拨号链路，然后整个公司都通过这个 9.6K 调制解调器进行路由。这花了很长时间才找到，因为没有人会承认他们做了什么。听起来你也有类似的事情。

相关内容