Porque é que o RDP congela quando o computador remoto se liga a uma VPN

Está dentro da janela do RDP, o ambiente de trabalho está no ecrã e prime Connect no cliente VPN que corre nessa máquina remota. Segundos depois a janela congela e fecha-se. O túnel subiu, que é exatamente o que o registo da VPN vai reportar, e esse é o facto menos útil de todo o incidente. A sessão morreu porque a máquina com quem falava mudou a forma como lhe responde, por isso reveja o caminho de regresso antes de tocar no túnel.

Registe o endpoint que a sua sessão utiliza realmente

O endereço escrito no cliente RDP não é necessariamente o endereço a que o computador remoto responde. O NAT, um RD Gateway ou um balanceador de carga à frente do anfitrião podem reescrevê-lo, e o caminho de regresso é definido pelo endereço de origem que a máquina remota vê na ligação estabelecida. Enganar-se aqui manda-o procurar uma rota que nunca esteve envolvida.

No computador remoto, antes de a VPN estar ligada, liste as sessões estabelecidas e leia o endereço do par na tabela. Depois anote-o num sítio fora dessa máquina, porque não o conseguirá ler depois de a sessão cair.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Trate esse endereço como aquilo que tem de continuar alcançável. Se for um endereço privado numa VLAN de gestão, o túnel tem de deixar esse caminho em paz. Se for um endereço público, a resposta tem de sair pela mesma interface que trouxe o pedido para dentro.

Leia a rota que responde a esse endpoint

O Windows escolhe uma interface por destino, e o Find-NetRoute mostra a decisão que ele tomaria agora. Execute-o contra o endereço do par antes de ligar, depois outra vez com o túnel em cima, e compare o índice de interface e o salto seguinte nas duas respostas. Uma mudança de interface é todo o defeito numa linha de saída.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

Um perfil de túnel completo instala uma rota predefinida através do túnel, como descreve o guia de encaminhamento VPN do Windows, por isso cada resposta sai agora pela VPN e depende de o outro lado encaminhar de volta para o seu cliente. Um perfil de túnel dividido é mais seguro por predefinição mas não é imune, porque uma rota específica que cubra o endereço do par ainda pode vencer a rota predefinida física. Em qualquer caso a pergunta é idêntica: depois de o túnel subir, o endereço do par continua a resolver para a interface que trouxe a sessão para dentro?

Se não, a correção pertence ao perfil ou a uma rota de exceção explícita aprovada por quem detém a política de VPN. Editar a tabela de rotas à mão num anfitrião de produção durante um incidente é como um contorno temporário se transforma em configuração não documentada.

Vigie a mudança de perfil da firewall

Uma nova interface é classificada quando aparece, e a classificação decide contra que perfil de firewall o seu tráfego é avaliado. Um adaptador de túnel que cai na categoria Public pode parar silenciosamente o RDP de entrada mesmo que a tabela de rotas pareça perfeita. Esse é o segundo modo de falha, e produz um sintoma diferente: a rota está certa, os pacotes chegam e o anfitrião recusa a ligação.

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

Compare o perfil ligado à interface do túnel com os perfis a que as regras de Remote Desktop estão circunscritas. Uma regra ativada apenas para Domain e Private não faz nada por uma interface classificada como Public, e nenhuma correção de rota muda isso. Alguns clientes VPN também restringem por conceção o acesso à sub-rede local, o que produz a mesma forma de falha a partir de outro controlo.

Teste a transição a partir de um local de onde possa voltar

Faça toda a sequência a partir de uma consola fora de banda ou de um segundo caminho de gestão, por esta ordem: confirme a sessão existente, ligue a VPN, abra uma sessão nova, depois desligue a VPN e abra outra. Cada passo testa uma transição diferente, e o primeiro que falhar diz-lhe qual é o controlo responsável.

Programe o retrocesso antes de começar, por exemplo uma tarefa agendada que executa rasdial "Work VPN" /disconnect após um intervalo definido. Isso transforma uma sessão perdida numa interrupção de cinco minutos em vez de uma visita ao local, e é o seguro mais barato de todo o procedimento.

Volte a entrar quando a sessão já desapareceu

Se o anfitrião já está inalcançável, pare de tentar novas ligações RDP a partir do mesmo cliente e use o canal de recuperação que o ambiente já tem: um RD Gateway, uma consola de hipervisor ou uma interface de gestão fora de banda. Peça à pessoa com acesso à consola para executar os mesmos comandos Find-NetRoute e Get-NetConnectionProfile, para que as provas sobrevivam à recuperação.

Depois decida a disposição permanente e não a mais rápida. Ou o caminho de gestão é preservado explicitamente pelo perfil de VPN, ou a gestão passa para um canal que não depende da rota predefinida do anfitrião. Ambas são defensáveis; uma rota de anfitrião com um gateway adivinhado não é. Escreva qual escolheu e registe o endereço do par que tinha de sobreviver.