周末的时候写了一篇关于Docker底层支撑技术的文章：
以firejail sandbox解析Docker核心原理依赖的四件套：https://blog.csdn.net/dog250/article/details/81025071
获得了一些反响，总结下来就三点：
1. 确实这四件套支撑了很多的容器技术；
2. 唱衰Docker以及OverlayFS，Cgroup，NS这些，以为它们违背了某种原则；
3. 关于firejail网络方面的某些细节。

上述的1和2显得过于形而上，保留个人观点不讨论，或者等哪天闲了再说。关于第三点，我觉得有必要梳理一下，本文先说一个典型的。

有网友问到，firejail的Macvlan配置细节是怎样的，firejail容器内的Macvlan虚拟网卡如何访问容器外宿主机的IP地址呢？？(先说答案吧，默认情况下，不能访问)

我并没有深入的了解过firejail，本身接触它也不久，所以只能从其文档代码中去一窥究竟了。firejail的github源在这里：https://github.com/netblue30/firejail

1. 从以下的链接可以看到一个典型的Demo样例，我和作者描述问题的思路是一致的：
   https://github.com/netblue30/firejail/blob/master/src/firejail/network.txt
2. 从下面的代码中你可以看到firejail关于macvlan的配置细节：
   https://github.com/netblue30/firejail/blob/master/src/firejail/network_main.c

总而言之，firejail使用网络的方式有两种：

• Bridge veth的方式：与Docker Bridge模式一致，如果–net参数指定一个Linux Bridge的话。
• Macvlan bridge模式：如果–net参数指定一块物理网卡，即会产生一个bridge模式的macvlan虚拟网卡。

这些在其manual中也有提到：

–net=bridge_interface
                Enable  a  new  network  namespace  and  connect it to this bridge interface.  Unless specified with option –ip and –defaultgw, an IP address and a
                default gateway will be assigned automatically to the sandbox. The IP address is verified using ARP before  assignment.  The  address  configured  as
                default gateway is the bridge device IP address. Up to four –net bridge devices can be defined. Mixing bridge and macvlan devices is allowed.
  .
                Example:
                sudobrctladdbrbr0 sudobrctladdbrbr0 firejail –net=eth0 –ip=192.168.1.80 –dns=8.8.8.8 firefox

现在我们关注第二点，即Macvlan的方式。我使用下面的命令启动firejail：

# 我为容器指派192.168.44.55这个IP地址# 我的宿主机enp0s17这块网卡的IP地址是192.168.44.138root@debian:/home/zhaoya# firejail --net=enp0s17 --ip=192.168.44.55/24 Reading profile /etc/firejail/server.profileReading profile /etc/firejail/disable-common.incReading profile /etc/firejail/disable-programs.incReading profile /etc/firejail/disable-passwdmgr.inc** Note: you can use --noprofile to disable server.profile **Parent pid 870, child pid 871The new log directory is /proc/871/root/var/logInterface        MAC                IP               Mask             Statuslo                                  127.0.0.1        255.0.0.0        UP    eth0-870         1e:01:c7:ff:4b:39  192.168.44.55    255.255.255.0    UP    Default gateway 192.168.44.2Child process initializedroot@debian:~# root@debian:~# ping 192.168.44.138PING 192.168.44.138 (192.168.44.138) 56(84) bytes of data.From 192.168.44.55 icmp_seq=1 Destination Host UnreachableFrom 192.168.44.55 icmp_seq=2 Destination Host UnreachableFrom 192.168.44.55 icmp_seq=3 Destination Host Unreachable

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25

在容器外的宿主机抓包：

root@debian:/home/zhaoya# tcpdump -i enp0s17 arp or icmp -ntcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on enp0s17, link-type EN10MB (Ethernet), capture size 262144 bytes19:31:50.029168 ARP, Request who-has 192.168.44.138 tell 192.168.44.55, length 2819:31:51.053176 ARP, Request who-has 192.168.44.138 tell 192.168.44.55, length 2819:31:52.077292 ARP, Request who-has 192.168.44.138 tell 192.168.44.55, length 2819:31:53.101540 ARP, Request who-has 192.168.44.138 tell 192.168.44.55, length 28...

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

显然，ARP请求没有得到回应。

如果此时另外启动一个新的firejail容器，指派另一个同网段IP地址，你会发现，两个容器之间是可以互通的，但是容器和宿主机之间无法互通，这是怎么回事？

这就涉及到Macvlan的几种工作模式的原理了，我简单将其总结成下面的图示：

我们专门看看左上角第一幅图，即Bridge模式的Macvlan。显然，没有从虚拟网卡到物理网卡的通路(确实有点像裤衩…)…有了这个图示几乎便不用去看代码了。

值得注意的是，VEPA是一个特殊的模式，它不仅仅关乎Macvlan本身，还涉及到宿主机外部的交换机是否支持Hairpin(发夹弯模式，即交换机端口并不过滤入口的模式，可以实现原路echo)，所以说，Bridge模式情况下，Macvlan虚拟网卡不能访问宿主网卡，有关限定条件，即虚拟网卡在主机内部不能访问宿主网卡，虚拟网卡发出的数据包经由物理宿主网卡一旦发到外部，还是有可能通过Hairpin给echo回来的。

问题的解释就是这样。

下面是见招拆招了。如果你非要实现Macvlan的虚拟网卡和物理网卡之间的互通，怎么办？其实简单，只需要构造下面的图即可：

这下不看代码也得看了！

主要看Macvlan的xmit回调：

static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev){    const struct macvlan_dev *vlan = netdev_priv(dev);    const struct macvlan_port *port = vlan->port;    const struct macvlan_dev *dest;    if (vlan->mode == MACVLAN_MODE_BRIDGE) {        const struct ethhdr *eth = (void *)skb->data;        /* send to other bridge ports directly */        if (is_multicast_ether_addr(eth->h_dest)) {            macvlan_broadcast(skb, port, dev, MACVLAN_MODE_BRIDGE);            // 显然在ARP广播注入所有的虚拟网卡接收路径后，便从物理网卡直接发到外部去了。            goto xmit_world;        }        dest = macvlan_hash_lookup(port, eth->h_dest);        // 如果不是广播，也只有路由到虚拟网卡的数据包从能被注入。        if (dest && dest->mode == MACVLAN_MODE_BRIDGE) {            /* send to lowerdev first for its network taps */            dev_forward_skb(vlan->lowerdev, skb);            return NET_XMIT_SUCCESS;        }    }xmit_world:    skb->dev = vlan->lowerdev;    // 直接经由物理网卡连接的线缆发出。    return dev_queue_xmit(skb);}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31

对付这个非常简单，只需要改成下面的这个就行：

static int macvlan_queue_xmit_v2(struct sk_buff *skb, struct net_device *dev){        const struct macvlan_dev *vlan = netdev_priv(dev);        const struct macvlan_port *port = vlan->port;        const struct macvlan_dev *dest;        if (vlan->mode == MACVLAN_MODE_BRIDGE) {                const struct ethhdr *eth = (void *)skb->data;                /* send to other bridge ports directly */                if (is_multicast_ether_addr(eth->h_dest)) {                        struct sk_buff *nskb;                        macvlan_broadcast(skb, port, dev, MACVLAN_MODE_BRIDGE);                        nskb = skb_clone(skb, GFP_ATOMIC);                        if (likely(nskb)) {                                nskb->dev = vlan->lowerdev;                                // 往物理网卡也注入一份。                                dev_forward_skb(vlan->lowerdev, nskb);                        }                        goto xmit_world;                }                dest = macvlan_hash_lookup(port, eth->h_dest);                if (dest && dest->mode == MACVLAN_MODE_BRIDGE) {                        /* send to lowerdev first for its network taps */                        dev_forward_skb(vlan->lowerdev, skb);                        return NET_XMIT_SUCCESS;                }                // 如果目标MAC是物理网卡的，则注入到宿主物理网卡                else /*if (!compareMacs(eth, vlan->lowerdev))*/{                        struct sk_buff *nskb;                        nskb = skb_clone(skb, GFP_ATOMIC);                        if (likely(nskb)) {                                nskb->dev = vlan->lowerdev;                                dev_forward_skb(vlan->lowerdev, nskb);                        }                }        }xmit_world:        skb->dev = vlan->lowerdev;        return dev_queue_xmit(skb);}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44
• 45
• 46

Macvlan虚拟网卡的发送路径就是这么轻松搞定的，那么接下来看一个比较棘手的，即物理网卡的发送路径，因为显然我们需要宿主机也能通过物理网卡和容器通信，比如SSH登录它。

这个比较棘手是因为我们不得不改物理网卡的驱动的hard_start_xmit回调函数，目前也没有在dev_queue_xmit中看到有什么比较好的HOOK点，而修改物理网卡驱动就为了支持Macvlan这么一个并非通用的机制，也有点怪异…

为了尽快跑起来看到效果，不去想那么多，直接使用ptype_all机制。

在数据包将要发送到物理网卡前，会有一个抓包的HOOK点，即dev_queue_xmit_nit函数。我们只需要注册一个ETH_P_ALL类型的packet_type即可将数据包拉到一个func回调中，之后便可以在这个回调中做任何想做的事了：

int xmit_handle(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt, struct net_device *orig_dev){        const struct macvlan_port *port = macvlan_port_get_rcu(skb->dev);        const struct ethhdr *eth = eth_hdr(skb);        const struct macvlan_dev *vlan;        if (skb->pkt_type != PACKET_OUTGOING)  {            // 仅仅在发送路径使能                goto drop_out;        }        if (port) {                vlan = macvlan_hash_lookup(port, eth->h_dest);                if (vlan) // 如果找到了虚拟网卡就单播注入。                        dev_forward_skb(vlan->dev, skb);                else // 如果没有对应到，就广播注入。                        macvlan_broadcast(skb, port, dev, MACVLAN_MODE_BRIDGE);                return 0;        }drop_out:        consume_skb(skb);        return再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow