IPTables 和 DHCP 问题？

Question

在我的另一个线程中，我正在谈论有关iptables 策略和状态的一些有趣的事情，现在我想更多地了解 DHCP 的工作原理以及 iptables 如何理解它。

ETH0 连接到我的主交换机，它从我的路由器接收动态 ip，不仅可以访问互联网，还可以访问我的外部网络。

ETH1 是连接到内部交换机的内部卡，X 客户端从该服务器接收其 IPS

ETH1 网络为 192.168.1.0/255.255.255.0，其中服务器 IP 为 192.168.1.254。

据我了解，dhcp 是一个 bootp 协议，因此即使您的防火墙策略可以删除所有内容，您的网络仍会收到 DHCP，在我进行的测试中，这似乎是正确的。

来自 tcpdump：

root@test:~# tcpdump -i eth1 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:34:03.943928 IP 192.168.1.2.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303
11:34:03.957647 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300
11:34:06.492153 IP 192.168.1.2.bootpc > 192.168.1.254.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303
11:34:06.506593 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300

我做了一个简单的日志规则来看看 iptables 做了什么：

root@test:~# tail -f /var/log/syslog
Oct 15 11:30:58 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9527 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:31:43 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9529 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:33:32 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9531 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:34:03 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9533 PROTO=UDP SPT=68 DPT=67 LEN=311

这是我目前的 iptables 规则：

# deny all traffic
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

# Use stateful inspection feature to only allow incoming connections
# related to connections I have already established myself
$IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# allow all traffic on lo interface
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

因此，即使使用默认的 POLICY 删除所有内容，我仍然可以在我的网络上获得 DHCP，而更新 IP 等确实需要更长的时间。

如果我将以下规则添加到我的防火墙中：

$IPT -I OUTPUT -o $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

更新任何客户端 dhcp 将花费更少的时间。

考虑到以上几点：

1. 为什么更新它确实需要更长的时间，即使它没有被阻止？
2. 是否可以完全删除 dhcp 服务器而不将其关闭？
3. 是否可以使用 BOOTP 在 iptables 中接受 dhcp 服务器？这是怎么做的？

---

如果你知道好的链接，我不介意拿很多:)

Answer 1

我会回答#2：不。

当获取 IP 地址时，dhcp 守护进程会创建一个到网络接口的原始套接字并处理 UDP 协议本身。因此，UDP 数据包永远不会通过 iptables。

dhcp 守护进程必须实现 UDP 的原因是内核只能在接口具有 IP 地址时处理 UDP（实际上是所有 TCP/IP 套件）。以前 dhcp 守护进程会首先为接口提供 0.0.0.0 的 IP 地址，但这不再有效。

Answer 2

添加

$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

应使 DHCPD 更新更快:) 它应在 INPUT 和 OUTPUT 双方工作。您可以使用 ebtables 删除 dhcpd，而不是使用 iptables。DHCPD 在 0.0.0.0 侦听，不在 IP 内

Answer 3

我最近在 OpenWRT Kamikaze 7.09 = 2.4.34 和来自 busybox 1.4.2 的 udhcpc 上的观察：

我在 OUTPUT 链中有一个“ACCEPT”策略，而在 INPUT 方向，我最初依赖的是这个经典的包罗万象的规则：

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

允许 WAN 接口上的 DHCP 响应（到我的 udhcpc）。即，这是我的 ISP 的上游 DHCP 服务器为我分配 IP 地址的地方。

注意初始 DHCP 交换（发现、提供、请求、确认）和 DHCP 租约更新（请求、确认）之间的区别。

启动后，udhcpc 通过完整的初始交换启动。那次交流会成功。再更新一两次也会成功——只是一个请求和确认。我的 ISP 的 DHCP 服务器通常要求大约 1 小时到 1.5 小时的更新时间，因此我的 DHCP 客户端每 30 到 45 分钟要求更新一次（此行为基于 RFC）。

但是，大约在第三次或第四次更新时，它会开始变得有趣。TCPdump 会显示大约 3 次左右的更新尝试，然后是完整的初始交换——在几分钟甚至几秒钟的时间跨度内。好像 udhcpc 不喜欢它得到的东西:-( 并且最终会对完全交换感到满意。此后，半小时后再次续订将成功......并且故事将再次重复。

我发现，可能是内核中的连接跟踪出了问题。好像 conntrack 条目在两个小时左右后过期，并且以后的 DHCP 续订失败，因为来自服务器的 ACK 实际上并没有使其 udhcpc 侦听套接字。请注意，tcpdump (libpcap) 在原始接口上侦听，并且可以看到所有传入的数据包，然后再将它们处理为 iptables。一旦 udhcpc 放弃续订，并在绝望中尝试使用完整交换从头开始（从 DISCOVER 开始），内核会建立一个新的 conntrack 条目，并且可以在一段时间内理解相关数据包......

果然，一旦我添加了类似的东西：

iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT

更新似乎永远有效。

您可能会发现以下 tcpdump cmdline 参数很有用：

tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68

注意：-vv要求详细的解剖器输出。eth0.1是我的 WAN 端口（也是“NAT 外部”接口）。

ACK 数据包中一个有趣的属性是 LT：字段 = 建议/最大授权租用时间（以秒为单位）。DHCP 请求从端口 68 发送到端口 67。响应来自端口 67 到端口 68。