我是怎么莫名地劫持了自己的 DHCP 的

1. DNS 抢答

我们都知道，传统的 DNS 走的是 UDP 协议，在大陆的网络环境下，DNS 请求是可以被抢答的，不信你看：

# 美西的机器
root@pf:~# dig www.bennythink.com +short
104.27.167.30
104.27.166.30

# 大陆的机器
➜  ~ dig www.bennythink.com +short
67.15.129.210

天知道国内这个这是个什么 IP！

DNS 抢答有不少优点，比如：

• 对于国内用户而言，DNS 请求不再需要一层层递归到原始 NS 服务器了
• 整个大陆有超多 POP 为对应的请求响应，缩小了延迟
• 减少了 NS 服务器的压力和请求次数

唯一的问题就是：

• 它解析出来的 IP 是不能用的

2. DHCP

对于 DHCP 的简要原理，在之前的博文（我们的 IP 是怎么来的——从本地路由 DHCP 到 IANA 的 “公网” IP 分配^[1]）中我们知道，和 DNS 类似，它也是一个走 UDP 的，随缘返回的一个协议，但是和 DNS 不同，大部分的 DHCP 请求都是在一些内网中，由于路由器广播域的限制，DHCP 请求一般不会被漏到公网中。

DHCP Error

前段时间在配置一个网络的时候，插上自己电脑的网线发现 IP 不再是熟悉的 192.168.1.xxx ，而变成了 10.19.89.xxx，“但是依然可以正常上网”。

这个时候第一反应是访问一下之前的网关 192.168.1.1，发现能 ping 通，也可以正常地访问到对应的配置页面。

这个时候问题就非常奇怪了，除了在寝室内有配置过这个段以外，应该不会在什么地方配置这么个段吧…

思前想后终于想到了在某个图形化的界面上配置过这么个 IP 段：

然后突然想到了角落的一台 NUC，那还是几天之间为了保证国内其他地区用户可以通过它连接到国内大内网中而随意开的一个 SoftEther VPN Server，最初尝试失败之后就被搁置了，没想到它的 SecureNAT 功能在本地内网内成为了一个 DHCP 服务器继续发光发热。

DHCP Packet

在大概确认了来源之后，就开始打开 Wireshark 开始抓包了，很快就可以看到又如下的包：

从上面的包中我们可以看到，我的电脑先是对外发了一个 DHCP Discovery 的广播包，然后有两个 DHCP 服务器给我们客户端发了 Offer ，分别是 192.168.1.1 和 10.19.89.1，且后者先给的 Offer，于是我们的客户端接受了这个 10.19.89.1 的 Offer。

由于没有配置 IP 地址、网关、DNS 等，在网络上是寸步难行的，因此首先需要从 DHCP 那获得这些。然而，既然连 IP 地址都没有，那又是如何通信的？显然，只能发到广播地址（255.255.255.255）上，而自己则暂时使用无效的 IP 地址（0.0.0.0）。（事实上，链路层的通信只要有 MAC 地址就行，IP 地址已属于网络层了，但 DHCP 由于某些特殊需要使用的是 UDP 协议）

因为是发往广播，内网环境里的所有用户都能听到。如果存在多个 DHCP 服务器，则分别予以回复；用户则选择最先收到的。由于规则是如此简单，以至于用户没有选择的余地。

来源：https://www.jianshu.com/p/aed707f183c5

所以之前的问题也就非常明显了，由于自己的配置失误，被内网另一个 DHCP 服务器抢答了 DHCP 请求（连网关都抢过去了），所有的流量都走了那台 NUC，然后那台 NUC 再向上转发了对应的流量。

这个时候另一个问题出现了，为什么同在 192.168.1.0/24 网段下的 NUC 可以更快地发出 DHCP Offer 呢？

所以在一个内网下，如果想要劫持原有用户流量我们可以走 ARP 欺骗的路子，如果希望劫持新用户的流量，还可以考虑一下 DHCP 抢答的方式（当然，成功率随缘），这个时候回头来看一下在学校里面非常常用的 EtterCap 的 DHCP Spoof 功能…

感慨万千…

参考资料

你可能还喜欢

点击下方图片即可阅读

云原生是一种信仰 ?

扫码关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！