Si apre una finestra, chiede le credenziali, poi resta vuota o cade, e l'utente riferisce che la VPN ha rotto l'accesso remoto. A volte il tunnel è a posto e la sessione non è mai iniziata. Sapere dove viene effettivamente eseguita l'applicazione è ciò che separa questi casi, perché un tunnel e una sessione desktop offrono cose diverse e falliscono in punti diversi.

Un tunnel dà al tuo dispositivo un percorso verso una rete. Una sessione desktop ti dà uno schermo e una tastiera collegati a un'altra macchina.

Il sintomo dipende da dove viene eseguita l'applicazione

Con l'accesso diretto attraverso un tunnel, l'applicazione viene eseguita sul tuo dispositivo e le sue richieste attraversano la rotta privata consentita fino a una condivisione di file o a un sito interno. Se quell'applicazione fallisce, stai guardando un problema di risoluzione dei nomi o di instradamento, e il programma locale per il resto si comporta normalmente.

In una sessione remota, l'applicazione viene eseguita sulla macchina remota e il tuo dispositivo ne riceve un'immagine. Questo cambia del tutto l'elenco dei guasti: l'host della sessione deve essere disponibile, il servizio che accetta le connessioni deve essere in ascolto e il tuo account deve essere autorizzato sia sul tunnel sia sull'host. Una finestra vuota dopo un accesso riuscito al tunnel di solito significa che la seconda autenticazione non è mai riuscita.

Entrambi i progetti possono convivere per lo stesso utente. Una disposizione comune richiede prima il tunnel e poi una sessione desktop al suo interno, ed è per questo che un successo parziale si legge così facilmente come un'unica funzione rotta.

Le prestazioni seguono il carico di lavoro, non l'etichetta

Aprire un file grande direttamente attraverso un tunnel sposta quel file sulla rete, e il ritardo visibile segue il trasferimento e non il clic. In una sessione remota il file potrebbe non lasciare mai il centro dati, il che elimina il trasferimento e lo sostituisce con l'aggiornamento dello schermo e la latenza di input. Nessuno dei due progetti è più veloce in generale, perché spostano cose diverse. Chiedi su quale grandezza l'utente sta davvero aspettando prima di scegliere una metrica.

Questa differenza conta quando qualcuno segnala lentezza. Una sessione remota che sembra lenta durante la digitazione è sensibile al ritardo di andata e ritorno, mentre l'apertura diretta di un file sullo stesso tunnel è sensibile alla velocità effettiva. Misura il compito e non una cifra di velocità generica, e prova esattamente l'operazione di cui l'utente si lamenta.

Il lavoro interattivo su un percorso ad alta latenza peggiora quanto più cambia lo schermo, ed è per questo che scorrere un documento si sente diverso dal guardare una finestra statica. Se la lamentela riguarda la reattività e non il tempo di completamento, la posizione del carico di lavoro è la variabile che vale la pena cambiare.

Controllate ogni livello separatamente quando fallisce

Lavorate dall'esterno verso l'interno e annotate cosa restituisce ogni passo, perché riavviare tutto insieme distrugge le prove. Confermate che il tunnel è attivo, poi che la rotta privata si risolve, poi che l'host della sessione accetta connessioni, poi che il vostro account è consentito su di esso.

Test-NetConnection -ComputerName 172.20.8.30 -Port 3389
Resolve-DnsName workstation-14.corp.example
qwinsta /server:172.20.8.30

Una rotta che risponde e una porta che rifiuta sono risultati diversi, e una porta che risponde mentre le vostre credenziali vengono rifiutate è un terzo. Dove la distribuzione usa un gateway di accesso gestito invece di un tunnel verso l'ufficio, seguite quell'architettura invece di esporre un servizio desktop su internet perché una rotta privata ha fallito.

Crittografia e autorizzazione sono anch'esse mansioni separate. Il tunnel crittografa il percorso, mentre il protocollo di sessione vi autentica verso un host e l'applicazione può autenticarvi di nuovo. Superare il primo controllo non dice nulla sul terzo, e le indicazioni per raggiungere un PC remoto dall'esterno della rete descrivono le parti di cui necessita una distribuzione funzionante.

Decidete cosa deve restare dentro l'organizzazione

Presumere che una sessione remota tenga ogni documento nel centro dati non è sicuro. La condivisione degli appunti, le unità reindirizzate e la stampa possono spostare informazioni tra i due ambienti ogni volta che la policy lo consente, e un tunnel non limita quali file un utente autorizzato copia da una condivisione raggiungibile. Se il requisito è il confinamento, esaminate i controlli di trasferimento reali della sessione invece di fidarvi del diagramma dell'architettura. Chiedete al proprietario della sessione quali reindirizzamenti sono attivi prima di promettere qualcosa a nome suo.

La durata della sessione è l'altra sorpresa. Chiudere la finestra può lasciare la sessione in esecuzione sull'host, quindi perdere il tunnel può solo renderla temporaneamente irraggiungibile. Imparate il modo approvato di terminare il lavoro su una macchina condivisa, e controllate l'host dopo invece di dare per scontato che la disconnessione sia avvenuta.

Annotate quale livello ha fallito, cosa avete cambiato e cosa l'utente dovrebbe ritestare. Quel verbale vale più di una soluzione che nessuno può riprodurre.

Articoli correlati