除非目标计算机重新启动后立即重置连接

除非目标计算机重新启动后立即重置连接

我遇到了一个奇怪的网络问题。我在办公室的 udp:1195 上设置了 VPN(将端口从 1194 改为了 1194)。

VPN服务器是10.9.0.1,我的客户端连接时接收10.9.0.2。

当 VPN 连接时,我可以从家里 ping 通 LAN 服务器 (10.217.50.0/24)。

我可以从局域网服务器(10.9.0.2)ping 我的VPN 客户端。

我总是可以从 LAN 服务器 ssh 到 VPN 客户端。(在 10.217.50.169 >> ssh 10.9.0.2)

我始终可以从 vpn 客户端通过 ssh 连接到 VPN 服务器的 LAN 或 VPN 地址。(在 10.9.0.2 >> ssh 10.9.0.1 或 ssh 10.217.50.9)

我总是可以从 vpn 客户端通过 ssh 连接到网关地址的 fios 路由器。(在 10.9.0.2 >> ssh 10.217.50.1)

如果目标服务器刚刚重启,我只能从 vpn 客户端 ssh 到 lan 服务器。(在 10.9.0.2 >> ssh 10.217.50.169)

如果我在机器重新启动后等待几秒钟,就会出现以下错误:

ssh [email protected]
kex_exchange_identification: read: Connection reset by peer
Connection reset by 10.217.50.169 port 22

工作路由器是 Verizon Fios G1100。我在其上设置了一条路由,允许 10.217.50.0/24 访问 10.9.0.0/24。

有任何想法吗?

我猜想机器上线几秒钟后我被路由器中的某些防火墙规则阻止了。

看来此路由器在防火墙 Web 配置上没有数据包过滤选项。我确实可以通过 ssh 访问防火墙,并且我已经从我的 VPN 确认,我可以从我的 VPN 客户端连接 ssh 到 VPN 网关 10.9.0.1 和路由器 10.217.50.1。

答案1

这听起来像是一个非常经典的路由/反向路由/安全问题。

ICMP(ping)消息用于诊断或控制目的。其错误被导向来源原始数据包的 IP 地址,因此 ICMP 数据包在两个方向上流动。

SSH 和其他 TCP 应用程序使用 TCP(三向)握手。问题就在这里:您的 VPN 客户端将数据发送到“服务器”(直接通过 VPN 服务器的 NIC)。服务器获取数据并根据其路由表向网络网关发送技术上正确的答案。但(安全)网关从未看到连接被启动,因此“未知”答案被阻止为“未启动”或“非法尝试”。这是完全正常的,防火墙应该阻止半答案的连接。

如何解决这个问题?

可以为所有服务器添加本地路由,在尝试访问 VPN LAN 时指向 VPN 网关。从技术上讲(作为网络管理员),这是“正确”的解决方案(因为不涉及其他组件),但管理起来却很麻烦。

您还可以检查您的 VPN 服务器和安全设备是否支持 ICMP 重定向(基本上是动态路由公告)。这或多或少无法完美运行。

您可以(也许应该)停止通过这个“自己的”vpn 绕过您的安全应用程序,而使用它提供的 VPN 解决方案。

相关内容