Perché RDP si blocca quando il computer remoto si connette a una VPN

Sei dentro la finestra RDP, il desktop è sullo schermo e premi Connect nel client VPN che gira su quella macchina remota. Pochi secondi dopo la finestra si blocca e poi si chiude. Il tunnel è salito, ed è esattamente ciò che registrerà il log della VPN, ed è il fatto meno utile di tutto l’incidente. La sessione è morta perché la macchina con cui parlavi ha cambiato il modo di risponderti, quindi esamina il percorso di ritorno prima di toccare il tunnel.

Annota l’endpoint che la tua sessione usa davvero

L’indirizzo digitato nel client RDP non è necessariamente quello a cui risponde il computer remoto. NAT, un RD Gateway o un bilanciatore di carico davanti all’host possono riscriverlo, e il percorso di ritorno è definito dall’indirizzo sorgente che la macchina remota vede sulla connessione stabilita. Sbagliarlo ti manda a cercare una rotta che non è mai stata coinvolta.

Sul computer remoto, prima che la VPN sia connessa, elenca le sessioni stabilite e leggi l’indirizzo del peer dalla tabella. Poi annotalo da qualche parte fuori da quella macchina, perché non potrai più leggerlo dopo la caduta della sessione.

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

Tratta quell’indirizzo come ciò che deve restare raggiungibile. Se è un indirizzo privato su una VLAN di gestione, il tunnel deve lasciare tranquillo quel percorso. Se è un indirizzo pubblico, la risposta deve uscire dalla stessa interfaccia che ha portato la richiesta dentro.

Leggi la rotta che risponde a quell’endpoint

Windows sceglie un’interfaccia per ogni destinazione, e Find-NetRoute mostra la decisione che prenderebbe adesso. Eseguilo sull’indirizzo del peer prima di connettere, poi di nuovo con il tunnel attivo, e confronta l’indice di interfaccia e il next hop nelle due risposte. Un cambio di interfaccia è tutto il difetto in una riga di output.

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 profilo a tunnel completo installa una rotta predefinita attraverso il tunnel, come descrive la guida di Windows al routing VPN, quindi ogni risposta ora esce dalla VPN e dipende dal fatto che l’altro lato instradi verso il tuo client. Un profilo a tunnel diviso è più sicuro per impostazione predefinita ma non immune, perché una rotta specifica che copre l’indirizzo del peer può ancora battere la rotta predefinita fisica. In ogni caso la domanda è identica: dopo che il tunnel è salito, l’indirizzo del peer si risolve ancora verso l’interfaccia che ha portato la sessione dentro?

Se no, la correzione appartiene al profilo o a una rotta di eccezione esplicita approvata da chi possiede la politica VPN. Modificare a mano la tabella di routing su un host di produzione durante un incidente è il modo in cui una soluzione temporanea diventa configurazione non documentata.

Osserva il cambio di profilo del firewall

Una nuova interfaccia viene classificata quando appare, e la classificazione decide a quale profilo firewall viene giudicato il suo traffico. Un adattatore di tunnel che finisce nella categoria Public può fermare silenziosamente RDP in ingresso anche se la tabella di routing sembra perfetta. Questo è il secondo modo di guasto, e produce un sintomo diverso: la rotta è giusta, i pacchetti arrivano e l’host rifiuta la connessione.

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

Confronta il profilo associato all’interfaccia del tunnel con i profili a cui sono limitate le regole di Remote Desktop. Una regola abilitata solo per Domain e Private non fa nulla per un’interfaccia classificata Public, e nessuna correzione di rotta lo cambia. Alcuni client VPN limitano anche per progetto l’accesso alla sottorete locale, il che produce la stessa forma di guasto da un controllo diverso.

Prova la transizione da un punto da cui puoi tornare

Esegui tutta la sequenza da una console fuori banda o da un secondo percorso di gestione, in questo ordine: conferma la sessione esistente, connetti la VPN, apri una sessione nuova, poi disconnetti la VPN e aprine un’altra. Ogni passo prova una transizione diversa, e il primo che fallisce ti dice quale controllo è responsabile.

Pianifica il rollback prima di iniziare, per esempio un’attività pianificata che esegue rasdial "Work VPN" /disconnect dopo un intervallo definito. Questo trasforma una sessione persa in un’interruzione di cinque minuti invece di una visita in sede, ed è l’assicurazione più economica di tutta la procedura.

Rientra quando la sessione è già sparita

Se l’host è già irraggiungibile, smetti di provare nuove connessioni RDP dallo stesso client e usa il canale di ripristino che l’ambiente ha già: un RD Gateway, una console dell’hypervisor o un’interfaccia di gestione fuori banda. Chiedi alla persona con accesso alla console di eseguire gli stessi comandi Find-NetRoute e Get-NetConnectionProfile, così le prove sopravvivono al ripristino.

Poi decidi l’assetto permanente invece del più rapido. O il percorso di gestione è preservato esplicitamente dal profilo VPN, oppure la gestione passa a un canale che non dipende dalla rotta predefinita dell’host. Entrambi sono sostenibili; una rotta host con un gateway indovinato no. Annota quale hai scelto e registra l’indirizzo del peer che doveva sopravvivere.