☰

VPN 在 VM 来宾中有效，但在 VM 主机中无效

tag-icon • tag-icon networking vpn
VPN 在 VM 来宾中有效，但在 VM 主机中无效

我有一个交换机，该交换机有 3 根连接电缆。

NAS PC 互联网

我的 VPN 使用 SonicWall，并且使用 NetExtender。最重要的是，我使用完全相同的程序以相同的凭据进行连接。两者均报告已连接并通过 IP 传输流量。

我觉得这里重要的一点是，当连接到 VPN 时，我无法连接到我的 NAS，如果我已经连接，该连接将被阻止并且不再有效。我通过“LinkOnly”连接连接到我的 NAS。没有其他办法可以/不会起作用。

但是，在访客上我可以访问 VPN 后面的页面。但在主机上我不能。来宾具有使用 VmWare Workstation v16 的 NAT 连接网络适配器。

我要求 IT 检查失败请求的日志，结果显示： some 403s just after I asked you to hit turo-green with an x-forwarded-for header value of 2a01:4b00:86f0:e00:6c71:9e79:XXX:9597, 64.252.XX.126. The 1st IP is hyperoptic (I guess thats the ISP for you apartment or block of apartments), the 2nd is AWS cloudfront

当挖掘一点点时curl ifconfig.co给予2a01:4b00:86f0:e00:6c71:9e79:e8d:9597但应该给予195.114.XXX.217

Before connection 

(base) hutber@hutber:~$ ip route 
default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
169.254.0.0/16 dev enp2s0 proto kernel scope link src 169.254.168.22 metric 100 
169.254.0.0/16 dev enp8s0 proto kernel scope link src 169.254.59.152 metric 101 
169.254.0.0/16 dev wlo1 scope link metric 1000 
172.16.64.0/24 dev vmnet8 proto kernel scope link src 172.16.64.1 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.104 metric 600 
192.168.246.0/24 dev vmnet1 proto kernel scope link src 192.168.246.1 
224.0.0.0/4 dev enp2s0 proto static scope link metric 100 
224.0.0.0/4 dev enp8s0 proto static scope link metric 101 

After connecting    

(base) hutber@hutber:~$ ip route
default via 10.xx.57.3 dev ppp0 scope link 
default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
10.0.0.0/8 via 10.xx.57.3 dev ppp0 scope link 
128.0.0.0/1 via 10.xx.57.3 dev ppp0 scope link 
169.254.0.0/16 via 10.x.57.3 dev ppp0 scope link 
169.254.0.0/16 dev enp2s0 proto kernel scope link src 169.254.168.22 metric 100 
169.254.0.0/16 dev enp8s0 proto kernel scope link src 169.254.59.152 metric 101 
169.254.0.0/16 dev wlo1 scope link metric 1000 
172.16.64.0/24 via 10.xx.57.3 dev ppp0 scope link 
172.16.64.0/24 dev vmnet8 proto kernel scope link src 172.16.64.1 
192.0.2.1 via 10.xx.57.3 dev ppp0 scope link 
192.0.2.1 dev ppp0 proto kernel scope link src 10.10.57.3 
192.168.1.0/24 via 10.xx.57.3 dev ppp0 scope link 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.104 metric 600 
192.168.1.1 dev wlo1 scope link 
192.168.246.0/24 via 10.10.57.3 dev ppp0 scope link 
192.168.246.0/24 dev vmnet1 proto kernel scope link src 192.168.246.1 
195.114.XX.217 via 192.168.1.1 dev wlo1 
224.0.0.0/4 via 10.xx.57.3 dev ppp0 scope link 
224.0.0.0/4 dev enp2s0 proto static scope link metric 100 
224.0.0.0/4 dev enp8s0 proto static scope link metric 101

您可能会想，他为什么不直接问 IT。嗯，IT 不支持 Linux，我因为使用​​ OSX 感到非常沮丧（抱歉）

hutber@hutber:~$ curl --interface ppp0 ifconfig.co
195.114.103.217

据我所知，我的主机上没有防火墙。

[编辑]

所以我相信我需要创建一个 ip 路由来映射此 IP 195.114.XX.217 via 192.168.1.1 dev wlo1，192.168.1.1但是我的 VPN 无法连接，169.254.168.22所以我想这是因为 VPN 正在隧道传输所有流量？

在此输入图像描述

在此输入图像描述

答案1

阅读了相关评论后，我认为@larsks 已经对此进行了排序。

好吧，让我尝试扩展它：

从第一个路由表：

  1. 您有一个无线 (wlo1) 和两个以太网（enp2s0、enp8s0）接口。
  2. 由于我未知的原因，您有一个多播地址，也许是一些流媒体软件（纯粹是猜测）。
  3. 由于我未知的原因，您拥有链路本地 IPv4 地址（子网 169.254.0.0/16）。您将它们都连接到某些设备，您的接口的 IP 地址为 169.254.168.22 (enp2s0) 和 169.254.59.152 (enp8s0)。我推测是一些像 avahi mDNS 这样的软件。 Note：我只在没有运行 DHCP 服务器的计算机之间看到这些 Windows DHCP 配置连接（例如，只是交换机或直接链接），它可以被认为是自动后备 IP 地址。
  4. 您通过 Wi-Fi (wlo1) 连接到路由器（又名无线家庭调制解调器）。您的 IP 地址是 192.168.1.104，其（网关）IP 地址是子网 192.168.1.0/24 内的 192.168.1.1。Note：如有疑问，请假设路由器（作为网关）至少使用以下地址之一进行操作：CIDR 表示法中的 192.168.0.1/24、192.168.1.1/24、192.168.100.1/24。我遇到过一些家庭路由器通过占用两个子网来重定向到正确的子网。
  5. 您有两个正在运行的虚拟机，它们具有不同的虚拟网络（192.168.246.0/24、172.16.64.0/24）。它们是 NAT 网络，您的计算机（虚拟机管理程序）是这些网络中的网关。 Hypervisor 的 IP 分别为 192.168.246.1 和 172.16.64.1。

根据之前的观察，根据第二个路由表：

  1. 出于某种原因，您现在知道 Wi-Fi 是访问 NAS (195.114.XX.217) 的接口。我怀疑您只是在之前的输出之前没有连接，VPN 没有什么特别的。
  2. 您所谓的 mDNS 客户端（负责 169.254.0.0/16）在 ppp0 上尝试了运气，就像之前在 wlo1 上所做的那样。又没什么特别的了。
  3. 您的 VPN (ppp0) 已添加 10.0.0.0/8、128.0.0.0/1、192.0.2.1/24 的路由。192.168.1.0/24（全部通过您的 VPN IP 地址 10.XX.57.3）。Note：只要您有互联网连接来连接到 VPN 服务器，您的 VPN 地址就可以使用。因此，所有这些网络都取决于您的家庭网络是否正常运行。那个大胆的子网很麻烦，稍后会详细介绍。
  4. 您的虚拟网络正在通过您的 VPN IP 地址 (10.XX.57.3) 进行通告，这可能是由于 NAT 的工作原理所致。一个数据包来自对方（任何上述子网）是否可以通过这种方式路由回适当的虚拟机；几乎肯定首先有一个由虚拟机发起的连接。

分析完所有这些后，问题就出在这些地方：

default via 10.xx.57.3 dev ppp0 scope link 
default via 192.168.1.1 dev wlo1 proto dhcp metric 600

192.168.1.0/24 via 10.xx.57.3 dev ppp0 scope link 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.104 metric 600

您的计算机无法连接到家庭路由器（192.168.1.1），因为它尝试通过 ppp0 接口进行连接，而该接口的路由器以某种方式无法访问，至少从计算机的角度来看是这样。

我怀疑 ppp0 接口不会永远循环数据包，而是在第一次循环后丢弃它们，而是出于性能原因尝试下一个接口 (wlo1)。再次纯属猜测。

然而，如果您的 wlo1 优先级高于 ppp0（较小的整数），您将保留家庭 LAN 连接，从而保留 NAS 和 VPN 连接。但请注意，VPN 上的 192.168.1.0/24 不起作用，因为它会被您的家庭 LAN 遮蔽。

我建议您将路由器设备的 Wi-Fi 配置下的家庭 LAN 子网更改为上面未写的某个子网。我建议使用符合 192.168.XXX.1/24 形式的内容。

PS 我再次推测，但我认为您在编辑 VPN 连接后的路由表后能够连接到 NAS，因为您已经有以下行：

195.114.XX.217 via 192.168.1.1 dev wlo1

因此，当您查找 195.114.XX.217 时，表条目意味着它应该经过 192.168.1.1。 wlo1 上的 IP 地址为 192.168.1.104/24，它是到 192.168.1.1 的 LAN 连接，并且数据包可以在没有网关的情况下发送，而且确实如此。如果您尝试任何其他地址，您将不知道通过 192.168.1.1（网关）发送它并失败，因此没有互联网，但有 NAS 连接。这是我最好的猜测。

如果这作为答案令人满意，也请投票@larsks 的评论。他就是灯塔。

相关内容