netfilter_ipv4.h
据我了解,Linux内核在文件中定义了五个用于IPv4数据包流的挂钩点:
/* IP Hooks */
/* After promisc drops, checksum checks. */
#define NF_IP_PRE_ROUTING 0
/* If the packet is destined for this box. */
#define NF_IP_LOCAL_IN 1
/* If the packet is destined for another interface. */
#define NF_IP_FORWARD 2
/* Packets coming from a local process. */
#define NF_IP_LOCAL_OUT 3
/* Packets about to hit the wire. */
#define NF_IP_POST_ROUTING 4
..根据netfilter_ipv6.h
同样的说法,IPv6 似乎也是如此:
/* IP6 Hooks */
/* After promisc drops, checksum checks. */
#define NF_IP6_PRE_ROUTING 0
/* If the packet is destined for this box. */
#define NF_IP6_LOCAL_IN 1
/* If the packet is destined for another interface. */
#define NF_IP6_FORWARD 2
/* Packets coming from a local process. */
#define NF_IP6_LOCAL_OUT 3
/* Packets about to hit the wire. */
#define NF_IP6_POST_ROUTING 4
这让我想知道,以定义操作发生的位置并确定可以完成哪些操作的方式来思考netfilter
/架构是否正确?此外,对于内核也很重要,还是它们只是为了让用户对可能发生的处理类型进行分组?iptables
chains
tables
tables
iptables
答案1
关键是表格按以下方式分组设计意图。所有用于过滤的规则都在这里,所有 NAT 规则都在那里。链是规则序列,默认链在数据包路径中的特定点处遍历。
理论上,您可以添加一条对 NAT 表等进行过滤的规则。但前端阻止你这样做,并显示一条类似的消息
“nat”表不用于过滤,因此禁止使用 DROP。
我的想法是,它实际上是关于链条的,而桌子是事后才想到的,可以帮助你组织它们。它令人困惑,因为它是临时的、历史悠久的用户界面设计。