VPN connessa ma un servizio fallisce: isola la fase

«Connesso» è il dato meno informativo in un ticket VPN. Registra che due peer hanno completato un handshake e nulla sul nome interrogato, sull’interfaccia da cui è uscito il pacchetto, sulla sua dimensione o se l’estremità remota lo ha accettato. Per questo un servizio può fallire mentre ogni altra applicazione sullo stesso portatile funziona. Attraversa le fasi in ordine e la prima che fallisce nominerà il guasto.

Parti dal nome, non dal tunnel

Risolvi prima di instradare, perché una risposta sbagliata rende inutile ogni test successivo. Interroga il nome con il resolver di sistema e confronta quella risposta con l’indirizzo che l’applicazione ha realmente usato. Un nome privato che torna come indirizzo pubblico significa che la query è andata a un resolver che non ha nulla a che fare. Un nome che non si risolve è la stessa categoria, solo più rumorosa.

resolvectl query host.internal
getent hosts host.internal

I browser con la propria impostazione di DNS sicuro falliscono qui mentre il resto del sistema funziona. Per questo una lamentela solo del browser appartiene prima a questa fase, prima che qualcuno tocchi una rotta. Confronta entrambi i comandi e non uno, perché getent segue il percorso NSS e la query al resolver no.

Chiedi al kernel quale percorso ha scelto

La tabella di routing è un ordine di preferenza, e il percorso scelto dal kernel non è sempre quello mostrato dal diagramma. Chiediglielo direttamente per la destinazione in questione. La risposta nomina l’interfaccia, il salto successivo e l’indirizzo sorgente che verrà usato. Un pacchetto può uscire dal tunnel con un indirizzo sorgente che l’estremità remota rifiuta, e una voce più specifica nella tabella fisica può farlo uscire dall’interfaccia Wi-Fi.

ip route get 10.20.30.40
ip -brief address show

Leggi i campi dev, via e src in questo ordine, perché ciascuno elimina un sospetto diverso. Questa fase possiede anche lo stato installato dal client, perché le regole del firewall e le rotte possono restare dopo un’uscita anomala. Per questo «niente internet senza il tunnel» e «niente internet se il client non gira» sono una stessa famiglia di guasti, non due.

Prova la dimensione del pacchetto

Una risposta piccola che torna mentre un trasferimento grande si blocca punta prima all’MTU del percorso. Una sola sonda con il bit do-not-fragment attivo, inviata da dentro il tunnel, separa questa fase dalle altre. Alza il carico utile finché la sonda fallisce e hai il numero che conta.

ping -M do -s 1400 10.20.30.40

Sonde piccole che passano mentre un elenco di cartella o un caricamento si blocca è la firma di questa fase. La lamentela suona come credenziali o una regola del firewall, e non è nessuna delle due.

Il numero è una proprietà del percorso, non del client, quindi un valore che funziona su una connessione d’ufficio può fallire su un collegamento mobile. Conserva il comando della sonda con il ticket, perché la persona successiva ha bisogno della stessa misura. Se passa un carico minore, la correzione è un clamp o un MTU del tunnel più basso, non un nuovo cifrario.

Prova l’estremità remota

Prova la destinazione per il suo indirizzo, poi guarda cosa ascolta lì. Una connessione rifiutata e una connessione che non risponde mai sono riscontri diversi. La prima dice che qualcosa è attivo e non serve quella porta, la seconda dice che non è tornato nulla. Nessuna delle due è un problema del client per impostazione predefinita.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Nulla raggiungibile attraverso un tunnel può essere un servizio che ascolta solo su 127.0.0.1, perché l’ascoltatore non vede mai il pacchetto. Quando il firewall dell’host remoto consente la sottorete dell’ufficio e rifiuta il pool del tunnel, il risultato sembra un guasto del client e non lo è. Desktop remoto o condivisione file che si rompono mentre il traffico web sopravvive di solito finiscono qui, comunque l’utente lo formuli.

Mappa la lamentela su una sola fase

La maggior parte delle segnalazioni rientra in una di cinque forme, e ogni forma nomina una fase. Un sito che funziona solo attraverso il tunnel è una risposta di nome o una policy legata all’indirizzo sorgente. Aggiornamenti che falliscono senza il tunnel mentre la navigazione funziona: è un problema di nome o di rotta per quel client.

Che tutto si fermi all’avvio di un client del provider è stato installato, cioè una questione di rotta e firewall. Un servizio irraggiungibile mentre il resto è a posto è l’estremità remota. Trasferimenti che si bloccano dopo pochi secondi sono la dimensione del pacchetto. Abbina la forma prima di eseguire comandi, perché decide quali prove raccogliere prima.

Annota la fase che ha prodotto il primo errore insieme all’output del comando. Un ticket che dice che l’indirizzo sorgente era sbagliato, con la riga di rotta allegata, merita un intervento, mentre uno che segnala la VPN come rotta no.