【iptables交流贴】iptables执行的流程分析

Godbach

呵呵，高手可能都忙于开发自己的东西了。不像咱们这些初学者，还需要了解很多初级的问题，不在论坛上问，还去哪里呢。

Godbach

原帖由 sunorr 于 2008-8-7 17:47 发表


谢谢哈，的确比较多哈～哪种比较简单易学呢？

系统调用最省事了吧，呵呵。

proc也不错。具体的dreamice给咱们讲讲啊。

sunorr

原帖由 Godbach 于 2008-8-7 17:44 发表


看一下Libiptc.c中TC_COMMIT这个函数。

还是不太明白啊，在终端中执行“iptables 。。。。” 然后规则就生效了，但是，并没有执行iptables-restore呀，而iptc_commit这个函数是出现在iptables-restore.c文件中的啊

晕，具体讲下……

Godbach

又看了一遍九贱兄的netfilter分析。搞清楚了一个问题，mark一下。
问题就是内核中一条规则中所有match是如何匹配的问题。因为iptables传过来的结构体中，并没有包match的处理函数。这里在check_match（iptables.c）中实现了查找全局的链表ipt_match，如果找到该match的话，则将链表中该match对应的匹配函数赋给规则中该match结构的成员：
m->u.kernel.match = match;

这样在对数据包进行匹配的时候，就可以直接调用具体模块的match函数进行处理了。

------Bingo

[ 本帖最后由 Godbach 于 2008-8-7 18:15 编辑 ]

Godbach

原帖由 sunorr 于 2008-8-7 18:07 发表

还是不太明白啊，在终端中执行“iptables 。。。。” 然后规则就生效了，但是，并没有执行iptables-restore呀，而iptc_commit这个函数是出现在iptables-restore.c文件中的啊

晕，具体讲下……

iptables-restore的具体功能我们有研究。
iptc_commit这个函数还出现在了iptables_standalone.c，这个文件才是整个iptables命令行的入口，有main函数。

flw2

原帖由 sunorr 于 2008-8-7 17:12 发表
如果表是空的，数据包就不经过netfilter吗？不是这样吧？

netfilter最下面是一堆hook，如果没有规则，那么这些hook就是不干什么了

Godbach

原帖由 flw2 于 2008-8-7 18:17 发表


netfilter最下面是一堆hook，如果没有规则，那么这些hook就是不干什么了

是的，list_empty为空啊，NF_HOOK就直接执行最后一个参数指定的函数了。

flw2

原帖由 sunorr 于 2008-8-7 17:24 发表
那NF在内核中是在TCP/IP协议栈之前呢？还是之后呢？

net/core/dev.c
int netif_receive_skb(struct sk_buff *skb)
{
        struct packet_type *ptype, *pt_prev;
        struct net_device *orig_dev;
        int ret = NET_RX_DROP;
        unsigned short type;

        ...

        ...

        /* 类似于tcpdump这样的程序（或者其它使用libpcap的程序）
        就在这个地方抓到这个包 */
        list_for_each_entry_rcu(ptype, &ptype_all, list) {
                if (!ptype->dev || ptype->dev == skb->dev) {
                        if (pt_prev)
                                ret = deliver_skb(skb, pt_prev, orig_dev);
                        pt_prev = ptype;
                }
        }
        ...

        /* 根据是否是桥上的接口，包可能会通过这里到达桥处理包的代码 */
        if (handle_bridge(&skb, &pt_prev, &ret, orig_dev))
                goto out;

        /* 如过桥(2层)不处理该包，那么该包就要走向3层也就是tcp/ip协议栈的网络层了
        根据是IP协议还是arp协议等，最后把包传递给相应的函数，该函数由协议初始化的时候注册的
        比如ip_rcv, ipv6_rcv, arp_rcv等 */

        type = skb->protocol;
        list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type)&15], list) {
                if (ptype->type == type &&
                    (!ptype->dev || ptype->dev == skb->dev)) {
                        if (pt_prev) ）
                                ret = deliver_skb(skb, pt_prev, orig_dev);
                        pt_prev = ptype;
                }
        }

        if (pt_prev) {）
                ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);//ip_rcv~~~~~~~
        } else {
                /* 没有函数处理这种协议，比如自定义的非arp/ip 的协议 */
                kfree_skb(skb);
                /* Jamal, now you will not able to escape explaining
                 * me how you were going to use this.
                 */
                ret = NET_RX_DROP;
        }

out:
        rcu_read_unlock();
        return ret;
}


net/ipv4/ip_input.c
/*
*      Main IP Receive routine.
*/
int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt, struct net_device *orig_dev)
{
        struct iphdr *iph;
        u32 len;

        ...



        ...

        /* 通向netfilter之路 */}}}
        return NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, dev, NULL,
                       ip_rcv_finish);

inhdr_error:
        IP_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS);
drop:
        kfree_skb(skb);
out:
        return NET_RX_DROP;
}

在netfilter处理之后再往4层走，发包也是类似的

Godbach

原帖由 flw2 于 2008-8-7 18:21 发表


net/core/dev.c
int netif_receive_skb(struct sk_buff *skb)
{
        struct packet_type *ptype, *pt_prev;
        struct net_device *orig_dev;
        int ret = NET_RX_DROP;
        unsi ...

版主能否帮忙解释一下偶在46.47楼的问题。也就是带有-m state的规则，是否被调整到对应CHAIN的规则的开始处？

sunorr

原帖由 flw2 于 2008-8-7 18:17 发表


netfilter最下面是一堆hook，如果没有规则，那么这些hook就是不干什么了

那怎么还拿nf的效率说事？:em11: