安装Juniper Network Connect后EC2实例无法访问问题咨询

首先可以明确：免费套餐的单CPU实例性能不足大概率不是问题根源——Juniper Network Connect这类VPN客户端对资源消耗极低，t2.micro这类实例完全能承载。真正的问题几乎都是VPN客户端修改了系统网络配置导致的，具体来说：

核心原因 #

• 默认路由被强制修改：Juniper Network Connect在启动时通常会将系统的默认路由指向VPN隧道接口，而AWS EC2实例的公网访问依赖于AWS虚拟私有云（VPC）的默认网关。当默认路由被替换后，实例无法再与AWS的网络基础设施通信，自然就会失去远程连接能力，甚至连VPN本身都无法正常建立（因为初始化连接需要先访问VPN服务器的公网地址，路由变了之后连这个都走不通）。
• 防火墙/网络规则被篡改：部分VPN客户端会自动修改Windows防火墙规则，禁用本地网卡的入站/出站流量，或者直接阻断RDP（远程桌面）端口，导致你无法远程连接实例。

可行的解决办法 #

根据你的实例当前状态，分两种情况处理：

情况1：已配置AWS Systems Manager（SSM）代理 #

如果你的EC2实例之前安装并配置了SSM代理（默认Windows Server 2016 AMI可能自带，只要实例有访问SSM服务的权限），可以通过SSM Session Manager直接连接实例：

1. 登录AWS控制台，进入EC2服务，找到目标实例，右键选择「连接」→「Session Manager」标签页，点击「连接」。
2. 进入实例的命令行后，先尝试卸载Juniper Network Connect：

   # 查找VPN客户端的卸载命令（根据实际安装包调整）
   Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "*Juniper Network Connect*"} | ForEach-Object { $_.Uninstall() }
   

3. 如果卸载失败，手动恢复路由表：

   # 查看当前路由表，找到原来的默认网关（通常是VPC的网关地址，比如10.0.0.1）
   route print
   # 删除VPN添加的默认路由，添加回原默认路由
   route delete 0.0.0.0 mask 0.0.0.0 <VPN隧道网关>
   route add 0.0.0.0 mask 0.0.0.0 <VPC默认网关> metric 10
   

情况2：未配置SSM代理（只能通过挂载磁盘修复） #

如果无法通过SSM连接，只能通过挂载实例根卷到另一个正常的Windows EC2实例来修复：

1. 停止目标故障实例，在EC2控制台中分离它的根卷（注意记录卷的设备名称，比如/dev/sda1）。
2. 启动一个临时的Windows Server 2016实例，将分离的根卷挂载到这个临时实例上（作为额外磁盘）。
3. 登录临时实例，打开磁盘管理，将挂载的卷分配驱动器号。
4. 进入该卷的Windows目录，修改以下内容：
   • 删除VPN客户端的启动项：打开对应挂载卷的ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp路径，删除Juniper相关的快捷方式。
   • 清理VPN相关的网络驱动：打开设备管理器（显示隐藏设备），卸载Juniper的虚拟网卡驱动。
5. 卸载临时磁盘，重新挂载回原故障实例，启动实例即可恢复访问。

预防措施（避免再次出现） #

如果之后还要在EC2实例上使用该VPN，建议提前做好以下配置：

• 启用拆分隧道（Split Tunnel）：在Juniper VPN客户端的配置中，设置仅让特定业务流量走VPN隧道，保留默认路由指向VPC网关。具体操作需要联系你的VPN管理员获取配置权限，或者在客户端连接时选择「拆分隧道」选项（如果支持）。
• 添加静态路由保护AWS服务：在安装VPN前，手动添加静态路由，将AWS SSM、EC2元数据服务（169.254.169.254）等关键服务的流量指向VPC默认网关，这样即使VPN修改了默认路由，这些服务仍能正常访问，方便后续排查问题。

内容的提问来源于stack exchange，提问作者disasterkid