我偶然发现了 Iptables 的一个奇怪问题。我不是在寻求问题的解决方案，而是在寻求对 iptables 一些奇怪行为的解释。
我的平台是带有 5.19.0-43-generic 内核的 Ubuntu 22.04.2 LTS，使用由 NetworkManager 管理的无线接口“wlp1s0”（Intel Wi-Fi 6 AX200 M.2）。
在尝试优化我的笔记本电脑 iptables 配置以使其可以在不安全的网络（如免费机场 WiFi 网络等）上使用时，我开始研究如何限制 DHCP 流量。为此，我首先从一些规则开始记录 DHCP 活动，以查看其工作原理并与 IETF DHCP RFC 进行比较：
因此，在表“过滤器”中我添加了以下规则：
-A INPUT -i wlp1s0 -p udp --sport 67 --dport 68 -j filter-log
-A OUTPUT -o wlp1s0 -p udp --sport 68 --dport 67 -j filter-log
-A filter-log -m limit --limit 5/min --limit-burst 10 -j LOG --log-prefix "[MYFW FILTER-LOG] "
-A filter-log -j RETURN
INPUT 通道默认策略为“DROP”
完成后，我便激发网络重新协商连接，如下所示：
1. sudo sysemctl restart NetworkManager
2. use NetworkManager to "forget" my connection and then re-establish anew
3. waited for an automatic renewal of the lease (12 hours after establish connection)
现在，令我惊讶的是，我没有看到任何日志记录，“iptables -L -nv -t filter”确认对于场景 1+2，计数为零，但自动更新按预期显示在日志中。我用“Wireshark”检查，它确实显示了预期的 DHCP 命令“Discover”、“Request”和“Ack”，并且它已经填写了 RFC 中描述的所有预期选项字段，因此通信确实按预期进行，但 iptables 中的日志记录却没有。当我使用过滤器“raw”将“INPUT”规则移动到 PREROUTING 通道时，来自服务器的 DHCP 回复出现在 iptables 中，但我找不到任何规则让 iptables 记录传出的初始 DHCP“Discover”或“Request”，无论 Wireshark 显示它发生了什么。
分析表明，我不需要任何特定的 DHCP 输入通道接受规则，因为它是由笔记本电脑发起的，并且答复由“RELATED,ESTABLISHED”规则接受。
但据我理解，如果有人能解释所描述的行为那就太好了。
答案1
据我所知，DHCP 协议有一些奇怪的要求，为了正常工作，客户端和服务器通常（倾向于）打开原始网络套接字，而不是或除了使用传统网络堆栈之外。背景：https://kb.isc.org/docs/aa-00378例如https://stackoverflow.com/q/14774668/2952385
因此，匹配 DHCP 协议请求和回复需要原始表中的过滤规则。使用原始套接字时，数据包会直接注入/接收，不会经过更高级别的 TCP 堆栈，因此无法在默认过滤表中观察到。
我发现下面的图表来自https://stuffphilwrites.com/2014/09/iptables-processing-flowchart/对于需要应用 netfilter/iptables 规则的上下文很有用。
