O RDP para depois de instalar um cliente VPN? É o firewall

Poucos minutos depois de o cliente VPN de consumo terminar a instalação, o portal continua a dizer que a VM está em execução, o IP público não mudou e o RDP não responde. As pessoas costumam supor que a VM falhou ou que o grupo de segurança de rede mudou, e ambas as hipóteses costumam estar erradas. O que mudou foi o perfil do firewall do Windows em que a máquina está, e a regra de RDP que antes correspondia já não corresponde. A reparação começa por obter uma shell por um caminho que não dependa do RDP.

A VM está em execução; a regra deixou de corresponder

As regras do firewall do Windows têm um conjunto de perfis, e uma regra limitada a Privado ou Domínio não tem efeito enquanto a máquina está no perfil Público. Os instaladores de VPN acrescentam adaptadores e rotas, e vários endurecem o Público como efeito secundário. O ouvinte continua ligado à 3389 e os pacotes continuam a chegar, mas a discrepância de perfil descarta-os.

O estado de energia e a acessibilidade são factos distintos, e uma VM em execução com uma porta fechada parece de fora exatamente como uma que falhou.

Teste a porta antes de alterar qualquer coisa. Uma tentativa de ligação à 3389 que expira enquanto um comando do agente convidado ainda devolve saída aponta para o firewall do anfitrião. Uma porta que responde enquanto o RDP continua a falhar significa que a avaria está acima da camada de rede, e esta reparação não lhe tocará. Anote qual dos dois casos viu, porque o resto do plano depende disso.

Duas portas fecham-se de forma independente

A política da plataforma vem primeiro: o grupo de segurança de rede vê o pacote antes do convidado. Essa ordem torna uma entrada de NSG perfeita inútil quando o anfitrião descarta o pacote, e uma regra de anfitrião aberta inútil quando a plataforma a recusa. Trate-as como portas separadas e teste cada uma por si.

Leia as regras efetivas do NSG no portal ou na CLI e depois compare-as com as regras do próprio convidado. Não presuma que a última alteração de que se lembra é a que entrou em vigor.

Um cliente de consumo também pode instalar um controlador de filtro ou um kill switch que bloqueia tráfego abaixo do firewall do Windows. Se as regras do firewall parecerem corretas e a porta continuar a falhar, essa camada é o próximo suspeito.

Use o agente convidado como caminho de regresso

Duas funcionalidades de execução remota, o Run Command e a Custom Script Extension, correm dentro do convidado através do agente da plataforma. Nenhuma precisa de RDP, por isso o erro do firewall não as afeta. Ambas devolvem a saída do script, o que as torna num canal de diagnóstico e também de reparação.

Leia o perfil ativo e a regra de RDP antes de alterar qualquer um deles:

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

Reativar as regras de entrada nesse perfil é uma medida temporária, não um destino. Use-a para obter uma sessão e depois feche a abertura como deve ser:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Esse interruptor abre todas as regras de entrada do perfil, não apenas o RDP. Assim que tiver uma sessão, substitua-o por uma regra limitada e reponha as definições que realmente quer. Se o agente também estiver indisponível, a alternativa é uma consola série ou um disco reconstruído, e essa é a razão prática para manter o agente saudável.

Reduza a abertura antes de fechar a sessão

A alteração temporária de perfil é uma porta mantida aberta a todas as regras de entrada desse perfil. Substitua-a por uma regra limitada ao seu endereço de origem e à porta de RDP, e depois confirme que o perfil voltou ao estado previsto. Faça-o enquanto ainda tem a sessão, porque o próximo erro pode não ser reversível remotamente. Mantenha um segundo caminho administrativo, como o Bastion ou uma consola série, durante a alteração.

Confirme o resultado a partir da sua estação de trabalho com um teste de porta, e de dentro do convidado com a lista de regras:

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

Ative o registo do firewall durante o teste. Uma única linha sobre um pacote descartado que nomeie a 3389 e o perfil ativo responde à pergunta mais depressa do que outro reinício.

Impeça o próximo instalador de o fazer outra vez

Se esse anfitrião não tem motivo para executar o cliente, desinstale-o. Um cliente instalado é um convite permanente para a próxima atualização reescrever o perfil outra vez, e a próxima pessoa vai depurar a mesma falha a partir do portal.

Tire um instantâneo do disco antes de deixar algo reescrever as definições de rede, e mantenha um segundo caminho administrativo pronto antes de precisar dele.

Anote o que o instalador alterou: adaptadores, rotas, perfis de firewall, controladores de filtro e serviços. Esse registo transforma o próximo incidente num padrão conhecido em vez de uma nova investigação. Quando a VM precisa de um túnel para exatamente um serviço, ponha o cliente na sua estação de trabalho ou monte uma ligação local a local em vez de instalar no servidor um produto para portáteis. Os clientes de consumo destinam-se a portáteis, e um servidor que administra remotamente não é isso.