Por que se conxela o RDP cando o equipo remoto se conecta a unha VPN

Estás dentro da xanela de RDP, o escritorio está na pantalla e premes Connect no cliente VPN que se executa nese equipo remoto. Segundos despois a xanela conxélase e logo péchase. O túnel levantouse, que é exactamente o que rexistrará o log da VPN, e ese é o dato menos útil de todo o incidente. A sesión morreu porque a máquina coa que falabas cambiou a forma de responderte, así que revisa o camiño de volta antes de tocar o túnel.

Anota o extremo que a túa sesión usa realmente

O enderezo escrito no teu cliente RDP non é necesariamente o enderezo ao que responde o equipo remoto. O NAT, unha RD Gateway ou un balanceador de carga diante do host poden reescribilo, e o camiño de volta defíneo o enderezo de orixe que a máquina remota ve na conexión establecida. Se te equivocas aquí, buscarás unha ruta que nunca estivo implicada.

No equipo remoto, antes de que a VPN estea conectada, lista as sesións establecidas e le o enderezo do par da táboa. Despois anótao nalgún lugar fóra desa máquina, porque non poderás lelo cando caia a sesión.

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

Trata ese enderezo como aquilo que debe seguir sendo alcanzable. Se é un enderezo privado nun VLAN de xestión, o túnel ten que deixar ese camiño en paz. Se é un enderezo público, a resposta ten que saír pola mesma interface que trouxo a petición.

Le a ruta que responde a ese extremo

Windows escolle unha interface por destino, e Find-NetRoute mostra a decisión que tomaría agora mesmo. Execútao contra o enderezo do par antes de conectar, logo outra vez co túnel levantado, e compara o índice de interface e o seguinte salto nas dúas respostas. Un cambio de interface é todo o fallo nunha liña 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

Un perfil de túnel completo instala unha ruta por defecto a través do túnel, como describe a guía de enrutamento de VPN de Windows, así que agora cada resposta sae pola VPN e depende de que o outro lado enrute de volta cara ao teu cliente. Un perfil de túnel dividido é máis seguro por defecto pero non inmune, porque unha ruta específica que cubra o enderezo do par aínda pode vencer a ruta por defecto física. En calquera caso a pregunta é idéntica: cando o túnel se levanta, o enderezo do par segue resolvéndose á interface que trouxo a sesión?

Se non, a corrección pertence ao perfil ou a unha ruta de excepción explícita aprobada por quen posúe a política de VPN. Editar a táboa de enrutamento a man nun host de produción durante un incidente é como un apaño temporal se converte en configuración non documentada.

Vixía o cambio de perfil da devasa

Unha interface nova clasifícase cando aparece, e a clasificación decide contra que perfil de devasa se xulga o seu tráfico. Un adaptador de túnel que cae na categoría Public pode deter silenciosamente o RDP entrante aínda que a táboa de enrutamento pareza perfecta. Ese é o segundo modo de fallo, e produce un síntoma distinto: a ruta é correcta, os paquetes chegan e o host rexeita a conexión.

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

Compara o perfil asociado á interface do túnel cos perfís aos que están dirixidas as regras de Remote Desktop. Unha regra habilitada só para Domain e Private non fai nada por unha interface clasificada como Public, e ningunha corrección de ruta o cambia. Algúns clientes VPN tamén restrinxen por deseño o acceso á subrede local, o que produce a mesma forma de fallo desde outro control.

Proba a transición desde algún lugar recuperable

Fai toda a secuencia desde unha consola fóra de banda ou un segundo camiño de xestión, nesta orde: confirma a sesión existente, conecta a VPN, abre unha sesión nova, despois desconecta a VPN e abre outra. Cada paso proba unha transición distinta, e o primeiro que falla diche que control é o responsable.

Programa a reversión antes de comezar, por exemplo unha tarefa programada que execute rasdial "Work VPN" /disconnect tras un intervalo fixo. Iso converte unha sesión perdida nunha interrupción de cinco minutos en lugar dunha visita ao sitio, e é o seguro máis barato de todo o procedemento.

Volta entrar cando a sesión xa se foi

Se o host xa é inalcanzable, deixa de probar conexións RDP novas desde o mesmo cliente e usa a canle de recuperación que o contorno xa ten: unha RD Gateway, unha consola de hipervisor ou unha interface de xestión fóra de banda. Pide á persoa con acceso á consola que execute os mesmos comandos Find-NetRoute e Get-NetConnectionProfile, para que as probas sobrevivan á recuperación.

Logo decide o arranxo permanente en lugar do máis rápido. Ou o camiño de xestión se preserva explicitamente no perfil de VPN, ou a xestión pasa a unha canle que non depende da ruta por defecto do host. Ambos son sostibles; unha ruta de host cunha pasarela adiviñada non o é. Anota cal escolliches e rexistra o enderezo do par que tiña que sobrevivir.