Desktop remoto tramite VPN: in quale guasto ti trovi?

Il tuo tunnel è attivo, il wiki interno si carica e il desktop remoto continua a rifiutare la connessione. Questa combinazione è normale, perché la VPN fornisce una rotta verso l'host mentre il servizio desktop deve essere in ascolto, autorizzato dal proprio firewall e disposto ad autenticare l'account. Quattro fasi di guasto separano un tunnel funzionante da una sessione utilizzabile, e ciascuna fallisce con un messaggio diverso. Leggi prima il messaggio, perché nomina la fase.

Quattro guasti che sembrano uno

Le fasi sono ordinate: il nome si risolve nell'indirizzo privato previsto dal progetto, la porta risponde a un handshake TCP, l'host accetta la connessione secondo la propria politica e l'accesso alla sessione riesce. Ogni fase rende la successiva non testabile, per questo modificare le impostazioni RDP prima che la rete sia a posto produce solo rumore. Il sintomo appare identico dal lato dell'utente in tutti e quattro i casi. Solo il messaggio del client li distingue.

Un sito interno funzionante non dimostra nessuna delle quattro cose. Dimostra che un host della stessa rete ha risposto su una porta diversa con un servizio diverso. Prendilo come prova sul routing e nulla più.

Prova in ordine e annota il risultato. Saltare alla schermata di accesso perché la porta ha risposto è il modo di passare un pomeriggio su un problema di firewall che il primo passo ha già localizzato.

Qualcosa è in ascolto sulla 3389?

Inizia dal nome, perché un nome che si risolve nell'indirizzo sbagliato invalida ogni test successivo. Chiedi al resolver del tunnel che cosa significa il nome, poi confronta la risposta con l'indirizzo privato previsto dal progetto, non con una risposta riuscita. Un nome che si risolve in un indirizzo pubblico è tutto il problema, e nessuna modifica RDP lo correggerà:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Poi prova la porta invece dell'host. Un handshake TCP completato sulla 3389 separa la raggiungibilità da tutto ciò che sta sopra:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Esegui quel test dalla LAN e dal tunnel, perché una differenza tra i due risultati localizza il guasto sul percorso VPN. Sul percorso ci sono due firewall ed è facile confonderli: la rete deve consentire all'indirizzo del tunnel del client di raggiungere l'host, e il firewall dell'host deve consentire la stessa origine sulla porta in ascolto. Una regola limitata alla sottorete LAN non copre il pool di client VPN, ed è la causa più comune di un timeout che solo gli utenti remoti segnalano. Controlla l'ambito, non l'esistenza della regola.

Il percorso di ritorno merita lo stesso controllo. Le risposte hanno bisogno di una rotta di ritorno verso il pool di client e non verso la LAN, e una traduzione davanti all'host cambia l'origine che il tuo registro mostrerà. Se la porta risponde in una direzione e non nell'altra, la metà mancante è di solito il percorso di ritorno.

Leggi il messaggio prima di leggere la configurazione

La terza fase è l'host che rifiuta la connessione secondo la propria politica, cosa che spesso sembra una porta che si apre e si chiude subito. Qualcosa ha risposto, e questa è un'informazione utile invece del silenzio. Se l'handshake è stato completato e la sessione è morta subito, la rete è a posto e decide l'host. Controlla le autorizzazioni del desktop remoto prima di toccare di nuovo la rete.

La funzione può essere abilitata per la macchina mentre l'accesso è limitato a gruppi specifici, e il listener può essere associato in modi che escludono l'indirizzo da cui sei arrivato. L'autenticazione a livello di rete aggiunge una porta che fallisce prima del caricamento del desktop, e il suo testo di errore è diverso da una password sbagliata. Confronta il messaggio del client con il registro eventi dell'host, perché il messaggio nomina la porta e il registro l'account.

L'accesso alla sessione è un confine a sé

L'autenticazione appartiene al servizio desktop, non alla VPN. L'identità del tunnel e l'account del desktop sono credenziali separate con politiche di blocco separate, quindi un tunnel funzionante dimostra solo che il tunnel ti ha accettato. Bloccare l'account del desktop non disturba il tunnel, e vale anche il contrario.

Mantieni entrambi intatti. Quando manca la rotta privata, correggi la rotta, perché pubblicare il listener su internet scambia un difetto di raggiungibilità con un desktop esposto. Non indebolire neppure i controlli di identità della sessione per superare un avviso di certificato apparso nello stesso momento. Un certificato autofirmato su un listener RDP produce un avviso per progetto, quindi accettarlo è una decisione e non un passo.

Conta i tentativi prima di riprovare. Le soglie di blocco del desktop contano gli accessi falliti separatamente dai guasti VPN, e un client che riprova a tempo può superare la soglia mentre stai ancora modificando una regola. È lo stesso meccanismo di tentativi paralleli che blocca gli account dopo un cambio di password.

Cosa può spostare la sessione, e dove resta

Impara il flusso di disconnessione approvato prima di averne bisogno. Chiudere la finestra può solo disconnettere la vista mentre la sessione continua a funzionare secondo la politica configurata, cosa che conta su un host condiviso o sottoposto a audit. Disconnettiti dall'interno della sessione quando la politica se lo aspetta.

Poi decidi cosa può trasportare la sessione, perché appunti, unità reindirizzate, reindirizzamento delle stampanti e trasferimento di file spostano dati tra i sistemi locale e remoto dove la politica lo consente. Un'applicazione pubblicata che gira dall'altra parte non è automaticamente un confine senza download, e una sessione che sembra di sola lettura può comunque trasportare appunti. Prova il compito reale e non la connessione: apri il file, usa l'applicazione e conferma il reindirizzamento che ti serve. Le indicazioni Microsoft per raggiungere un desktop remoto dall'esterno descrivono le opzioni di esposizione supportate, e sono un riferimento migliore di un listener pubblico aggiunto sotto pressione.