安装 VPN 客户端后 RDP 停了？问题在防火墙

面向消费者的 VPN 客户端装完几分钟后，门户仍显示 VM 正在运行，公网 IP 没有变化，可 RDP 就是连不上。人们通常以为 VM 崩溃了，或者网络安全组被改动了，这两种猜测往往都不对。真正变化的是这台机器所处的 Windows 防火墙配置文件，原来匹配的 RDP 规则不再匹配。修复要从一条不依赖 RDP 的通道拿到 shell 开始。

VM 在运行，规则却不匹配了

Windows 防火墙规则带有一组配置文件，限定在专用或域的规则，在机器处于公用配置文件时不生效。VPN 安装程序会添加适配器和路由，其中好几个还会顺带加固公用配置文件。监听仍然绑定 3389，数据包也照常到达，但配置文件不匹配会把它们丢掉。

电源状态和可达性是两回事，一台在运行但端口关闭的 VM，从外面看和崩溃的机器一模一样。

先探测端口，再动手改动。连接 3389 超时，而来宾代理命令仍能返回输出，这说明问题在主机防火墙。端口有响应但 RDP 仍然失败，说明故障在网络层之上，这次修复碰不到它。记下你看到的是哪一种，后面的方案取决于它。

两道门各自独立关闭

先运行的是平台策略：网络安全组在来宾之前看到数据包。这个顺序使得主机丢弃数据包时，再完美的 NSG 条目也没用；平台拒绝时，主机上放开的规则同样没用。把它们当成两道独立的门，各自单独验证。

在门户或 CLI 里读取 NSG 的实际生效规则，再与来宾自身的规则对照。不要假定你记得的最后一次改动就是已经生效的那次。

消费级客户端还可能装上过滤器驱动或断网开关，在 Windows 防火墙以下拦截流量。如果防火墙规则看起来正确，端口却仍然失败，下一层就是嫌疑对象。

把来宾代理当作回到机器的通路

Run Command 和 Custom Script Extension 这两项远程执行能力，通过平台代理在来宾内部运行。它们都不需要 RDP，所以防火墙的误配置影响不到它们。两者都会返回脚本输出，因此既是诊断通道，也是修复通道。

改动其中任何一项之前，先读当前配置文件和 RDP 规则：

Get-NetConnectionProfile
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

在该配置文件上重新启用入站规则只是临时措施，不是终点。用它拿到会话，然后老老实实把缺口补上：

Set-NetFirewallProfile -Name Public -AllowInboundRules True

那个开关会打开该配置文件上的每一条入站规则，而不只是 RDP。拿到会话后，换成一条限定范围的规则，并把手头真正需要的设置恢复回去。如果代理也不可用，退路就是串行控制台或重建磁盘，这也是保持代理健康的现实理由。

关闭会话之前先把缺口收窄

临时改配置文件的动作，等于为这个配置文件上的每条入站规则开了一扇门。把它换成一条限定来源地址和 RDP 端口的规则，再确认配置文件回到预期状态。趁会话还在时做完这件事，因为下一次失误未必能远程挽回。改动期间手边要留好第二条管理通道，比如 Bastion 或串行控制台。

从工作站用端口测试确认结果，从来宾内部用规则列表确认：

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

测试期间打开防火墙日志。一行丢包记录如果写明 3389 和当前配置文件，比再重启一次更快给出答案。

别让下一个安装程序故技重施

如果那台主机没有理由跑这个客户端，就把它卸掉。装着的客户端等于长期邀请下一次更新再改一遍配置文件，下一个人还得从门户上排查同样的中断。

在让任何东西改写网络设置之前先给磁盘做快照，并在需要之前就准备好第二条管理通道。

记录安装程序改了什么：适配器、路由、防火墙配置文件、过滤器驱动和服务。这份记录能把下一次事故变成已知模式，而不是从头调查。当 VM 只需要通往某一个服务的隧道时，把客户端装在自己的工作站上，或者建一条站点到站点链路，而不是在服务器上装笔记本产品。消费级客户端面向笔记本，而你远程管理的服务器并不是笔记本。