Client VPN disinstallato, ma il tunnel parte ancora all’avvio

La vostra distribuzione rimuove il pacchetto, il menu perde la voce e il tunnel compare comunque dopo il riavvio successivo. Un client VPN commerciale lascia pezzi che il gestore di pacchetti non ha mai tracciato, quindi una rimozione pulita non è la stessa cosa di una macchina pulita. Quattro di questi pezzi spiegano quasi ogni connessione fantasma: un’unità, un profilo di connessione, un helper privilegiato e un repository del fornitore. Leggete tutti e quattro prima di eliminare qualcosa, poi rimuovete ciascuno tramite il componente che lo possiede.

Ciò che il disinstallatore non ha mai registrato

Un gestore di pacchetti rimuove i file che ha annotato e nient’altro. Non ha alcun registro di un profilo di connessione creato dal client a runtime, di un’unità abilitata dopo l’installazione, né di un helper che si è registrato mentre girava con diritti elevati. Ognuno di questi appartiene a un sottosistema diverso, e ognuno può sopravvivere al pacchetto per uno o più riavvii. Proprio quel vuoto spiega perché un tunnel può essere sano mentre il software che lo ha prodotto è sparito.

Il residuo ha sempre un proprietario, che sia systemd, NetworkManager, la configurazione del repository o una voce di avvio automatico per utente. Individuare prima il proprietario è ciò che impedisce a una pulizia di diventare una macchina mezzo configurata. Eliminare i file direttamente di solito funziona finché il proprietario non li rigenera, ed è per questo che i comandi qui sotto iniziano con le query.

Quattro proprietari, prima solo lettura

Cominciate con le query anziché con le eliminazioni e annotate i nomi esatti che tornano. I fornitori spesso distribuiscono un payload versionato accanto a un metapacchetto, quindi un prodotto può apparire con due nomi. Un nome presente in entrambi gli elenchi è un solo prodotto con due proprietari, e vanno rimossi entrambi. Il primo blocco copre pacchetti e unità, dove la maggior parte dei residui diventa visibile.

dpkg -l | grep -i acmevpn
systemctl list-unit-files | grep -i acmevpn
systemctl list-units --type=service --state=running | grep -i acmevpn

Il secondo blocco copre i due componenti che sopravvivono più spesso a una pulizia, vale a dire il profilo di connessione e il repository del fornitore. Leggete la colonna UUID invece del nome, perché i nomi duplicati sono comuni e il comando di eliminazione attende l’identificatore. La riga del repository vale la pena di leggerla anche se oggi non lo rimuovete, dato che un host del fornitore morto può rompere un’installazione non correlata mesi dopo. Nessuno dei due elenchi cambia nulla, ed è proprio per questo che si eseguono per primi.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
grep -ril acmevpn /etc/apt/sources.list.d/ /etc/apt/sources.list

Un processo ancora vivo dopo la pulizia è un’unità attiva oppure il figlio di un altro programma. Leggete la tabella dei processi e la sua catena di genitori prima di incolpare un servizio che non esiste più. Le voci di avvio automatico per utente richiedono lo stesso passaggio, e compaiono solo in una shell di login nuova, non in una sessione root.

Tre verbi che non sono intercambiabili

Fermare termina l’esecuzione corrente, disabilitare rimuove i collegamenti all’avvio e mascherare punta l’unità su /dev/null. Solo il terzo blocca anche l’attivazione tramite socket, timer o dipendenza, il che lo rende il più forte dei tre. L’ordine conta finché state ancora decidendo cosa fare della macchina. Mascherare è lo stato giusto durante quella decisione, perché fallisce in modo rumoroso invece di avviarsi in silenzio al prossimo boot.

Smascherate prima di reinstallare, altrimenti il nuovo pacchetto sembrerà rotto per un motivo che nessuno ha annotato. La stessa cautela vale per le differenze di impacchettamento: una build fornisce un’unità che può essere fermata, mentre un’altra non lascia alcun servizio. Stabilite quale impacchettamento avete prima di scegliere un verbo, perché il percorso di pulizia differisce tra loro.

Con i caratteri jolly si elimina il profilo sbagliato

Eliminate il profilo con l’UUID annotato e mai con un carattere jolly. La directory keyfile contiene anche ogni profilo Wi-Fi ed Ethernet della macchina, quindi una corrispondenza ampia rimuove cose che vi servono ancora. Un keyfile eliminato a mano può essere rigenerato dalla policy che lo possiede, il che fa sembrare l’eliminazione inefficace.

nmcli connection delete uuid <uuid>

Esportate prima il gateway e l’identità se quel profilo è l’unica copia che vi resta, perché un’eliminazione locale non revoca nulla sul server. Il repository segue la stessa regola: rimuovete l’unico file del fornitore e il suo portachiavi, poi aggiornate gli elenchi dei pacchetti e riprovate l’installazione che volevate davvero. Lasciare una voce di terze parti obsoleta può bloccare una vecchia dipendenza o non rispondere affatto. Entrambe le rimozioni sono piccole, e ciascuna può essere annullata dalla copia che conservate.

Cosa gira ancora dopo il riavvio

Riavviate prima di dichiarare vittoria, poi cercate gli artefatti anziché l’applicazione. Un’interfaccia di tunnel, una rotta divisa obsoleta e DNS per collegamento lasciati dal vecchio client richiedono ciascuno il proprio comando. Tutti e tre possono sopravvivere a una pulizia che ha rimosso ogni pacchetto con successo.

ip link
ip route
resolvectl status

Aprite anche una shell di login nuova, perché una voce di avvio automatico scatta solo lì. Poi leggete /etc/NetworkManager/dispatcher.d/ in cerca di uno script che alza una connessione ogni volta che un’interfaccia cambia stato, il che spiega un tunnel che torna senza servizio dietro. Se qualcosa chiama ancora verso l’esterno, seguite il processo fino al suo genitore invece di eliminare file finché il sintomo non cessa. Pulire la macchina e revocare l’account restano due lavori separati, e solo uno dei due è finito quando il riavvio sembra tranquillo.