Il VPN dice di essere connesso, ma la rotta predefinita è morta

Il client dichiara la connessione, l’icona nella barra delle applicazioni sembra normale e non si carica nulla. È iniziato subito dopo il passaggio da Wi-Fi a cavo, o subito dopo la fine di un aggiornamento della distribuzione. Ciò che si è rotto non è il profilo, ma lo stato costruito per la connessione di base precedente. Il kernel ha ancora una rotta predefinita che punta a un dispositivo tunnel che nessuno possiede, oppure il resolver elenca ancora server su un collegamento che è sparito. Entrambi i guasti sembrano una rete morta ed entrambi si riparano sul posto.

I pezzi obsoleti erano già sbagliati prima che te ne accorgessi. Scollegare un cavo li ha solo resi visibili.

Chiedi al kernel dove andrebbe un pacchetto

Gli elenchi delle rotte sono difficili da leggere perché enumerano tutto ciò che il sistema conosce, comprese le voci che non valgono più. Una ricerca di rotta risponde all’unica domanda che vale la pena: quale dispositivo trasporta proprio questo pacchetto in questo momento. Se la risposta nomina un dispositivo tunnel, il kernel lo userà anche se dietro non c’è alcun processo client vivo, e il pacchetto finisce in un’interfaccia che nessuno mantiene. Se la risposta nomina l’adattatore Ethernet mentre il client insiste di essere connesso, il tunnel esiste ma ha perso la selezione, che è il risultato abituale del passaggio da wireless a cavo.

Esegui la ricerca due volte, una per un indirizzo pubblico e una per uno interno, perché una politica di tunnel diviso può instradarne uno onestamente e lasciar cadere l’altro.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Il resolver conserva anche il collegamento morto

Su un host con systemd-resolved, i server DNS appartengono ai collegamenti e non a un elenco globale. Un collegamento VPN caduto può restare registrato con i suoi server per un po’, e allora ogni ricerca attende un indirizzo che non risponderà mai. Quel ritardo sembra una rete morta e spinge le persone a guardare le rotte quando la rotta è a posto.

resolvectl status
resolvectl query intranet.example.com

Leggi i blocchi per collegamento e individua quale collegamento possiede il dominio in questione. Un tunnel attivo ma non proprietario del dominio interno inoltra i nomi interni al resolver pubblico, e il sintomo è indistinguibile da un guasto di instradamento.

Ripara la registrazione invece di /etc/resolv.conf. Nelle installazioni attuali di Ubuntu e Fedora quel percorso è un collegamento simbolico allo stato di esecuzione del resolver, quindi una modifica viene ignorata o sovrascritta al successivo evento di rete.

Un VPN non parte mai da solo

NetworkManager alza un VPN sopra una connessione di base, e impara quale seguire da connection.secondaries su quella base. Il riferimento delle impostazioni di connessione dichiara esplicitamente che la connessione automatica non è implementata per i profili VPN. Questo è l’intero meccanismo dietro questa classe di guasti: cambia la base, e il VPN deve essere riaccoppiato o riattivato a mano.

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

Quando l’elenco attivo mostra la base senza il VPN, il tunnel non è affatto attivo e la rotta non è mai stata installata invece di essere rimasta obsoleta. Quando l’attivazione si lamenta che non esiste alcuna connessione sorgente, la base con cui era accoppiato è sparita, quindi ripara prima la base o l’accoppiamento e smetti di riprovare il VPN.

Un aggiornamento può far cadere impostazioni senza un messaggio

Aggiornare una distribuzione sostituisce il client e spesso il suo plugin NetworkManager, mentre il profilo salvato conserva i nomi delle proprietà con cui è stato scritto. Tutto ciò che il nuovo plugin non riconosce più viene saltato in silenzio. Il profilo si attiva ancora e il dispositivo compare ancora, ma la rotta che un tempo arrivava con lui non arriva più.

Anche gli hook scritti a mano si spostano. Uno script che installava una rotta in un momento prevedibile della vecchia sequenza ora può essere eseguito prima che l’interfaccia esista, o dopo che il client è già andato in timeout.

Confronta il profilo vivo con il plugin che hai davvero, non con il comportamento che ricordi. Se una chiave è sparita dalla documentazione, sposta il lavoro in uno script dispatcher o in una sostituzione supportata invece di ripristinare la vecchia proprietà.

Tre stati, tre riparazioni diverse

Decidi in quale stato sei prima di toccare qualsiasi cosa, perché un riavvio distrugge le prove e il guasto torna al successivo cambio di rete.

Chiudi con una ricerca per un indirizzo pubblico, una per un indirizzo interno e una query di nome. Se gli indirizzi funzionano e il nome no, il guasto rimanente è l’ambito del dominio nel resolver, e la tabella delle rotte non è mai stata il problema.