我遇到了一个奇怪的网络问题。我在办公室的 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 解决方案。