Disinstallare il client VPN, riavviare e poi scoprire che il browser non carica nulla è una sequenza comune su Ubuntu. Il tunnel è sparito, ma non la politica che vi indirizzava il traffico, e su Ubuntu questi residui vivono di solito in NetworkManager e non nel pacchetto. Un profilo di connessione e un'interfaccia fittizia creati a runtime non appartengono a nessun pacchetto, quindi rimuovere il pacchetto non li rimuove.

Il tunnel è sparito, la politica no

Un kill switch funziona rendendo la rete inutilizzabile senza il tunnel. Quando il client viene rimosso mentre quello stato è attivo, non resta nulla che lo disattivi. Il risultato sembra esattamente una scheda di rete rotta ed è di solito un profilo che trattiene una rotta.

Per questo una reinstallazione a volte ripristina la connettività: ricrea il processo che sa annullare la propria politica. Un client rimosso mentre il suo interruttore era attivo ha lasciato uno stato che nessuno ripulisce più.

Leggi gli oggetti che il pacchetto non ha mai posseduto

Leggi lo stato prima di cambiarlo. Elenca dispositivi, connessioni attive ed entrambe le tabelle di routing, poi cerca un dispositivo fittizio che si dichiara connesso o una rotta predefinita che punta a uno. IPv4 e IPv6 falliscono separatamente, quindi un ping che funziona verso un indirizzo con la risoluzione dei nomi rotta punta a un oggetto diverso da una rotta morta. Un dispositivo fittizio che trattiene una rotta predefinita spiega da solo l'intera interruzione.

nmcli device status
nmcli connection show --active
ip -4 route
ip -6 route

Annota ciò che trovi, perché la correzione è eliminare un oggetto preciso invece di reimpostare tutto. Qualsiasi cosa più ampia rischia una seconda interruzione. È la differenza tra una riparazione e una supposizione.

Una tabella di routing vuota con un dispositivo connesso è un altro guasto, e punta a DHCP invece che a un profilo residuo. Leggi il lease prima di modificare qualsiasi cosa.

Elimina il profilo, non il file della chiave

Elimina il profilo tramite NetworkManager invece di rimuovere il file della chiave. Eliminare il file lascia il profilo in memoria attivo fino al riavvio successivo, il che fa sembrare inaffidabile una riparazione corretta. Poi riavvia il servizio e rileggi l'elenco dei dispositivi. È il riavvio che rende reale l'eliminazione.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

Se un collegamento fittizio sopravvive, rimuovi anche quel collegamento, poi prova un indirizzo e un nome separatamente. Un routing pulito con un nome non risolto punta a DNS, mentre un indirizzo non raggiungibile punta a una rotta o a un firewall.

Controlla l'aggancio di avvio prima che si ripeta

Alcuni residui si reinstallano a ogni avvio. Un'unità scritta a mano o uno script if-up che aggiunge regole del firewall continua a farlo dopo che il pacchetto è sparito, così l'interruzione torna e la riparazione precedente sembra fortuna. Cerca nei file delle unità e negli agganci di rete prima di riavviare di nuovo. Il nome dell'unità di solito è l'indizio.

systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.d

Rimuovi o maschera il file specifico, riavvia una volta e conferma che lo stato senza tunnel è quello che vuoi. Quell'ultimo riavvio è il test, perché una correzione che regge solo fino al prossimo avvio non è una correzione. Conserva la nota con la macchina dopo. Il riferimento di nmcli copre i comandi di dispositivo e connessione usati sopra.

Articoli correlati