☰

IPsec

tag-icon • tag-icon linux vpn bridge bonding
IPsec

我正在尝试通过 VPN (GRE-TAP) 实现 Linux 绑定。有趣的是，它只有当我tcpdump在两台主机上运行时才有效，但稍后会详细介绍...

有两台机器，分别称为pxn1和pxn2。它们通过 eth1 使用简单的交换机连接在一起。

pxn1 has IP address 10.1.1.197
pxn2 has IP address 10.1.1.199

IPsec

为了获得安全连接，所有 IP 流量都使用 IPsec 加密。这有效，我可以在两台机器之间 ping 通，没有任何问题，并且tcpdump只显示加密数据包。

贸易援助计划

一个 GRE-TAP（通过 IP 隧道传输以太网帧）然后在两个方向上设置接口，因为稍后我将需要一个虚拟网络接口：

ip link add vpn_gre_pxn2 type gretap local 10.1.1.197 remote 10.1.1.199 dev eth1

ifconfig 显示：

vpn_gre_pxn2 Link encap:Ethernet  HWaddr 1a:73:32:7f:36:5f
          inet6 addr: fe80::1873:32ff:fe7f:365f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1462  Metric:1
          RX packets:19 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1294 (1.2 KiB)  TX bytes:1916 (1.8 KiB)

这是在 上pxn1。在另一台主机上，在另一个方向上设置了相同的接口。

桥

已建立当前仅使用 GRE-TAP 设备的桥。

我需要桥接器，因为稍后我想添加更多机器（我的计划是将所有 GRE 隧道桥接在一起）。最终结果应该成为一个 VPN 网状网络（每个主机-主机组合都有一个专用的 GRE-TAP 接口）。但由于现在我只是用两台机器进行第一次测试，所以桥接器当然有点没用，但对于测试本身来说仍然很重要。

brctl addbr vpn_br
brctl addif vpn_br vpn_gre_pxn2

大桥正常运转因为当我激活vpn_br接口并设置一些 IP 地址（仅用于测试桥接器）时，ICMP PING 可以完美运行。

vpn_br    Link encap:Ethernet  HWaddr 02:00:0a:01:01:c5
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1462  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:448 (448.0 B)  TX bytes:468 (468.0 B)

粘合

Linux Bonding 接口现已设置完毕。同样，由于这只是第一次概念验证测试，因此我只会向 Bonding 添加一个从属设备。

稍后还会有一个真正的单独的 Gbit NIC 和一个专用交换机，它将充当主从属设备（VPN 只是备份），但现在绑定接口将仅使用 VPN。

modprobe bonding mode=1 miimon=1000
ifconfig bond0 hw ether 02:00:0a:01:01:c5  # some dummy MAC
ifconfig bond0 up
ifconfig bond0 mtu 1462
ifenslave bond0 vpn_br   # as said, only a single slive at the moment
ifconfig bond0 172.16.1.2/24 up

另一台主机设置为 172.16.1.1/24，HWaddr 为 02:00:0a:01:01:c7。

这产生了一个理论上有效的粘合界面：

bond0     Link encap:Ethernet  HWaddr 02:00:0a:01:01:c5
          inet addr:172.16.1.2  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::aff:fe01:1c5/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1462  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:448 (448.0 B)  TX bytes:468 (468.0 B)

我觉得状态也不错：

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: vpn_br
MII Status: up
MII Polling Interval (ms): 1000
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: vpn_br
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: 1a:73:32:7f:36:5f
Slave queue ID: 0

...路由表也是如此：

# ip route show
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.2
172.16.1.0/24 dev bond0  proto kernel  scope link  src 172.16.1.2
10.1.1.0/24 dev eth1  proto kernel  scope link  src 10.1.1.197
default via 10.1.1.11 dev eth1

注意：eht0是一个单独的活动 NIC（以太网交叉电缆），但在我看来这并不重要。

问题

我觉得这个设置不错，但是 PING 不起作用（这是在 上运行的pxn1）：

# ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
From 172.16.1.2 icmp_seq=2 Destination Host Unreachable
From 172.16.1.2 icmp_seq=3 Destination Host Unreachable
From 172.16.1.2 icmp_seq=4 Destination Host Unreachable

在 ping 期间，tcpdump 在另一台机器上（pxn2）表示：

# tcpdump -n -i bond0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:45:13.013791 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
17:45:13.013835 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28
17:45:14.013858 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
17:45:14.013875 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28
17:45:15.013870 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
17:45:15.013888 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28

但是，当我在单独的终端tcpdump上运行时，我突然收到了 ICMP 回复！pxn1

...
From 172.16.1.2 icmp_seq=19 Destination Host Unreachable
From 172.16.1.2 icmp_seq=20 Destination Host Unreachable
64 bytes from 172.16.1.1: icmp_req=32 ttl=64 time=0.965 ms
64 bytes from 172.16.1.1: icmp_req=33 ttl=64 time=0.731 ms
64 bytes from 172.16.1.1: icmp_req=34 ttl=64 time=1.00 ms
64 bytes from 172.16.1.1: icmp_req=35 ttl=64 time=0.776 ms
64 bytes from 172.16.1.1: icmp_req=36 ttl=64 time=1.00 ms

这只适用于两个都机器正在运行。当程序同时在两台机器上运行时，tcpdump我可以启动/停止并始终只看到回复。无论我在哪台机器上尝试都没关系。tcpdump

这是内核错误吗？或者（更可能）是我的配置有问题？

桥接器和绑定接口都显示相同的 MAC 地址，这正常吗？我只手动配置了绑定接口，这显然也改变了桥接器。

仅供参考，配置概述：

更新

当我将桥接接口设置为混杂模式 ( ifconfig vpn_br promisc ) 时，我得到了一个工作设置。我不太确定这是否是正常需要的。另一方面，我不知道思考它有任何缺点……

顺便说一下，有一个类似的RedHat 错误报告存在，但bond0对我的情况来说，设置向下/向上没有帮助。

答案1

没有绑定件它能工作吗？我怀疑问题是 LACP 消息无法通过网桥，除非你将其置于混杂模式。

如果您使用的是 3.5 或更高版本的内核，启用桥接接口的 IGMP 查询传输可能也会有所帮助。这可以帮助桥接器订阅 LACP 多播组。

echo -n 1 > /sys/devices/virtual/net/vpn_br/bridge/multicast_querier

相关内容