Per què es bloqueja l’RDP quan l’ordinador remot es connecta a una VPN

Sou dins de la finestra de l’RDP, l’escriptori és a la pantalla i premeu Connect al client VPN que s’executa en aquella màquina remota. Al cap d’uns segons la finestra es bloqueja i després es tanca. El túnel s’ha aixecat, que és exactament el que registrarà el log de la VPN, i aquest és el fet menys útil de tot l’incident. La sessió ha mort perquè la màquina amb qui parlàveu ha canviat la manera com us respon, així que reviseu el camí de tornada abans de tocar el túnel.

Anoteu el punt final que la vostra sessió fa servir realment

L’adreça que escriviu al client RDP no és necessàriament l’adreça a què respon l’ordinador remot. El NAT, una RD Gateway o un balancejador de càrrega davant de l’amfitrió poden reescriure-la, i el camí de tornada el defineix l’adreça d’origen que la màquina remota veu a la connexió establerta. Si us equivoqueu aquí, buscareu una ruta que no hi era mai.

A l’ordinador remot, abans que la VPN estigui connectada, llisteu les sessions establertes i llegiu l’adreça de parell de la taula. Després anoteu-la en algun lloc fora d’aquella màquina, perquè no la podreu llegir quan caigui la sessió.

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

Tracteu aquella adreça com allò que ha de romandre accessible. Si és una adreça privada en una VLAN de gestió, el túnel ha de deixar aquell camí tranquil. Si és una adreça pública, la resposta ha de sortir per la mateixa interfície que ha fet entrar la petició.

Llegiu la ruta que respon a aquell punt final

Windows tria una interfície per a cada destí, i Find-NetRoute mostra la decisió que prendria ara mateix. Executeu-lo contra l’adreça de parell abans de connectar, després un altre cop amb el túnel aixecat, i compareu l’índex d’interfície i el salt següent de les dues respostes. Un canvi d’interfície és tot el defecte en una línia de sortida.

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 complet instal·la una ruta per defecte a través del túnel, tal com descriu la guia de Windows per a l’encaminament de VPN, així que ara cada resposta surt per la VPN i depèn que el costat oposat encamini de tornada cap al vostre client. Un perfil de túnel dividit és més segur per defecte però no immune, perquè una ruta específica que cobreixi l’adreça de parell encara pot superar la ruta per defecte física. En qualsevol cas la pregunta és idèntica: quan el túnel s’aixeca, l’adreça de parell encara es resol a la interfície que ha fet entrar la sessió?

Si no, la correcció pertoca al perfil o a una ruta d’excepció explícita aprovada per qui posseeix la política de VPN. Editar la taula d’encaminament a mà en un amfitrió de producció durant un incident és com una solució provisional es converteix en configuració no documentada.

Vigileu el canvi de perfil del tallafoc

Una interfície nova es classifica quan apareix, i la classificació decideix contra quin perfil de tallafoc es jutja el seu trànsit. Un adaptador de túnel que cau a la categoria Public pot aturar silenciosament l’RDP d’entrada encara que la taula d’encaminament sembli perfecta. Aquest és el segon mode de fallada, i produeix un símptoma diferent: la ruta és correcta, els paquets arriben i l’amfitrió refusa la connexió.

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

Compareu el perfil adjunt a la interfície del túnel amb els perfils a què estan abastades les regles de Remote Desktop. Una regla habilitada només per a Domain i Private no fa res per a una interfície classificada com a Public, i cap correcció de ruta no ho canvia. Alguns clients VPN també restringeixen l’accés a la subxarxa local per disseny, cosa que produeix la mateixa forma de fallada des d’un control diferent.

Proveu la transició des d’algun lloc recuperable

Feu tota la seqüència des d’una consola fora de banda o un segon camí de gestió, en aquest ordre: confirmeu la sessió existent, connecteu la VPN, obriu una sessió nova, després desconnecteu la VPN i obriu-ne una altra. Cada pas prova una transició diferent, i el primer que falla us diu quin control n’és el responsable.

Programeu la reversió abans de començar, per exemple una tasca programada que executi rasdial "Work VPN" /disconnect després d’un interval fix. Això converteix una sessió perduda en una interrupció de cinc minuts en lloc d’una visita al lloc, i és l’assegurança més barata de tot el procediment.

Torneu a entrar quan la sessió ja ha desaparegut

Si l’amfitrió ja és inabastable, deixeu de provar connexions RDP noves des del mateix client i feu servir el canal de recuperació que l’entorn ja té: una RD Gateway, una consola d’hipervisor o una interfície de gestió fora de banda. Demaneu a la persona amb accés a la consola que executi les mateixes ordres Find-NetRoute i Get-NetConnectionProfile, perquè les proves sobrevisquin a la recuperació.

Després decidiu l’arranjament permanent en lloc del més ràpid. O el camí de gestió es preserva explícitament al perfil de VPN, o la gestió es trasllada a un canal que no depèn de la ruta per defecte de l’amfitrió. Tots dos són sostenibles; una ruta d’amfitrió amb una passarel·la endevinada no ho és. Anoteu quin heu triat i registreu l’adreça de parell que havia de sobreviure.