VPN di Windows: il profilo salvato contro lo stato dell’interfaccia attiva

Una VPN di Windows compare in due punti che rispondono a domande diverse, e confonderli produce una diagnosi sicura ma sbagliata. Il profilo salvato dice ciò che qualcuno ha configurato; l’interfaccia attiva dice ciò che lo stack ha appena applicato. Quando una connessione si stabilisce e il traffico prende comunque la strada sbagliata, vanno lette entrambe le viste, in quest’ordine. Nessuna delle due da sola dice se il pacchetto dell’applicazione è uscito dal tunnel.

Due viste dello stesso tunnel

La vista del profilo è la configurazione: indirizzo del server, tipo di tunnel, metodo di autenticazione, impostazioni del tunnel diviso. Può essere corretta mentre la connessione la ignora, e può essere obsoleta mentre la connessione funziona perfettamente, perché un client che si riconnette può non rileggere ciò che hai modificato. La vista dell’interfaccia è lo stato applicato: quali adattatori esistono, quali famiglie di indirizzi portano, le loro metriche e il loro stato di connessione. Cambia man mano che i tunnel compaiono e scompaiono, il che la rende il posto giusto per una domanda di routing dal vivo e il posto sbagliato per una domanda di configurazione.

Leggerle insieme è l’intero metodo, e leggerne una sola è il modo in cui le persone finiscono per eliminare un adattatore sano. I comandi qui sotto producono entrambe le viste senza cambiare nulla.

Leggi entrambe le viste senza cambiare nulla

Inizia dai profili salvati, perché è il fatto meno costoso da confermare. Nota il tipo di tunnel e il valore del tunnel diviso, dato che entrambi decidono quali destinazioni devono entrare nel tunnel. Se il profilo è sbagliato, correggilo tramite la sua superficie di configurazione supportata, perché nulla nell’elenco delle interfacce ripara un profilo che punta a un gateway sbagliato.

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

La vista dell’interfaccia ha una forma diversa: un tunnel può occupare due righe quando porta entrambe le famiglie di indirizzi. Leggi l’indice come identità e l’alias come un’etichetta scelta da qualcuno, e aspettati che l’alias cambi tra le versioni del client.

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

La presenza non è prova d’uso, perché un’interfaccia può esistere, essere connessa e non essere comunque quella che sceglie la rotta verso la tua destinazione. Tienilo presente prima di trattare un adattatore sconosciuto come la colpa. Questi due guasti sembrano identici dall’esterno: un profilo corretto con una rotta che non lo usa mai, e un profilo sbagliato con una rotta che lo usa. Hanno correzioni completamente diverse, ed è per questo che esiste la sezione successiva.

Segui la rotta fino alla destinazione

Chiedi allo stack quale percorso seguirebbe per l’indirizzo che l’applicazione contatta davvero. Questa è la domanda a cui l’elenco delle interfacce non può rispondere da solo.

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

Il primo comando riporta due campi che vale la pena leggere: l’alias dell’interfaccia della sorgente scelta e il salto successivo per quella destinazione. L’indice 37 nel secondo comando è ciò che ha stampato il primo output, non una costante da copiare, e l’indirizzo 10.60.20.10 è illustrativo. Se la sorgente scelta appartiene all’adattatore fisico mentre la destinazione dovrebbe essere dentro il tunnel, hai trovato il problema di selezione, perché l’interfaccia VPN può essere perfettamente sana e semplicemente non preferita. La metrica è solo una parte di quella decisione, dato che la specificità della rotta, i criteri e lo stato dell’interfaccia partecipano tutti.

Confronta tre stati nelle stesse condizioni

Registra l’elenco delle interfacce e la rotta scelta prima di connetterti, mentre sei connesso e dopo la disconnessione, con la stessa destinazione e gli stessi comandi ogni volta. Quel confronto separa un’interfaccia di tunnel attuale da un vecchio adattatore nascosto lasciato da una disinstallazione, e da un secondo client che è anch’esso in esecuzione. Dice anche se l’interfaccia del tunnel scompare in modo pulito, perché un adattatore che persiste dopo la disconnessione è un problema diverso da uno che non è mai comparso. Senza le tre istantanee, ogni alias sconosciuto sembra il colpevole.

Conserva i tre output con il ticket, perché due output di comandi valgono più di un paragrafo di descrizione. Un collega può confrontarli senza ripetere affatto la tua sessione.

Non eliminare ciò che non hai identificato

Gli adattatori sconosciuti di solito appartengono a qualcosa: un client gestito, uno switch virtuale, una rete di container o un agente di sicurezza. Eliminarne uno può rimuovere un componente funzionante e lasciare il sintomo originale esattamente dov’era. Se la rotta è obsoleta, trova il proprietario della rotta e correggila lì; se il profilo è sbagliato, modifica il profilo. La documentazione di Get-NetIPInterface elenca i campi usati sopra, comprese le colonne metrica e stato che rendono significativo il confronto.

Dai un nome all’oggetto, trova il suo proprietario, poi agisci su quel proprietario. Qualsiasi altra cosa è rinominare il problema invece di leggerlo.