☰

当服务器连接到 openVPN 服务时，无法通过 VPN 隧道远程访问服务器

tag-icon • tag-icon networking router ssh vpn openvpn
当服务器连接到 openVPN 服务时，无法通过 VPN 隧道远程访问服务器

我创建了一条通往家庭 LAN 的 VPN 隧道。VPN 隧道已成功建立，因为我可以访问路由器的网关。

我可以ssh访问网络上的一台服务器 ( 192.168.1.113)。我在本地测试了此连接，它正常工作。但是，服务器本身正在使用 VPN，因此其公共 IP 地址与 LAN 的公共 IP 不同。

问题是我无法192.168.1.113在 VPN 隧道打开的情况下远程 ssh 进入。对服务器执行 ping 操作会导致：

PING 192.168.1.113 (192.168.1.113): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- 192.168.1.113 ping statistics ---
135 packets transmitted, 0 packets received, 100.0% packet loss

作为测试，我关闭了 VPN 192.168.1.113，它运行正常。我可以使用 VPN 隧道进行远程连接。但为什么会发生这种情况呢？如果我通过隧道连接到我的 LAN，那应该意味着我是 LAN 上的另一个设备。与物理上在那里没什么不同，对吧？

一些细节

  • 路由器：Archer C7 搭配 OpenVPN 服务器
  • 192.168.1.113使用 openVPN 和 protonVPN 配置文件

更新

当从隧道远程访问路由器网关时，我的远程电脑在 LAN 网络设备下不可见。但它在 VPN 连接下可见，信息如下：

  • 远程 IP：84.185.102.210
  • 分配的 IP：10.8.0.6
  • 分配的 IP 是 openVPN 子网/网络掩码的一部分：10.8.0.0/24

更新 2

从 VPN 隧道ping 时tcpdump查看显示：sudo tcpdump -eni any icmp192.168.1.113

12:29:21.027220 eth0  In  ifindex 2 e8:48:b8:e1:57:1a ethertype IPv4 (0x0800), length 104: 10.8.0.6 > 192.168.1.113: ICMP echo request, id 45097, seq 32, length 64
12:29:21.027357 tun0  Out ifindex 1063 ethertype IPv4 (0x0800), length 104: 192.168.1.113 > 10.8.0.6: ICMP echo reply, id 45097, seq 32, length 64
12:29:22.004265 eth0  In  ifindex 2 e8:48:b8:e1:57:1a ethertype IPv4 (0x0800), length 104: 10.8.0.6 > 192.168.1.113: ICMP echo request, id 45097, seq 33, length 64
12:29:22.004411 tun0  Out ifindex 1063 ethertype IPv4 (0x0800), length 104: 192.168.1.113 > 10.8.0.6: ICMP echo reply, id 45097, seq 33, length 64

更新 3

在 Mac 机器上使用arp -a来检查网络上的其他设备，当我在隧道上时没有显示任何其他设备。直接在 LAN 上尝试相同的命令会显示我想要连接的服务器。

答案1

但为什么会发生这种情况？如果我通过隧道连接到我的 LAN，那应该意味着我是 LAN 上的另一个设备。与物理上在那里没什么不同，对吧？

你是不完全是在您的 LAN 上。VPN 是一个与您的 LAN 互连的独立子网，但从服务器的角度来看，它仍然是一个“远程”网络。

服务器始终具有本地路由192.168.1.0/24（它所在的网络），但很可能没有路由10.8.0.0/24- 它依赖于默认路由来到达该路由（因为无论如何它仍然通过同一个路由器）。

但是，当服务器连接到 VPN 时，其主要默认路由不再是通过 Archer，而是通过 VPN。因此，每当服务器收到来自 10.8.0.6 的数据包时，它尝试通过 VPN 进行响应（在某个时候丢弃数据包）。您可以在 tcpdump 中看到“ICMP Echo Reply”数据包是正在发送，但它们是通过“tun0”设备而不是以太网发送的。

基本 IP 路由是针对每个数据包的，而不是针对每个连接的，并且响应是不是自动按照与初始数据包相同的方式路由 – 服务器独立于提示它们的任何入站数据包路由其出站数据包。（换句话说，路由可以是不对称的。）

就您而言，避免这种情况的最简单方法是在服务器上为 10.8.0.0/24 定义一条特定路由，这样即使 VPN 已启动，到达此目的地的数据包也将始终通过 Archer。（更具体的路由始终优先于不太具体的路由；您无需设置特定指标或任何其他内容。）

在更复杂的设置中（例如，如果客户端地址不可预测且不仅限于 VPN /24），您可以使用 iptables 或 nftables 规则将“标记”应用于入站连接，并ip rule根据出站数据包是否属于标记为本地的连接来选择几条默认路由之一。

相关内容