Linux各种虚拟网卡master/slave的叠加使用Netfilter,iptables/OpenVPN/TCP guard:-(-

很多年前的一个夏日炎热的夜晚，我在一家银行16摄氏度的机房蹲了2小时编写一个功能：

• eth0被bridge到br0，br0跑转发流量，eth0跑管理流量。

这个问题并没有想象的那么简单，不信你去试一下。

一般而言，当eth0被bridge或者被bonding了之后，它就成了slave，对外就不可见了。但是这真的很合理吗？根本就不合理。

网卡就是一个转发设备，哪来的业务逻辑？

Linux虽然实现了bridge，bonding，veth，vlan，macvlan，ipvlan，tun/tap等虚拟网卡，但不要过于神话Linux，有些事它就是做不到，或者非常麻烦。

下面是一个场景：

• enp0s9是一个物理网卡。
• enp0s9添加到了bond0；
• bond0上被配置到了vlan123。

我的需求如下：

• enp0s9裸物理网卡跑1.0.0.0/8的流量。
• bond0裸bonding网卡跑2.0.0.0/8的流量。
• bond0.123这个VLAN网卡跑3.0.0.0/8的流量。

是不是一个很直接的需求？能做到吗？

 ifconfig enp0s9 down  modprobe bonding  echo +enp0s9 >/sys/class/net/bond0/bonding/slaves  ifconfig bond0 2.2.2.1/8 up  ifconfig enp0s9 1.1.1.1/8 up  ip link add link bond0 name bond0.123 type vlan id 123  ifconfig bond0.123 3.3.3.1/8 up 

另外的一台“对端”也一样这么配置。

你会发现，2.2.2.1/2.2.2.2之间的互通是OK的，3.3.3.1/3.3.3.2之间的互通也是OK，然而1.1.1.1/1.1.1.2之间的互通是很有问题的。

这也很容易理解，虽然VLAN 123和bond0在底层都是bond0，但是由于protocol字段可以很容易区分IPv4和802.1Q，所以两个网段不会有任何冲突，然而bond0和enp0s9却会冲突。

所有的问题都出在arp上。

虽然arp_ignore等参数可以按照请求的IP地址区分是否回复ARP，但是 ARP请求的入口是不会变的。统一都是bond0！

OK，如果我们承认这一点，姑且就让bond0来处理ARP(但实际上配置enp0s9来响应ARP)，那么数据通信则会被rp_filter阻断！ 毕竟数据包是enp0s9的master bond0收上去的啊！

于是就是各种没完没了，过了就忘的trick。

我相信很多人都遇到了这类需求，于是才有了macvlan，ipvlan这种主动拆分隔离的虚拟网卡方案：

• 把一块物理的或虚拟的网卡分裂成多块使用。

说白了，本文中enp0s9和bond0的同时并行使用，就是一个纵方向上的macvlan！哈哈。

我相信如果我把本文所遇到问题的解法写出来，又是一篇长篇大论，这是我5，6年前的做法，那个时候经常写这种，全在我这个blog里，能找到很多trick式解决方案。

我不会再写这些了，因为这些方案不可持久，不可维护，除了炫耀 “百无一用的高超技巧” 之外，没有任何意义，我也早已过了那个阶段…

浙江温州皮鞋湿，下雨进水不会胖。