主页 / computer / 问题 / 1872316
Accepted
shadowpool
Asked: 2025-01-24 17:16:21 +0800 CST

当接口处于桥接状态时没有到主机的路由

  • 772

我目前遇到一个无法理解的问题，希望有人能帮助我。在互联网上快速搜索这个问题，得到的答案对我来说不起作用。

我来解释一下情况：

  • 我是一名 Windows 用户，使用 Hyper-V 来玩 Linux VM。
  • 我刚刚用最基本的软件包设置了 Debian 12 网络安装。
  • 我添加了“net-tools”和“bridge-utils”包。
  • VM 中只有一个网络接口：eth0（似乎可预测的设备名称为 Hyper-V 网络提供了“ethX”）。
  • 我通过 /etc/network/interfaces 配置了此接口。NetworkManager 或任何其他网络管理包均未安装。
  • 我的 VM 拥有 IP 192.168.100.128，并且我的 Windows 主机有一个拥有 192.168.100.1 的虚拟接口。
  • 在我的 Windows 上，有一个 HTTP 服务器正在监听 192.168.100.1 端口 1080。
  • Windows 防火墙允许来自/到虚拟网络接口的所有传入和传出流量。
  • 我也在旧的 Debian 11 VM 上运行了测试并得到了相同的结果。

配置1：直接接口，工作

在这里，我为接口配置一个 IPv4 地址，如下所示：

# File: /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet static
        address 192.168.100.128
        netmask 255.255.255.0

它运行并允许虚拟机到达网关（实际上是 Windows 中定义的虚拟网络适配器）。

# Here, I use ssh -v for debug purposes because a line explicitly tells me when TCP connection is established.
# ssh -v [email protected] -p 1080

OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.100.1 [192.168.100.1] port 1080.
debug1: Connection established.

配置 2：通过桥接，不工作

在这里，我将接口配置为具有 IPv4 地址的网桥成员，如下所示：

# File: /etc/network/interfaces

auto lo
iface lo inet loopback

iface eth0 inet manual

iface br0 inet static
        address 192.168.100.128
        netmask 255.255.255.0
        bridge_ports eth0

现在网络不工作，虚拟机似乎无法到达网关。

# ssh -v [email protected] -p 1080

OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.100.1 [192.168.100.1] port 1080.
debug1: connect to address 192.168.100.1 port 1080: No route to host
ssh: connect to host 192.168.100.1 port 1080: No route to host

不过，一切看上去都还好。

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.100.1   0.0.0.0         UG    0      0        0 br0
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 br0


# brctl show
bridge name bridge id       STP enabled interfaces
br0     8000.baa5ce5b1146   no      eth0


# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 00:15:5d:00:65:32 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ba:a5:ce:5b:11:46 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.128/24 brd 192.168.100.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::b8a5:ceff:fe5b:1146/64 scope link
       valid_lft forever preferred_lft forever

当我尝试连接到网关时在 VM 上启动 tcpdump 时，我看到很多 ARP 请求“谁有 IP 192.168.100.1”。

# tcpdunp -i br0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:10:08.275966 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:09.300152 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:10.323856 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:11.347906 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:12.371940 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:13.395793 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:14.419905 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:15.444155 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:18.516193 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:19.539804 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:20.563894 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
11:10:21.588085 ARP, Request who-has 192.168.100.1 tell 192.168.100.128, length 28
[...]

98 packets captured
101 packets received by filter
2 packets dropped by kernel
bridge

1 个回答

  1. Best Answer

    Hyper-V 不允许虚拟机伪造其 MAC 地址。

    • 桥接端口失去其身份，包括 IP 和 MAC；相反，桥接接口具有自己的 MAC 地址，并且只有该地址用于主机发起的所有数据包。

      有时（取决于创建接口的具体方法） br0 会自动继承添加到它的第一个端口的 MAC（即来自 eth0），但有时不会发生这种情况，它会获取一个随机生成的 MAC 地址，例如在您的情况下，它ba:a5:ce:5b:11:46代替了00:15:5d:00:65:32。

    • 当然，即使不是这种情况，通过桥接器的数据包也会保留其原始 MAC 地址（例如，桥接容器发送的数据包将具有该容器的 veth 的 MAC 地址）。

    这在 Hyper-V 中不起作用，因为默认情况下它只允许 VM 使用最初指定的 MAC 地址发送数据包。要使网桥正常工作，您需要在 VM 网络适配器的设置中激活“启用 MAC 地址欺骗” ：

    Hyper-V“虚拟机设置”的屏幕截图，显示选项

    • 9

相关问题