在 Debian Buster 上桥接 Wifi 不起作用

Question 1

我需要将以太网和 WiFi 适配器桥接在一起。

这是一个常见问题解答：Wifi 默认情况下使用称为 3 地址模式的东西，其结果是您无法桥接 Wifi 客户端和以太网。

（好吧，从技术上讲，你可以，但它不会工作：来自 Wifi 网络的数据包不会到达以太网上的目的地，即使它们是桥接的并且位于同一子网中。如果你写“它有点工作”，你可能没有测试过这种情况）。

然而，你能桥aWifi 接入点(AP) 和以太网。

所以，这是一个XY问题：您的 Y 是“我需要在 Debian Buster 上桥接 Wifi 和 LAN”，但我们不知道您的 X 是什么（也许：我家里有 Wifi 和 LAN，我希望它们位于同一子网中？）。

根据您的 X 是什么，还有其他方法可以实现此目的，例如，您可以桥接 Wifi AP 和 LAN在你的路由器中。

Answer

我需要将以太网和 WiFi 适配器桥接在一起。

这是一个常见问题解答：Wifi 默认情况下使用称为 3 地址模式的东西，其结果是您无法桥接 Wifi 客户端和以太网。

（好吧，从技术上讲，你可以，但它不会工作：来自 Wifi 网络的数据包不会到达以太网上的目的地，即使它们是桥接的并且位于同一子网中。如果你写“它有点工作”，你可能没有测试过这种情况）。

然而，你能桥aWifi 接入点(AP) 和以太网。

所以，这是一个XY问题：您的 Y 是“我需要在 Debian Buster 上桥接 Wifi 和 LAN”，但我们不知道您的 X 是什么（也许：我家里有 Wifi 和 LAN，我希望它们位于同一子网中？）。

根据您的 X 是什么，还有其他方法可以实现此目的，例如，您可以桥接 Wifi AP 和 LAN在你的路由器中。

Question 2

初步说明

作为@dirkt 已经写了，桥接限制是为了强制网络堆栈不会尝试（并且失败）通过无线接口发送具有不同源 MAC 地址的帧。有关此限制的详细信息可以在此 NE SE Q/A 中找到：802.11帧头中的四个二层地址。尽管链接的标题是默认情况下仅使用 3 个 MAC，并且接入点（“AP”）使用第三个 MAC 作为桥接器，而不是被视为简单端点的站客户端（“STA”）。缺席4号。切换到允许桥接 STA 的 4 地址模式（“4A”）也需要重新配置 AP 以支持 4A。例如主机通过为每个此类 STA 创建一个 4A 模式的附加本地克隆无线接口（必须对其网桥进行充分配置），可以像往常一样支持为普通 STA 提供服务，也可以为 4A 模式 STA 提供不同的服务。大多数公共客户 AP 不支持此功能（除非运行可重新配置的主机在引擎盖下和足够的 Wifi 硬件/固件）。

在OP的具体情况下，存在一个附加条件：网桥使用单个网桥端口，因此可以可以说仅假设一源 MAC 地址将来自网桥。如果桥接器配置了无线卡的 MAC 地址，则协议固有的限制在这种情况下不适用，但在这种特定情况下，无法告诉网络堆栈允许将无线接口设置为桥接端口。如果一个人只是想要另一个人界面（不是桥港) 表现得像这样，那么IPVLAN将是最简单的选择。

所以使用交通管制功能，将使用功能相当于集线器的解决方法：

获取传入无线接口的所有帧并将它们移动以显示传入镜像接口
获取从此镜像接口传出的所有帧并将它们移动到无线接口上，准备好传出（作为无线电波）。
配置网络堆栈以使用镜像接口而不是无线接口，或者这里使用此镜像接口（的韦斯对等）作为桥接端口来重现将无线接口设置为桥接端口。

然后，该虚拟“集线器”的另一个端口将作为 OP 情况下的桥接端口连接到实际的桥接器。内核不必禁止这一点，因为从技术上讲，它不是被设置为桥接端口的无线接口，因此没有具体的限制。

注意：我用了一个韦斯一对接口。用一个假的界面也可以使用，但我选择了韦斯一对接口有两个原因和一个额外的原因：

较老的ip路由2/内核版本tc ... action mirred无法重定向到入口但仅限于出口。 A韦斯一对接口充当方向逆变器：出口一侧变成入口另一方面，所以这个答案也适用于旧系统。
网络堆栈的工作方式（那里有示意图），这将使 AF_PACKET ( tcpdump) 捕获不对称：如入口发生在 AF_PACKET 克隆之后，tcpdump看不到入口流量重定向为入口在镜像接口上，同时在两个接口上都可以看到出口这发生在 AF_PACKET 之前。这个答案保留了通常的行为：在无线接口和其镜像接口（以及其镜像接口）上都可以看到两个方向。韦斯实际上不涉及的对等接口）。
奖金原因：nftables只得到了出口内核 5.16/5.17 中的支持可能仍然不可用。同样它也不能自由选择方向移动的框架的。和韦斯作为方向逆变器满足所有条件：仅需要入口到出口使得也可以替换交通管制和nftables。

镜像接口（或者对于韦斯此处的实现（镜像接口的另一侧）可以直接接收 IP 地址（包括使用 DHCP），但它将用作桥接端口（希望）解决 OP 的问题：应用程序需要一个桥接器。

准备

我将放弃一些必须由OP解决的细节：

设置不应远程完成，因为网络连接会暂时丢失。
OP 必须重新配置 Wifi，使其仅连接到 SSID，而不请求任何 IP 地址（无 IPv4 或 IPv6）、DNS 或其他自定义设置：这部分现在用于桥接接口。配置应始终在无线接口上保留相同的 MAC 地址，无论是原始永久地址还是本答案中的 12:34:56:78:9a:bc 之类的其他地址（非随机模式）。
集成到系统配置中必须由 OP 完成：此处仅提供手动设置。只有在无线连接后，网桥才会具有实际连接，因此不应过早地无用地启动。现在，通常的配置是在网桥上设置的（包括例如运行 DHCP 客户端）而不是无线接口。
br_netfilter不应加载内核模块。如果当前已加载，请避免任何副作用rmmod br_netfilter（因为Docker 破坏了 libvirt 桥接网络和许多桥梁设置）。

因此，让我们在更改之前定义示例配置。唯一相关的信息是无线接口名称wlp3s0及其 MAC 地址，在本例中为：12:34:56:78:9a:bc。

# ip link show dev wlp3s0
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 12:34:56:78:9a:bc brd ff:ff:ff:ff:ff:ff

脚步

使用首选网络配置工具重新配置 Wifi 以进行连接，并且不请求 IPv4 或 IPv6 的任何地址。

由 OP 执行此操作

vmbr0创建具有相同 MAC 地址的桥接接口wlp3s0并禁用特殊功能（以避免生成意外流量）

ip link add name vmbr0 address 12:34:56:78:9a:bc type bridge stp_state 0 forward_delay 0 mcast_snooping 0 mcast_router 0

或者如果它已经创建，请更改其设置：

ip link set dev vmbr0 down
ip link set dev vmbr0 address 12:34:56:78:9a:bc type bridge stp_state 0 forward_delay 0 mcast_snooping 0 mcast_router 0

创建一个韦斯接口vmbr0p1设置为的唯一桥接端口vmbr0，并且与其指定的对等链路也具有相同的 MAC 地址wlp3s0mirred（其 MAC 地址无关紧要）。
```
ip link add name vmbr0p1 address 12:34:56:78:9a:bc master vmbr0 type veth peer name wlp3s0mirred
```

重新配置wlp3s0和vmbr0p1/wlp3s0mirred不生成自己的流量，如 IPv6 SLAAC：这 3 个接口现在是桥接端口（或功能上等同于桥接端口）。

sysctl -w net.ipv6.conf.vmbr0p1.disable_ipv6=1
sysctl -w net.ipv6.conf.wlp3s0mirred.disable_ipv6=1
sysctl -w net.ipv6.conf.wlp3s0.disable_ipv6=1 #1st bullet should already have done this one

只是为了彻底（可选）：

ip link set dev wlp3s0 arp off
ip link set dev wlp3s0mirred arp off
ip link set dev vmbr0p1 arp off # this one is probably already forced by being a bridge port.

在下一批命令之前，接口必须已经存在。

重定向流量

重定向wlp3s0mirred的入口到wlp3s0的出口

使用TC

tc qdisc add dev wlp3s0mirred ingress
tc filter add dev wlp3s0mirred ingress matchall action mirred egress redirect dev wlp3s0

而不是上面，使用nftables

nft add table netdev hijack
nft add chain netdev hijack towireless '{ type filter hook ingress device wlp3s0mirred priority 0; policy accept; }'
nft add rule netdev hijack towireless fwd to wlp3s0

重定向wlp3s0的入口到wlp3s0mirred的出口

⚠️有一个问题：WPA 依赖于EAPOL以太网帧类型 0x888E。由于我们正在劫持帧，并且身份验证守护进程 ( wpa_supplicant) 无法被告知在网桥上读取它们，因为它无法被告知成功使用网桥，因此它仍在寻找上的 EAPOL 帧wlp3s0。必须首先添加一个例外，以使这些帧继续wlp3s0供wpa_supplicant消耗。否则，即使初始关联成功，仅使用最后一个过滤器完成的下一次重新生成密钥（不出现以下异常）也会失败（并且进一步的重新关联将不会成功）。看起来无线接口不断地连接和断开。
- 使用TC
```
tc qdisc add dev wlp3s0 ingress
tc filter add dev wlp3s0 ingress pref 1 protocol 0x888e matchall action pass
tc filter add dev wlp3s0 ingress pref 2 matchall action mirred egress redirect dev wlp3s0mirred
```
- 而不是上面，使用nftables
```
nft add table netdev hijack # already done but doesn't fail to write it again
nft add chain netdev hijack fromwireless '{ type filter hook ingress device wlp3s0 priority 0; policy accept; }'
nft add rule netdev hijack fromwireless ether type 0x888e accept
nft add rule netdev hijack fromwireless fwd to wlp3s0mirred
```

设置所有接口

ip link set dev vmbr0p1 up
ip link set dev wlp3s0mirred up
ip link set dev vmbr0 up

这个答案允许一件事：桥可以是系统上的主接口，并且可以用于交换普通的通过 Wifi 连接传输的流量与通过以太网连接使用的方式相同。

它不能保证的是，它将创建一个需要桥接器才能工作的专有应用程序，以实际工作：这实际上取决于它为什么需要桥接器。如果生成任何异常流量（将使用不同的源 MAC 地址）是原因，但很可能这仍然不起作用。

Answer

初步说明

作为@dirkt 已经写了，桥接限制是为了强制网络堆栈不会尝试（并且失败）通过无线接口发送具有不同源 MAC 地址的帧。有关此限制的详细信息可以在此 NE SE Q/A 中找到：802.11帧头中的四个二层地址。尽管链接的标题是默认情况下仅使用 3 个 MAC，并且接入点（“AP”）使用第三个 MAC 作为桥接器，而不是被视为简单端点的站客户端（“STA”）。缺席4号。切换到允许桥接 STA 的 4 地址模式（“4A”）也需要重新配置 AP 以支持 4A。例如主机通过为每个此类 STA 创建一个 4A 模式的附加本地克隆无线接口（必须对其网桥进行充分配置），可以像往常一样支持为普通 STA 提供服务，也可以为 4A 模式 STA 提供不同的服务。大多数公共客户 AP 不支持此功能（除非运行可重新配置的主机在引擎盖下和足够的 Wifi 硬件/固件）。

在OP的具体情况下，存在一个附加条件：网桥使用单个网桥端口，因此可以可以说仅假设一源 MAC 地址将来自网桥。如果桥接器配置了无线卡的 MAC 地址，则协议固有的限制在这种情况下不适用，但在这种特定情况下，无法告诉网络堆栈允许将无线接口设置为桥接端口。如果一个人只是想要另一个人界面（不是桥港) 表现得像这样，那么IPVLAN将是最简单的选择。

所以使用交通管制功能，将使用功能相当于集线器的解决方法：

获取传入无线接口的所有帧并将它们移动以显示传入镜像接口
获取从此镜像接口传出的所有帧并将它们移动到无线接口上，准备好传出（作为无线电波）。
配置网络堆栈以使用镜像接口而不是无线接口，或者这里使用此镜像接口（的韦斯对等）作为桥接端口来重现将无线接口设置为桥接端口。

然后，该虚拟“集线器”的另一个端口将作为 OP 情况下的桥接端口连接到实际的桥接器。内核不必禁止这一点，因为从技术上讲，它不是被设置为桥接端口的无线接口，因此没有具体的限制。

注意：我用了一个韦斯一对接口。用一个假的界面也可以使用，但我选择了韦斯一对接口有两个原因和一个额外的原因：

较老的ip路由2/内核版本tc ... action mirred无法重定向到入口但仅限于出口。 A韦斯一对接口充当方向逆变器：出口一侧变成入口另一方面，所以这个答案也适用于旧系统。
网络堆栈的工作方式（那里有示意图），这将使 AF_PACKET ( tcpdump) 捕获不对称：如入口发生在 AF_PACKET 克隆之后，tcpdump看不到入口流量重定向为入口在镜像接口上，同时在两个接口上都可以看到出口这发生在 AF_PACKET 之前。这个答案保留了通常的行为：在无线接口和其镜像接口（以及其镜像接口）上都可以看到两个方向。韦斯实际上不涉及的对等接口）。
奖金原因：nftables只得到了出口内核 5.16/5.17 中的支持可能仍然不可用。同样它也不能自由选择方向移动的框架的。和韦斯作为方向逆变器满足所有条件：仅需要入口到出口使得也可以替换交通管制和nftables。

镜像接口（或者对于韦斯此处的实现（镜像接口的另一侧）可以直接接收 IP 地址（包括使用 DHCP），但它将用作桥接端口（希望）解决 OP 的问题：应用程序需要一个桥接器。

准备

我将放弃一些必须由OP解决的细节：

设置不应远程完成，因为网络连接会暂时丢失。
OP 必须重新配置 Wifi，使其仅连接到 SSID，而不请求任何 IP 地址（无 IPv4 或 IPv6）、DNS 或其他自定义设置：这部分现在用于桥接接口。配置应始终在无线接口上保留相同的 MAC 地址，无论是原始永久地址还是本答案中的 12:34:56:78:9a:bc 之类的其他地址（非随机模式）。
集成到系统配置中必须由 OP 完成：此处仅提供手动设置。只有在无线连接后，网桥才会具有实际连接，因此不应过早地无用地启动。现在，通常的配置是在网桥上设置的（包括例如运行 DHCP 客户端）而不是无线接口。
br_netfilter不应加载内核模块。如果当前已加载，请避免任何副作用rmmod br_netfilter（因为Docker 破坏了 libvirt 桥接网络和许多桥梁设置）。

因此，让我们在更改之前定义示例配置。唯一相关的信息是无线接口名称wlp3s0及其 MAC 地址，在本例中为：12:34:56:78:9a:bc。

# ip link show dev wlp3s0
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 12:34:56:78:9a:bc brd ff:ff:ff:ff:ff:ff

脚步

使用首选网络配置工具重新配置 Wifi 以进行连接，并且不请求 IPv4 或 IPv6 的任何地址。

由 OP 执行此操作

vmbr0创建具有相同 MAC 地址的桥接接口wlp3s0并禁用特殊功能（以避免生成意外流量）

ip link add name vmbr0 address 12:34:56:78:9a:bc type bridge stp_state 0 forward_delay 0 mcast_snooping 0 mcast_router 0

或者如果它已经创建，请更改其设置：

ip link set dev vmbr0 down
ip link set dev vmbr0 address 12:34:56:78:9a:bc type bridge stp_state 0 forward_delay 0 mcast_snooping 0 mcast_router 0

创建一个韦斯接口vmbr0p1设置为的唯一桥接端口vmbr0，并且与其指定的对等链路也具有相同的 MAC 地址wlp3s0mirred（其 MAC 地址无关紧要）。
```
ip link add name vmbr0p1 address 12:34:56:78:9a:bc master vmbr0 type veth peer name wlp3s0mirred
```

重新配置wlp3s0和vmbr0p1/wlp3s0mirred不生成自己的流量，如 IPv6 SLAAC：这 3 个接口现在是桥接端口（或功能上等同于桥接端口）。

sysctl -w net.ipv6.conf.vmbr0p1.disable_ipv6=1
sysctl -w net.ipv6.conf.wlp3s0mirred.disable_ipv6=1
sysctl -w net.ipv6.conf.wlp3s0.disable_ipv6=1 #1st bullet should already have done this one

只是为了彻底（可选）：

ip link set dev wlp3s0 arp off
ip link set dev wlp3s0mirred arp off
ip link set dev vmbr0p1 arp off # this one is probably already forced by being a bridge port.

在下一批命令之前，接口必须已经存在。

重定向流量

重定向wlp3s0mirred的入口到wlp3s0的出口

使用TC

tc qdisc add dev wlp3s0mirred ingress
tc filter add dev wlp3s0mirred ingress matchall action mirred egress redirect dev wlp3s0

而不是上面，使用nftables

nft add table netdev hijack
nft add chain netdev hijack towireless '{ type filter hook ingress device wlp3s0mirred priority 0; policy accept; }'
nft add rule netdev hijack towireless fwd to wlp3s0

重定向wlp3s0的入口到wlp3s0mirred的出口

⚠️有一个问题：WPA 依赖于EAPOL以太网帧类型 0x888E。由于我们正在劫持帧，并且身份验证守护进程 ( wpa_supplicant) 无法被告知在网桥上读取它们，因为它无法被告知成功使用网桥，因此它仍在寻找上的 EAPOL 帧wlp3s0。必须首先添加一个例外，以使这些帧继续wlp3s0供wpa_supplicant消耗。否则，即使初始关联成功，仅使用最后一个过滤器完成的下一次重新生成密钥（不出现以下异常）也会失败（并且进一步的重新关联将不会成功）。看起来无线接口不断地连接和断开。
- 使用TC
```
tc qdisc add dev wlp3s0 ingress
tc filter add dev wlp3s0 ingress pref 1 protocol 0x888e matchall action pass
tc filter add dev wlp3s0 ingress pref 2 matchall action mirred egress redirect dev wlp3s0mirred
```
- 而不是上面，使用nftables
```
nft add table netdev hijack # already done but doesn't fail to write it again
nft add chain netdev hijack fromwireless '{ type filter hook ingress device wlp3s0 priority 0; policy accept; }'
nft add rule netdev hijack fromwireless ether type 0x888e accept
nft add rule netdev hijack fromwireless fwd to wlp3s0mirred
```

设置所有接口

ip link set dev vmbr0p1 up
ip link set dev wlp3s0mirred up
ip link set dev vmbr0 up

这个答案允许一件事：桥可以是系统上的主接口，并且可以用于交换普通的通过 Wifi 连接传输的流量与通过以太网连接使用的方式相同。

它不能保证的是，它将创建一个需要桥接器才能工作的专有应用程序，以实际工作：这实际上取决于它为什么需要桥接器。如果生成任何异常流量（将使用不同的源 MAC 地址）是原因，但很可能这仍然不起作用。

在 Debian Buster 上桥接 Wifi 不起作用

答案1

答案2

初步说明

准备

脚步

相关内容