☰

Ubuntu VM 收到网络“目标主机无法访问”消息，但主机却可以访问网络

tag-icon • tag-icon networking ubuntu routing proxmox
Ubuntu VM 收到网络“目标主机无法访问”消息，但主机却可以访问网络

我会尽量简短地介绍。我在两个不同的站点上有两个 Proxmox 节点，每个节点都位于一个带有 Wireguard 站点到站点隧道的 pfSense 实例后面。每台 Proxmox 机器（除其他外）都有一个 Ubuntu VM。

在此处输入图片描述

Proxmox 主机可以互相 ping 通，但 Ubuntu VM 无法互相 ping 通，也无法与隧道另一端的主机 ping 通。但是，Ubuntu 计算机彼此之间能对隧道另一端的 pfSense 实例进行 ping 操作。

因此，例如 172.20.0.5 可以 ping 10.0.0.2，但不能 ping 192.168.1.100 或 192.168.1.2。

我检查了两端的防火墙日志，问题不在这里。此外，Ubuntu VM 与其他所有设备（WAN、站点 A 的其他网络等）都完全连通。我对网络还不太熟悉，但我看不出 Ubuntu 的路由表（如下）有什么问题 - 172.20.0.1 是默认路由，理应如此。

两台 Ubuntu 机器都已ufw禁用，并且 Proxmox 防火墙也已禁用。

有人能指出我解决这个问题的正确方向吗？

default via 172.20.0.1 dev ens18 proto dhcp metric 100 
169.254.0.0/16 dev ens18 scope link metric 1000 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-c9c0c48f2ded proto kernel scope link src 172.18.0.1 linkdown 
172.19.0.0/16 dev br-2aff47d248c2 proto kernel scope link src 172.19.0.1 linkdown 
172.20.0.0/24 dev ens18 proto kernel scope link src 172.20.0.6 metric 100 
172.21.0.0/16 dev br-0a0f137580ce proto kernel scope link src 172.21.0.1 
172.22.0.0/16 dev br-22040c89a1df proto kernel scope link src 172.22.0.1 
172.23.0.0/16 dev docker_gwbridge proto kernel scope link src 172.23.0.1 linkdown 
172.24.0.0/16 dev br-ae49b8c7a0cd proto kernel scope link src 172.24.0.1 
172.25.0.0/16 dev br-af1cc2da36b5 proto kernel scope link src 172.25.0.1 
172.26.0.0/16 dev br-f846820847c1 proto kernel scope link src 172.26.0.1 
172.28.0.0/16 dev br-c337d629bdd7 proto kernel scope link src 172.28.0.1 
172.31.0.0/16 dev br-25edfa50f590 proto kernel scope link src 172.31.0.1 linkdown 
192.168.0.0/20 dev br-cd125e7d0775 proto kernel scope link src 192.168.0.1 
192.168.48.0/20 dev br-d9efec41f6e6 proto kernel scope link src 192.168.48.1 
192.168.160.0/20 dev br-8934e4e75f8d proto kernel scope link src 192.168.160.1

答案1

我不知道为什么这是必要的，或者这是否是正确的解决方法，但我通过手动添加路线解决了这个问题：

地点A：sudo ip route add 192.168.1.0/24 via 172.20.0.1

站点 B：sudo ip route add 172.20.0.0/24 via 192.168.1.1

我只是希望知道为什么这在我的 Ubuntu VM 上是必要的，但在其他基于 Linux 或 BSD 的 VM 上却不需要。

尽管我读到的所有内容都坚持认为这netplan是使这些路由永久化的正确方法（即在重新启动后仍然存在），但我无法弄清楚这一点。我不确定为什么，但我的 YAML 文件缺少很多我认为应该有的配置。所以，我只是添加了@rebootcron 条目，如下所示： crontab -e->（在文件底部的新行上）@reboot sudo ip route add 192.168.1.0/24 via 172.20.0.1。

再说一次，我希望我知道这里发生了什么，但它确实有效。

相关内容