RDP si blocca dopo l’installazione di un client VPN? È il firewall

Pochi minuti dopo che un client VPN consumer ha finito l’installazione, il portale dice ancora che la VM è in esecuzione, l’IP pubblico non è cambiato e RDP non risponde. Di solito si presume che la VM sia andata in crash o che sia cambiato il gruppo di sicurezza di rete, e entrambe le ipotesi sono di solito sbagliate. Quello che è cambiato è il profilo del firewall di Windows in cui si trova la macchina, e la regola RDP che prima corrispondeva non corrisponde più. La riparazione inizia ottenendo una shell attraverso un percorso che non dipende da RDP.

La VM è in esecuzione; la regola non corrisponde più

Le regole del firewall di Windows portano un insieme di profili, e una regola limitata a Privato o Dominio non ha effetto finché la macchina è sul profilo Pubblico. Gli installer VPN aggiungono adattatori e route, e diversi irrigidiscono il Pubblico come effetto collaterale. Il listener resta legato alla 3389 e i pacchetti arrivano ancora, ma la discrepanza di profilo li scarta.

Lo stato di alimentazione e la raggiungibilità sono fatti distinti, e una VM in esecuzione con una porta chiusa appare dall’esterno esattamente come una che è andata in crash.

Provi la porta prima di modificare qualsiasi cosa. Un tentativo di connessione alla 3389 che va in timeout mentre un comando dell’agente guest restituisce ancora output punta al firewall dell’host. Una porta che risponde mentre RDP continua a fallire significa che il guasto è sopra il livello di rete, e questa riparazione non lo toccherà. Annoti quale dei due casi ha visto, perché il resto del piano dipende da questo.

Due cancelli si chiudono in modo indipendente

La policy della piattaforma viene prima: il gruppo di sicurezza di rete vede il pacchetto prima del guest. Quest’ordine rende inutile una voce NSG perfetta quando l’host scarta il pacchetto, e inutile una regola host aperta quando la piattaforma la nega. Trattali come cancelli separati e prova ciascuno per conto suo.

Legga le regole effettive dell’NSG nel portale o nella CLI, poi le confronti con le regole del guest stesso. Non dia per scontato che l’ultima modifica che ricorda sia quella entrata in vigore.

Un client consumer può anche installare un driver di filtro o un kill switch che blocca il traffico sotto il firewall di Windows. Se le regole del firewall sembrano corrette e la porta continua a fallire, quel livello è il prossimo sospetto.

Usi l’agente guest come via di ritorno

Due funzioni di esecuzione remota, Run Command e la Custom Script Extension, girano dentro il guest tramite l’agente della piattaforma. Nessuna delle due richiede RDP, quindi l’errore del firewall non le riguarda. Entrambe restituiscono l’output dello script, il che le rende un canale di diagnosi e anche di riparazione.

Legga il profilo attivo e la regola RDP prima di modificare uno dei due:

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

Riattivare le regole in ingresso su quel profilo è una misura temporanea, non una destinazione. La usi per ottenere una sessione, poi chiuda il varco come si deve:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Quell’interruttore apre tutte le regole in ingresso del profilo, non solo RDP. Una volta ottenuta la sessione, lo sostituisca con una regola limitata e ripristini le impostazioni che vuole davvero. Se anche l’agente non è disponibile, la soluzione di ripiego è una console seriale o un disco ricostruito, ed è la ragione pratica per mantenere l’agente in salute.

Restringa il varco prima di chiudere la sessione

La modifica temporanea del profilo è una porta tenuta aperta per ogni regola in ingresso di quel profilo. La sostituisca con una regola limitata al suo indirizzo di origine e alla porta RDP, poi confermi che il profilo è tornato allo stato previsto. Lo faccia mentre ha ancora la sessione, perché il prossimo errore potrebbe non essere reversibile da remoto. Tenga pronta una seconda via amministrativa come Bastion o una console seriale durante la modifica.

Confermi il risultato dalla sua postazione con un test della porta, e dall’interno del guest con l’elenco delle regole:

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

Attivi la registrazione del firewall per la durata del test. Una sola riga su un pacchetto scartato che nomina la 3389 e il profilo attivo risponde alla domanda più in fretta di un altro riavvio.

Impedisca al prossimo installer di rifarlo

Se quell’host non ha motivo di eseguire il client, lo disinstalli. Un client installato è un invito permanente per il prossimo aggiornamento a riscrivere di nuovo il profilo, e la prossima persona eseguirà il debug dello stesso disservizio dal portale.

Faccia uno snapshot del disco prima di lasciare che qualcosa riscriva le impostazioni di rete, e tenga pronta una seconda via amministrativa prima di averne bisogno.

Annoti cosa ha modificato l’installer: adattatori, route, profili del firewall, driver di filtro e servizi. Quel registro trasforma il prossimo incidente in uno schema noto invece che in una nuova indagine. Quando la VM ha bisogno di un tunnel verso esattamente un servizio, metta il client sulla sua postazione o costruisca un collegamento sito a sito invece di installare sul server un prodotto per portatili. I client consumer puntano ai portatili, e un server che amministra da remoto non lo è.