☰

Linux 网桥不会转发来自老式 BSD 机器的 IP 数据包 --- 但来自其他 Linux 的数据包没问题

tag-icon • tag-icon linux networking ethernet bridge tap
Linux 网桥不会转发来自老式 BSD 机器的 IP 数据包 --- 但来自其他 Linux 的数据包没问题

概述

我使用 Linux 单板计算机作为 AWS 主机和一台非常古老且非常罕见的 Unix 计算机。这个设置一直有效，直到最近sudo apt upgrade在单板机上出现了一些问题，如图所示在这张图片中。现在，该网桥似乎不再传递来自旧 Unix 盒子的一些以太网帧，但是将要对现代 Linux 计算机上的以太网帧执行此操作！我想知道发生了什么变化以及如何修复它。

设置

如果上面链接的图表无法访问，这里是一个示意图：

                     +----------------------------+            +----------------+
                     |  Raspberry Pi              |            |  AWS host      |
                     |                +--------+  |            | +---------+    |
+---------+          |                | fastd   \....internet.....\  fastd |    |
| Vintage |--10bT--[eth0]===[br0]===[lance0]    / |            |  /   [lance0]  |
| BSD 4.2 |          |                +--------+  |            | +---------+    |
+---------+          |                            |            |                |
                     +----------------------------+            +----------------+

在此设置中，实例快速（在 TAP 模式下）Pi 和 AWS 主机上充当这两台机器之间的虚拟以太网电缆。我已经测试过它可以通过使用乙醚通过链路双向发送原始以太网帧，从 Pi 到 AWS，反之亦然。由于您需要以太网接口的名称，lance0因此我使用了历史致敬。

现在，在 Pi 上，我想将虚拟以太网电缆以及非常真实的以太网接口eth0插入虚拟以太网集线器，这就是用途br0。这是您的标准 TAP 桥，通过建立

ip link add name br0 type bridge
ip link set dev br0 up

ip link set dev lance0 master br0
ip link set dev eth0 master br0

完成此操作后，就好像我已将旧 BSD 盒和[lance0].......[lance0]“以太网电缆”插入同一个以太网集线器。 BSD 和 AWS 应该能够通过这台两台计算机的以太网相互通信。

问题

想象一下我已登录到 AWS 主机。我有一个分配给 的 IP（当然是 v4）lance0。我想 ping 我的老式 BSD 盒子。为了简化事情，我在 BSD 机器（有自己的 IP）和 AWS 主机上手动设置了 ARP 表 --- 这意味着仅有的流量将是 ICMP 数据包（计算机可以跳过 ARP 交换）。 ping 不通，因此为了进行调查，我们使用 来检查 Pi 上的内容tcpdump -i [interface]。我们观察到：

  • 看起来eth0不错。您会看到来自 AWS 盒子的回显请求和来自 BSD 盒子的回显回复。
  • br0同样的故事：看起来不错。
  • 但是，在 上lance0，您只能看到回显请求。回显回复正在被丢弃！

现在假设您用电缆末端的一台现代 Linux 机器代替了eth0已有 36 年历史的 BSD 机器。惊喜：ping 通了，一切正常！

观察结果

以太网和 TCP/IP 在老式 BSD 机器上运行良好。你可以摆脱所有的桥接，只需在 Pi 上挂一个 IP eth0，然后整天从 Pi 上 ping/telnet/ftp BSD 盒子即可。

BSD 和 Linux 之间的 ICMP 数据包看起来相同。使用tcpdump -i br0 -XX在网桥上，我检查了 ping 数据包的十六进制转储及其链路层标头。我不明白为什么它会喜欢现代 Linux 机器而不是旧 BSD 机器的 ping。您可以通过查看自己进行比较这个粘贴（这是一个备份）。

fastd 链接可能不是问题。如上所述——否则 AWS 机器和现代 Linux 机器之间的 ping 根本无法工作。

“通常的嫌疑人”似乎并不负有责任。 这一页许多 StackOverflow/ServerFault 页面都有很好的建议，但似乎并不适用于此。在 Pi 上，brctl show看起来很正常；brctl showstp br0显示eth0和lance0处于转发模式；并brctl showmacs br0为每个相关人员显示正确的以太网地址。表ebtables“filter”和“nat”均为空，且具有 ACCEPT 策略。表arptables“过滤器”也是同样的方式。运行iptables-save不会给你带来任何好处（没有任何条目）。

网桥将传递以太网广播帧！有时，BSD 机器上的旧 NTP 守护程序会发出广播 UDP 消息，这些消息会被打包到寻址到 ff:ff:ff:ff:ff:ff 的以太网广播帧中。这些帧做使其到达 AWS 主机，即使帧发送到非广播地址不似乎成功了。

所有这一切在几个月前都在发挥作用。我想它是在二月初才破裂的。

问题

那么，为什么 Pi 上的 Linux 的以太网分路桥接不想再传递一些带有 IP 有效负载的（非广播）老式以太网帧呢？如果没有人知道，我可以使用其他工具来尝试识别这些框架之间的差异吗？

相关内容