La VPN dice connesso ma non passa nulla: due punti da controllare

Un tunnel può dichiararsi connesso mentre nulla lo raggiunge, e i due fatti vivono in posti diversi. Uno è la tabella delle route, che può ancora inviare pacchetti a un dispositivo che nessuno possiede. L’altro è il resolver, che può ancora elencare un server su un link ormai sparito. Il cambiamento di rete non ha danneggiato il profilo, ha reso orfano lo stato della connessione precedente, e la riparazione dipende da quale dei due stai guardando davvero.

Prima chiedi al kernel quale dispositivo userebbe

Un elenco di route mostra ciò che esiste; una ricerca di route mostra ciò che accadrebbe. Chiedi di un indirizzo pubblico e leggi il nome del dispositivo nella risposta, perché quel solo campo decide se il pacchetto arriva da qualche parte utile. Quando la risposta nomina un dispositivo tunnel, il kernel gli consegna i pacchetti anche se dietro quell’interfaccia non gira più alcun processo client. Quando la risposta nomina l’adattatore fisico mentre il client dichiara di essere connesso, il tunnel è attivo e semplicemente non è il percorso scelto.

Il secondo caso è quello abituale dopo che un cavo sostituisce il wireless, e si presenta come una VPN rotta.

ip route show default
ip route get 203.0.113.9

Leggi poi le voci di default, perché una route aggiunta dalla precedente connessione di base può sopravvivere a un cambio di link e mettersi davanti a quella nuova. Una route di default attraverso un dispositivo spento è peggio di nessuna route di default, perché il kernel la preferisce comunque. Guarda la metrica accanto a ogni voce, perché quell’ordine spiega la preferenza più in fretta dei nomi delle interfacce.

Poi leggi il resolver per link, non per file

La risoluzione dei nomi porta con sé il proprio stato e la propria obsolescenza. Un resolver che elenca i server DNS per link conserva i server di un link tunnel spento ma ancora registrato, e ogni interrogazione aspetta poi un server che non risponderà. Il sintomo è una rete che sembra morta mentre la tabella delle route è perfetta.

Ispeziona lo stato per link invece del file, perché su molte distribuzioni quel file è un collegamento simbolico verso il resolver e modificarlo non fa nulla oppure viene sovrascritto in fretta. Guarda quale link possiede quali server e quale dominio di ricerca, poi chiediti se il link tunnel dovrebbe essere ancora registrato. Se non dovrebbe, disattiva la connessione che lo possiede invece di modificare a mano uno stato generato. Un nome che si risolve mentre la ricerca di route manda i pacchetti altrove è un terzo guasto, separato.

resolvectl status
resolvectl query app.internal.example

Se gli indirizzi si risolvono e le connessioni falliscono, il resolver va bene e la route no. Se gli indirizzi non si risolvono affatto, è qui che conviene iniziare.

Come una route obsoleta sopravvive al cambiamento

Il client non possiede la rete da solo. Su un host con NetworkManager un profilo VPN viene attivato sopra una connessione di base, e le impostazioni di connessione permettono a quella base di indicare la VPN che deve seguirla. Quando la base cambia perché un altro profilo diventa preferito, il tunnel segue sulla nuova base oppure resta senza nessuna.

Un profilo VPN non si tira su da solo, quindi l’accoppiamento conta molto più della preferenza di connessione automatica del profilo stesso.

Leggi l’elenco attivo e annota quale base è attiva prima di toccare il tunnel. Se la base è elencata e il tunnel no, la route manca invece di essere obsoleta e la riparazione è l’attivazione. Se attivando il tunnel viene segnalato che non esiste alcuna connessione sorgente, la base con cui era accoppiato è sparita, quindi attivala prima oppure ripara l’accoppiamento invece di ritentare il tunnel. Ritentare un profilo il cui padre è assente produce lo stesso errore ogni volta, il che è un segnale utile e non un fastidio.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Distinguere lo stato obsoleto da un padre mancante

Tre stati spiegano quasi ogni segnalazione, e ciascuno richiede una riparazione diversa. Una route di default attraverso un dispositivo che esiste ancora ma non porta più il tunnel è stato obsoleto, eliminato cancellando la voce oppure riavviando il profilo responsabile. Un dispositivo tunnel il cui processo client è sparito è un fallimento di pulizia, quindi merita attenzione il percorso di disconnessione e non la tabella delle route. Nessun dispositivo tunnel significa che manca il padre o l’accoppiamento e che la tabella delle route non è mai stata coinvolta.

Riavviare nasconde quale dei tre avevi, ed è esattamente per questo che sembra una riparazione.

Dopo la riparazione, chiedi al kernel un indirizzo pubblico e uno interno, poi interroga un nome interno. Quando l’indirizzo funziona e il nome no, hai trovato un problema di ambito del dominio nel resolver e non di routing. Annota quale stato hai trovato, perché il prossimo cambiamento di rete riprodurrà quello che hai lasciato stare.