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

[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 用户的经验分享。

[infinet]

不应该啊。设备的 DHCP 请求在内网广播，不会传到上级。而且 DHCP 服务器的应答是发给请求设备的 MAC ，不能跨过 openwrt 。更新 lease 的时侯，DHCP 服务器直接回答给请求设备的 IP ，也不会出现这种干扰。

[RoyCho]

@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]

基础不牢,地动山摇

[fuzzsh]

不知道你有没改过缺省规则，WAN 侧的 DHCP 流量是进不了 LAN 侧，它的策略只允许 WAN>LOCAL
我一直用官方构建的 openwrt ，即使 modem 开 dhcp ，openwrt 使用 pppoe 也不会获得任何 WAN 侧的 IP

[RoyCho]

@fuzzsh 我应该没动过相关的默认规则，会不会是路由器本机 DHCP 服务（ dnsmasq 或 odhcpd ），对 WAN 接口收到的 DHCP 包进行了处理，路由器可能错误地把它当作合法来源，再通过 DHCP 服务给 LAN 客户端回应。也就是说，不是 WAN → LAN 的防火墙转发，而是 路由器自己接收到 WAN DHCP 后，作为 DHCP 服务器响应 LAN 。

[fuzzsh]

…… 明显内网设备搞鬼，任何 relay 都不能保持原始包发送到 endpoint ，即使他要 relay ，他必需改写包，你帖的信息，mac 都没改写，完全是内网发出

[fuzzsh]

有 bug 早就开 issue 了，openwrt 又不是小众项目

[PrinceofInj]

运营商有 DHCP 很正常呀，甚至光猫都有 DHCP 的服务，要是 openwrt 真有这个问题的话，肯定会大规模出现，而不是就你遇到了。你这种现象很像是设置错误，LAN 接口的设置不会设置成 DHCP 客户端了吧？

[RoyCho]

@fuzzsh 家里的可以设备这些年都换了个遍，实在是不懂还有什么设备了，或者有什么排查的方法吗？我贴的抓包信息能看出什么关键信息吗

[kome]

是不是开了 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]

@kome 没有开 DHCP relay 呢，问了 chatgpt 我这种情况确实可能是运营商的 dhcp 服务器干扰的，只能先关了 Allow-DHCP-Renew 再看看，家里的设备能排查的都排查了，唯一一个这么多年没换过的 tp-link 的无线摄像头，我觉得可能性不大，也确认过没有人私接设备到我的网络里，这种 192.168.1.254 的 dhcp 服务器地址，我觉得更像会是运营商的设置，加上服务器名是 3g ，更可疑了

[kome]

@RoyCho 多问一嘴, 你是如何配置 DHCP 和 DHCPv6 的, 如果是直接编辑的配置文件, 会不会是某个```DHCPv6 'relay'```被写成了```DHCP 'relay'```
究其原因, 应该还是配置了 DHCP relay, 或者 DHCP 服务器未能正常工作. 广播无法跨局域网传播, 运营商设备也不知道你的局域网用的什么网段, 他也没有到你的局域网网段的路由.

[xqzr]

DHCP 首包是广播，“二层隔离”正确的情况下，不会超越路由器。
你的 DHCP “发现”（请求）可能误入 IPTV 专网

[RoyCho]

@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]

> 192.168.1.x ping 的网段延迟跟 Tranceroute

发一下

[niukuo]

tcpdump 一下就可以了

[RoyCho]

@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]

@niukuo 抓包吗？可是大部分时候都是正常的，是不是得有干扰的时候才能抓到有效的包？

[RoyCho]

@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]

ping 不通这个事也挺像运营商设备。有些运营商设备会禁掉一切 ICMP 包。

[thereone]

光猫用的哪个网段？有没有 IPTV 在用？

[RoyCho]

@thereone 光猫是 192.168.12.x 网段，光猫已经换第三个了，不可能是光猫了，前面两个是运营商的，但是同一个牌子，换第二个的时候我还有怀疑，最近我才换了第三方的万兆光猫

[RoyCho]

@thereone 看漏了，补充下有 IPTV ，但移动的 IPTV 好像不用专门 IPTV 口的

[RoyCho]

@ziseyinzi 是吧，正常家用设备都是 192.168.x.1 作为 dhcp 服务器，192.168.1.254 跟服务器名 3g 真的很像运营商设备，加上 ping 不通...

[thereone]

@RoyCho 看下你的 IPTV 盒子获取的 IP 地址是不是 192.168.1.x 这个段的地址，你这个有很大可能是拿到了 IPTV 那边给的地址。

[RoyCho]

@thereone IPTV 跟普通内网设备一样获取内网地址的，我这边 iptv 没有专门的网络

[n2l]

@PrinceofInj 刚搬家新办了条宽带，已经让运营商桥接，最近折腾其他东西发现直接让光猫和电脑相连，电脑被分配了内网地址，我印象中桥接后光猫 DHCP 服务器就应该不起作用了，我找邻居光猫测了下，他的也是桥接，直连并不会被分配 IP ，后来花 50 块咸鱼拿了超密，进去自己家光猫，果然 DHCP 服务器开着，网段也能对的上，但是关了后，直插还是会被分配 ip ，这是不是联通小哥活儿没干利索呢？

[Damn]

@n2l 不是三四块钱么，你这是给了内鬼扎了一针肾上腺素啊。。

[txydhr]

@n2l 正常的，两者没有直接关系，很多光猫都这样。

[Kepy]

@Damn 不是，还要钱？远程让安装的小哥给个不就行了？

[RoyCho]

@n2l 我的光猫 dhcp 已经关掉了，分配的也不是光猫的网段

[RoyCho]

@n2l 你是 openwrt 吗？像我一向关了来自 wan 口的 dhcp 响应看看

[SeeleLu]

@n2l 光猫的 DHCP 不会通过路由器 WAN 口透传到你路由器下面的 LAN 口、Wifi 设备上。

[lcy630409]

你说那个 ping ip 和你获得的 ip 没有关系，你的内网网段不是 192.168.1 你的路由没有 192.168.1 的路由表 就会让他走默认路由出去，只是恰好运营商内部 也有一个这个网段而已

你的调查方向 应该是找局域网内的 dhcp 服务器，怎么探查出来局域网的 dhcp 服务器 自己查一下谷歌 或者 ai ，然后根据查出来的 mac 地址 去找相应的硬件

[lcy630409]

随手谷歌一个 https://www.jb51.net/softs/70677.html
这个 DHCP 探查工具就出来了，查一下 MAC 地址，然后想办法找到这个设备

[keyfunc]

是不是抄过网上关于 IPTV 的配置？

[thereone]

你的 IPTV 配置怎么做的？一般上网 PPPOE 拨号后获取的是点对点三层网络除非你做了 dhcp 中继不然不存在拿到别的 DHCP 配置。大概率是 IPTV 那边搞过来的，光猫 IPTV 认证用的是什么协议 IPOE 还是 PPPOE 还是 IPTV 盒子直接走的 OTT ？

[RoyCho]

@lcy630409 mac 地址找过，上面有贴出来抓包信息，应该是个虚拟 mac 地址

[RoyCho]

@keyfunc 没有，移动的 UPTV 没有专门的线路，就跟普通第三方机顶盒一样用家庭内网 ip 就行了

[RoyCho]

@thereone 移动的 IPTV 没有专门的线路，就跟普通第三方机顶盒一样用家庭内网 ip 就行了

[RoyCho]

@lcy630409 而且正常探查不到，要是能一直探查到通过拔网线也能揪出来了，就很偶尔几个月来这么一下，重新获取就没了

[kome]

网内有没有其他路由器设备，可能是断网之后，这些路由器设备网络不通，DHCP 服务器自启动了。我这的 TPLink 的路由器(做 AP 的)会在某些情况下 DHCP 服务自启动，需要断电重启。

[RoyCho]

@kome 没有哎，之前怀疑过的设备这几年陆续都升级换掉了，一直在用的设备也就剩下个 tp-link 摄像头，洗衣机，空调是一直联网的，最烦的就是干扰不是持续的，不好查，有时候 openvpn 连回家都会被干扰

[thereone]

看下你的 openwrt 的 pppoe 拨号获取的网关是多少，route -n 就可以看到

[RoyCho]

@thereone 网关是 10.24.230.1 的大内网 ip

[thereone]

新建接口抓包吧，看看你的 pppoe 接口会不会回 dhcp 包。具体看图



在已经拨号上去的 pppoe 产生的隧道设备 pppoe-wan 这个设备(你的不一定是这个名称)上面新建一个使用 dhcp 协议的接口让 dhcp 报文在 pppoe 隧道接口内广播看看运营商的 bras 会不会回包，如果回包那就是运营商的 bras 上面存在多余或者错误配置的 dhcp 中继导致你获取到了运营商的地址。如果没有那就要在继续分析。

[Rorysky]

@fuzzsh 你怎么判断 mac 头有没有改过？

[RoyCho]

@thereone 图挂了，我可以直接电脑接光猫拨号，然后用 dhcp 服务器探查工具探查下吗？目前直接路由器后探查只能查到自己合法的 dhcp 服务器，非法服务器非常偶尔才会干扰一次，很不好排查的感觉

[RoyCho]

@Rorysky 是不是有可能是光猫外的设备干扰？因为光猫我已经换第三个了，但干扰服务器一直是名为 3g 的服务器

[Rorysky]

@RoyCho 最简单排除法呗，直接把光纤拔了；

[dasenlin]

要不你改一下 wifi 密码试试

[Damn]

@Kepy 那你有没有想过员工宿舍或租赁房中，以企业名义办的宽带，不给你任何信息的情况呢？

[RoyCho]

@Rorysky 要是一直干扰倒好排除了，直接一条条拔，几个月才有一次

[RoyCho]

@dasenlin 应该不是有人蹭网，我的 ap 可以管理接入的设备，所有设备我都备注过了，有未知设备我会知道的

[Kepy]

@Damn 。。。。说的不是家宽吗？

[thereone]

@RoyCho 图没有挂，你用全局代理试试我这边看着是没有问题的。你要电脑直接拨号那要能在虚拟拨号接口发送 dhcp 报文探测才行。如果是连接光猫的物理网卡接口探测那就没有意义了能拿到的也只是光猫的 dhcp 分配的。还有你的 openwrt ipv6 有没有启用是不是用的中继模式获取的地址？

[unused]

MAC 地址都有了，查 MAC 表啊

[DAPTX4869]

我的 OP 里也有这条规则, 但区域是 wan 到此设备; 这个是不会影响到 lan 下其它设备的额

[niukuo]

@RoyCho 是的 用规则过滤一下就行了 可以后台跑一段时间

[Rorysky]

中间路由器配置个 dhcp snooping 再观察

[Damn]

@Kepy 你没见过企业名下的家宽么？

[RoyCho]

@unused 也很诡异，查不到...

[RoyCho]

@DAPTX4869 我感觉要上游正好有错误的配置才会触发

[RoyCho]

@thereone 我之后再消化一下你说的内容哈，我不是太专业的，我的 lan 区域 v6 是服务器模式，无状态+有状态，都是默认设置也不懂改了有什么副作用，没感觉有问题就一直这么用

[RoyCho]

@Rorysky 我不是太专业的，只能先禁用 Allow-DHCP-Renew 规则再观察观察了

[RoyCho]

@kome 我查了下好像运营商不需要有到我内网的路由，利用了我网络拓扑中的 PPPoE 连接，PPPoe 连接本身就是一个点对点的二层链路

[n2l]

@SeeleLu 问题确实透过来了，桥接后的光猫 WAN 口接的路由器，路由器关了 DHCP ，电脑连接路由器就被分了光猫同网段的 IP ，我用的是 tplink 的 WDR7650 ，同样的操作我换成 AX3000T 就不会。

[UnluckyNinja]

@RoyCho #48 他图没挂，imugr ，换个好点的梯子节点就能看到了

[leafin]

@kome #42 没错，我使用的水星 AP 也是这样，如果它不能从主路由器获得 ip 地址，它就会开启自己的 dhcp 服务。
由于我的主路由装在虚拟机里，启动速度较慢，所以当家里意外断电又恢复后，AP 可能先完成启动导致开启 dhcp 服务，不过这只影响该 AP 下连接的设备。
根据这个思路建议楼主关掉提供 dhcp 的路由器，然后观察局域网内流量。或者像我的例子一样断电恢复，启动其它设备但不要启动路由器，然后观察。

[leafin]

上一条回复没有考虑楼主可能没有交换机的情况，这个得根据自己情况调整测试过程😅。
总之就是让局域网里没有 dhcp 服务，看其他设备在启动时检测不到 dhcp 服务后，是否会"智能"地启动一个 dhcp 服务

[RoyCho]

@leafin 给我提供了一个很好的思路，我试了下关闭了 dhcp 服务，暂时没有探知到别的 dhcp 服务器，这个干扰非常偶然才会发生，所以这么多年了一直排查不到。

[Edge2047]

我前天碰到类似情况，探究发现是 softether 的内网 vpn 服务器开了 dhcp ，然后桥接在内网网卡上，这个 dhcp 会给内网分配 ip 。你用 openvpn 的话可以看看是不是类似问题

[RoyCho]

@Edge2047 是不是在虚拟 HUB 中的“虚拟 NAT 和虚拟 DHCP 服务器”中设置的，我的 SecureNAT 没启用，SecureNAT 配置中 DHCP 虽然打开了，但也是一个 30 网段的配置，不启用 SecureNAT 的话应该不会有影响

[Edge2047]

@RoyCho 你说的对。我是启用了 secureNAT