内网被运营商非法 dhcp 服务器干扰大概找到原因了

24 天前
 RoyCho

我家宽带五六年前刚装的时候,就偶尔出现奇怪的 DHCP 干扰:电脑会检测到一个名称为 3g 的 DHCP 服务器,租约长达 365 天,服务器地址是 192.168.1.254 。 这个 DHCP 服务器地址跟名称看起来不像普通家用设备,也 ping 不通,但会影响内网设备的正常 DHCP 分配。

当时我开启 OpenWrt 的 强制 DHCP 服务器 功能后,情况改善了很多,但偶尔仍会被干扰。多年下来,家里的 NAS 、交换机、光猫、AP 都陆续升级过,但问题依然偶尔出现。

于是我开始怀疑干扰源可能在光猫之外。通过排查发现:

首先我家没有 192.168.1.x 的内网网段,192.168.1.254 无法 ping 通,但同一网段的其他 IP 可以 ping 通。

Traceroute 显示访问 192.168.1.x 网段需要经过两个运营商的公网 IP 。

这让我怀疑干扰源很可能是 运营商设备。进一步排查发现,OpenWrt 默认防火墙中有一条 Allow-DHCP-Renew 规则,这条规则会允许 DHCP 报文透传到内网。

在 PPPoE 拨号的情况下,其实根本不需要这条规则。如果运营商存在非法 DHCP 服务器,这条规则就会让干扰 DHCP 直接透传到内网。

我关闭了这条规则后,内网 DHCP 干扰暂时消失。 初步判断,这可能就是多年来偶尔遇到的“神秘 DHCP 干扰”的根源。 我会继续观察,如果情况稳定,也可以作为给同样使用 OpenWrt + PPPoE 用户的经验分享。

5688 次点击
所在节点    宽带症候群
74 条回复
infinet
24 天前
不应该啊。设备的 DHCP 请求在内网广播,不会传到上级。而且 DHCP 服务器的应答是发给请求设备的 MAC ,不能跨过 openwrt 。更新 lease 的时侯,DHCP 服务器直接回答给请求设备的 IP ,也不会出现这种干扰。
RoyCho
24 天前
@infinet 我也搞不懂,只能暂时再观察下,内网实在没有这种机器了,抓包看了下也不是很懂。

Frame 2: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits) on interface \Device\NPF_{E5D10228-16CC-4B04-9F8B-5611DC6D238B}, id 0
Section number: 1
Interface id: 0 (\Device\NPF_{E5D10228-16CC-4B04-9F8B-5611DC6D238B})
Encapsulation type: Ethernet (1)
Arrival Time: Jun 18, 2024 22:57:34.085063000 中国标准时间
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1718722654.085063000 seconds
[Time delta from previous captured frame: 0.000749000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000749000 seconds]
Frame Number: 2
Frame Length: 314 bytes (2512 bits)
Capture Length: 314 bytes (2512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:dhcp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: 00:ff:e6:d1:02:28 (00:ff:e6:d1:02:28), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: 00:ff:e6:d1:02:28 (00:ff:e6:d1:02:28)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.254, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 300
Identification: 0x0000 (0)
000. .... = Flags: 0x0
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 16
Protocol: UDP (17)
Header Checksum: 0xe71b [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.254
Destination Address: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Source Port: 67
Destination Port: 68
Length: 280
Checksum: 0xc2c7 [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
[Timestamps]
UDP payload (272 bytes)
Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x24d6d8f2
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.1.102
Next server IP address: 192.168.1.254
Relay agent IP address: 0.0.0.0
Client MAC address: 00:ff:e5:d1:02:28 (00:ff:e5:d1:02:28)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Length: 1
DHCP: Offer (2)
Option: (54) DHCP Server Identifier (192.168.1.254)
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (31536000s) 365 days
Option: (1) Subnet Mask (255.255.255.0)
Length: 4
Subnet Mask: 255.255.255.0
Option: (15) Domain Name
Length: 2
Domain Name: 3G
Option: (6) Domain Name Server
Length: 4
Domain Name Server: 192.168.1.10
Option: (255) End

下面这个是另一个我觉得跟这个问题相关的包
Frame 657: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{10FB3DBC-1CF5-41F2-8653-8C8FF89365B8}, id 0
Section number: 1
Interface id: 0 (\Device\NPF_{10FB3DBC-1CF5-41F2-8653-8C8FF89365B8})
Interface name: \Device\NPF_{10FB3DBC-1CF5-41F2-8653-8C8FF89365B8}
Interface description: WLAN 2
Encapsulation type: Ethernet (1)
Arrival Time: Aug 24, 2025 12:54:20.430748000 中国标准时间
UTC Arrival Time: Aug 24, 2025 04:54:20.430748000 UTC
Epoch Arrival Time: 1756011260.430748000
[Time shift for this packet: 0.000000000 seconds]
[Time delta from previous captured frame: 0.011937000 seconds]
[Time delta from previous displayed frame: 0.011937000 seconds]
[Time since reference or first frame: 16.853005000 seconds]
Frame Number: 657
Frame Length: 60 bytes (480 bits)
Capture Length: 60 bytes (480 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:arp]
[Coloring Rule Name: ARP]
[Coloring Rule String: arp]
Ethernet II, Src: 00:ae:4f:44:87:0f (00:ae:4f:44:87:0f), Dst: CloudNetwork_e5:14:c3 (4c:82:a9:e5:14:c3)
Destination: CloudNetwork_e5:14:c3 (4c:82:a9:e5:14:c3)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: 00:ae:4f:44:87:0f (00:ae:4f:44:87:0f)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: ARP (0x0806)
[Stream index: 5]
Padding: 000000000000000000000000000000000000
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: 00:ae:4f:44:87:0f (00:ae:4f:44:87:0f)
Sender IP address: 172.31.80.69
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 192.168.1.102


我的设备刚刚被分配到 192.168.1.102 这个非法地址,而且我也不清楚 172.31.80.69 这个 ip 是什么,看起来像运营商设备 ip
1423
24 天前
基础不牢,地动山摇
fuzzsh
24 天前
不知道你有没改过缺省规则,WAN 侧的 DHCP 流量是进不了 LAN 侧,它的策略只允许 WAN>LOCAL
我一直用官方构建的 openwrt ,即使 modem 开 dhcp ,openwrt 使用 pppoe 也不会获得任何 WAN 侧的 IP
RoyCho
24 天前
@fuzzsh 我应该没动过相关的默认规则,会不会是路由器本机 DHCP 服务( dnsmasq 或 odhcpd ),对 WAN 接口收到的 DHCP 包进行了处理,路由器可能错误地把它当作合法来源,再通过 DHCP 服务给 LAN 客户端回应。也就是说,不是 WAN → LAN 的防火墙转发,而是 路由器自己接收到 WAN DHCP 后,作为 DHCP 服务器响应 LAN 。
fuzzsh
24 天前
…… 明显内网设备搞鬼,任何 relay 都不能保持原始包发送到 endpoint ,即使他要 relay ,他必需改写包,你帖的信息,mac 都没改写,完全是内网发出
fuzzsh
24 天前
有 bug 早就开 issue 了,openwrt 又不是小众项目
PrinceofInj
24 天前
运营商有 DHCP 很正常呀,甚至光猫都有 DHCP 的服务,要是 openwrt 真有这个问题的话,肯定会大规模出现,而不是就你遇到了。你这种现象很像是设置错误,LAN 接口的设置不会设置成 DHCP 客户端了吧?
RoyCho
24 天前
@fuzzsh 家里的可以设备这些年都换了个遍,实在是不懂还有什么设备了,或者有什么排查的方法吗?我贴的抓包信息能看出什么关键信息吗
kome
24 天前
是不是开了 DHCP relay?
我对比了我这的 DHCP offer 包, 设备是 ikuai 软路由, DHCP 设置部分是默认设置.
在 DHCP-> option, 我这的是 53,1,3,6,51,54,252,255, 跟你的包有差别.
在 DHCP-> next server ip address 部分, 我这是 0.0.0.0, 而且 DHCP 本身就是广播包, 不需要单播至某个 IP 地址, 估计是你的 DHCP 服务器设置了 DHCP relay, 查一查 DHCP 设置吧.
RoyCho
24 天前
@kome 没有开 DHCP relay 呢,问了 chatgpt 我这种情况确实可能是运营商的 dhcp 服务器干扰的,只能先关了 Allow-DHCP-Renew 再看看,家里的设备能排查的都排查了,唯一一个这么多年没换过的 tp-link 的无线摄像头,我觉得可能性不大,也确认过没有人私接设备到我的网络里,这种 192.168.1.254 的 dhcp 服务器地址,我觉得更像会是运营商的设置,加上服务器名是 3g ,更可疑了
kome
24 天前
@RoyCho 多问一嘴, 你是如何配置 DHCP 和 DHCPv6 的, 如果是直接编辑的配置文件, 会不会是某个```DHCPv6 'relay'```被写成了```DHCP 'relay'```
究其原因, 应该还是配置了 DHCP relay, 或者 DHCP 服务器未能正常工作. 广播无法跨局域网传播, 运营商设备也不知道你的局域网用的什么网段, 他也没有到你的局域网网段的路由.
xqzr
24 天前
DHCP 首包是广播,“二层隔离”正确的情况下,不会超越路由器。
你的 DHCP “发现”(请求)可能误入 IPTV 专网
RoyCho
24 天前
@kome DHCP 都是默认配置的,装过 smartdns 我想跟这个也没关系,我自己的内网是 192.168.30.x ,家里没有 192.168.1.x 的网段,却可以 ping 通 192.168.1.x 网段,之后发现 192.168.1.x ping 的网段延迟跟 Tranceroute 都表明是一个光猫外的设备,192.168.1.x 网段是跨了两个运营商公网 ip 到达的
xqzr
24 天前
> 192.168.1.x ping 的网段延迟跟 Tranceroute

发一下
niukuo
24 天前
tcpdump 一下就可以了
RoyCho
24 天前
@xqzr
traceroute to 192.168.1.33 (192.168.1.33), 30 hops max, 46 byte packets
1 221.178.219.99 1.212 ms
2 112.0.184.77 2.082 ms
3 192.168.1.33 3.265 ms
RoyCho
24 天前
@niukuo 抓包吗?可是大部分时候都是正常的,是不是得有干扰的时候才能抓到有效的包?
RoyCho
24 天前
@xqzr traceroute to 192.168.1.113 (192.168.1.113), 30 hops max, 46 byte packets
1 221.178.219.99 1.554 ms
2 120.195.79.193 1.869 ms
3 192.168.1.113 3.570 ms
不同的 ipTranceroute 还稍有不同...
ziseyinzi
24 天前
ping 不通这个事也挺像运营商设备。有些运营商设备会禁掉一切 ICMP 包。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1154624

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX