☰

KVM 的 Linux 桥接

tag-icon • tag-icon linux kvm-virtualization linux-networking bridge
KVM 的 Linux 桥接

我有一台 Debian Wheezy 机器，我试图在上面设置 KVM 桥接网络。不幸的是，桥接似乎无法正确转发流量。

我的设置如下：

物理机有一个eth0连接到 IP 地址为 192.168.0.1 的路由器的接口。
这eth0是桥接接口的成员br0，该接口静态配置为 IP 地址 192.168.0.101。
虚拟机的网络接口位于vnet0物理主机上和eth0虚拟机中。在虚拟机中，该接口静态配置为 IP 地址 192.168.0.110。

从物理主机，我可以 ping 虚拟机和路由器：

# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=0.331 ms

# ping 192.168.0.110
PING 192.168.0.110 (192.168.0.110) 56(84) bytes of data.
64 bytes from 192.168.0.110: icmp_req=1 ttl=64 time=0.417 ms

从虚拟机我可以 ping 物理机：

# ping 192.168.0.101:
PING 192.168.0.101 (192.168.0.101) 56(84) bytes of data.
64 bytes from 192.168.0.101: icmp_req=1 ttl=64 time=0.133 ms

但我无法 ping 通路由器：

# ping 192.168.0.1:
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.110 icmp_seq=10 Destination Host Unreachable

据我所知，网桥设置正确，所有连接端口均处于转发状态：

# brctl show
bridge name bridge id           STP enabled interfaces
br0         8000.2cd444acf8ad   no          eth0
                                            vnet0
# brctl showstp br0
br0
 bridge id               8000.2cd444acf8ad
 designated root         8000.2cd444acf8ad
 root port               0                    path cost        0
 max age                 20.00                bridge max age           20.00
 hello time              2.00                 bridge hello time         2.00
 forward delay           0.00                 bridge forward delay      0.00
 ageing time             300.01
 hello timer             1.20                 tcn timer                 0.00
 topology change timer   0.00                 gc timer                 28.95
 flags          


eth0 (1)
 port id            8001                state            forwarding
 designated root    8000.2cd444acf8ad   path cost              4
 designated bridge  8000.2cd444acf8ad   message age timer      0.00
 designated port    8001                forward delay timer    0.00
 designated cost       0                hold timer             0.20
 flags          

vnet0 (2)
 port id            8002                state            forwarding
 designated root    8000.2cd444acf8ad   path cost            100
 designated bridge  8000.2cd444acf8ad   message age timer      0.00
 designated port    8002                forward delay timer    0.00
 designated cost       0                hold timer             0.20
 flags

iptables和均为ebtables空，且采用默认策略ACCEPT：

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   
# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

有人知道是什么原因导致了这个问题以及我该如何解决它吗？

编辑：

显然，网桥认识到有东西与其相连，因为它建立了一个 MAC 表：

# brctl showmacs br0
port no mac addr            is local?   ageing timer
  1     2c:76:8a:ff:88:1d   no            1.28   <- ???
  1     2c:d4:44:ac:f8:ad   yes           0.00   <- MAC of br0 and physical eth0
  2     52:54:00:53:dd:34   no          143.80   <- MAC of VM's eth0
  1     c8:1f:66:ba:83:33   no            0.00   <- MAC of router interface
  2     fe:54:00:53:dd:34   yes           0.00   <- MAC of vnet0

编辑2：

我刚刚创建了第二台虚拟机。这台虚拟机在物理机上有接口 vnet1，其虚拟 eth0 被分配了 IP 地址 192.168.0.111。这台虚拟机也只能 ping 物理机，而不能 ping 路由器或原始虚拟机。brctl showstp显示所有端口（包括 vnet1）处于转发状态，并brctl showmacs显示 vnet1 和新机器虚拟 eth0 的 MAC，以及我上面写的内容。

答案1

检查内核是否设置为启用IP转发：

sysctl -a | grep forwarding

您可以通过以下方式启用：

sudo sysctl net.ipv4.conf.all.forwarding=1
sudo sysctl net.ipv6.conf.all.forwarding=1

ARP 代理也可能存在问题。检查：

sysctl -a | grep proxy_arp

并使用以下命令设置：

sudo sysctl net.ipv4.conf.eth0.proxy_arp=1

您可以将键和值放在下面的文件中，/etc/sysctl.d以便在重新启动时重置这些值。

从路由器子网上的另一台设备进行测试可能有助于确定问题。

  • 对虚拟机进行 ping 操作可能会提供有用的诊断信息。
  • 检查虚拟机是否可以进行 ARP 操作将表明您是否可以找到服务器的 MAC 地址。ping 后使用“arp -a”查看是否成功找到 MAC 地址。
  • 跟踪路由可能指出问题的起点。

tcpdump在接口上进行测试eth0也可能指出连接失败的位置。

  • 重复arp请求而没有得到有效响应表明存在可达性问题。
  • 缺失echo或echo reply交通可能表明哪一侧存在问题。
  • 对路由器或其后面的地址的跟踪路由响应可能会提供额外的信息。

答案2

我知道它有点过时，也有点 OT，但我想在这里记录我的解决方案。如果您最近安装dockerd到工作设置中，则可能需要卸载它。

我有一个运行了几年的 KVM 设置，然后它在重启后停止工作。在浏览了这里的清单后，我注意到已iptables被修改。仔细检查后发现已被iptables修改dockerd。卸载 Docker 使 Linux 桥接网络和虚拟机恢复到工作状态。

相关内容