RDP detense despois de instalar un cliente VPN? A culpa é do firewall

Poucos minutos despois de que un cliente VPN de consumo remate a instalación, o portal segue dicindo que a VM está en marcha, a IP pública non cambiou e RDP non responde. A xente adoita supoñer que a VM caeu ou que cambiou o grupo de seguridade de rede, e ambas cousas adoitan ser falsas. O que cambiou é o perfil do firewall de Windows no que está a máquina, e a regra de RDP que antes coincidía xa non coincide. A reparación comeza por obter un shell por unha vía que non dependa de RDP.

A VM está en marcha; a regra deixou de coincidir

As regras do firewall de Windows levan un conxunto de perfís, e unha regra limitada a Privado ou Dominio non ten efecto mentres a máquina está no perfil Público. Os instaladores de VPN engaden adaptadores e rutas, e varios endurecen o Público como efecto secundario. O oínte segue ligado ao 3389 e os paquetes seguen chegando, pero o desaxuste de perfil descártaos.

O estado de enerxía e a accesibilidade son feitos distintos, e unha VM en marcha cun porto pechado parece desde fóra exactamente unha caída.

Probe o porto antes de tocar nada. Un intento de conexión ao 3389 que expira mentres unha orde do axente convidado aínda devolve saída apunta ao firewall do host. Un porto que responde mentres RDP segue fallando significa que o fallo está por riba da capa de rede, e esta reparación non o tocará. Anote cal dos dous casos viu, porque o resto do plan depende diso.

Dúas portas péchanse de forma independente

A política da plataforma vai primeiro: o grupo de seguridade de rede ve o paquete antes que o convidado. Ese orde fai inútil unha entrada de NSG perfecta cando o host descarta o paquete, e inútil unha regra de host aberta cando a plataforma a denega. Tráteos como portas separadas e probe cada unha pola súa conta.

Lea as regras efectivas do NSG no portal ou na CLI e despois compáreas coas regras propias do convidado. Non supoña que o último cambio que recorda é o que entrou en vigor.

Un cliente de consumo tamén pode instalar un controlador de filtro ou un interruptor de emerxencia que bloquea o tráfico por debaixo do firewall de Windows. Se as regras do firewall parecen correctas e o porto segue fallando, esa capa é o seguinte sospeitoso.

Use o axente convidado como vía de volta

Dúas funcións de execución remota, Run Command e a Custom Script Extension, execútanse dentro do convidado mediante o axente da plataforma. Ningunha necesita RDP, así que o erro do firewall non as afecta. Ambas devolven a saída do script, o que as converte en canle de diagnóstico e tamén de reparación.

Lea o perfil activo e a regra de RDP antes de cambiar calquera dos dous:

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

Reactivar as regras de entrada nese perfil é unha medida temporal, non un destino. Úsea para conseguir unha sesión e despois peche o oco correctamente:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Ese interruptor abre todas as regras de entrada do perfil, non só RDP. Cando teña unha sesión, substitúao por unha regra limitada e restaure os axustes que realmente quere. Se o axente tampouco está dispoñible, a alternativa é unha consola serie ou un disco reconstruído, e esa é a razón práctica para manter o axente san.

Estreite o oco antes de pechar a sesión

O cambio temporal de perfil é unha porta aberta a todas as regras de entrada dese perfil. Substitúao por unha regra limitada ao seu enderezo de orixe e ao porto RDP, e despois confirme que o perfil volveu ao seu estado previsto. Fágao mentres aínda ten a sesión, porque o seguinte erro pode non ser reversible en remoto. Manteña unha segunda vía administrativa como Bastion ou unha consola serie durante o cambio.

Confirme o resultado desde a súa estación de traballo cunha proba de porto, e desde dentro do convidado coa lista de regras:

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

Active o rexistro do firewall durante a proba. Unha soa liña de paquete descartado que nomee o 3389 e o perfil activo responde a pregunta máis rápido que outro reinicio.

Evite que o seguinte instalador o volva facer

Se ese host non ten motivo para executar o cliente, desinstáleo. Un cliente instalado é unha invitación permanente a que a próxima actualización reescriba o perfil outra vez, e a seguinte persoa depurará a mesma caída desde o portal.

Faga unha instantánea do disco antes de deixar que algo reescriba a configuración de rede, e teña unha segunda vía administrativa lista antes de necesitala.

Anote que modificou o instalador: adaptadores, rutas, perfís de firewall, controladores de filtro e servizos. Ese rexistro converte o seguinte incidente nun patrón coñecido en lugar dunha investigación nova. Cando a VM necesite un túnel cara a exactamente un servizo, poña o cliente na súa estación de traballo ou monte unha ligazón sitio a sitio en vez de instalar no servidor un produto para portátiles. Os clientes de consumo apuntan a portátiles, e un servidor que administra en remoto non o é.