L’interruttore di sicurezza blocca ancora il traffico dopo la disconnessione della VPN

Il tunnel non c’è più, l’icona di rete sembra normale e nulla si carica. Hai disconnesso la VPN, l’hai disinstallata o hai riavviato, e il blocco che doveva proteggerti durante una caduta è ancora lì. La finestra del client non può spiegarlo, perché non è il client a bloccarti: la decisione è stata scritta nel kernel a tuo nome e non è rimasto nulla per rimuoverla. Su Windows quello stato risiede nel Windows Filtering Platform; su Linux è un insieme di regole in iptables o nftables, spesso con uno snapshot che viene riapplicato all’avvio. Quella che segue è l’ordine che uso: leggi lo stato, elimina l’oggetto più ristretto che spiega il guasto, poi trova tutto ciò che continua a rimetterlo a posto.

Un interruttore di sicurezza è stato del kernel, non un’impostazione

I client desktop implementano il blocco aggiungendo filtri che negano il traffico fuori dal tunnel. Su Windows sono filtri WFP ai livelli connect-redirect e transport, e alcuni sono persistenti: vengono registrati nell’archivio dei criteri del Base Filtering Engine e ripristinati all’avvio della macchina, prima che qualsiasi software VPN parta. I client differiscono su quando ripuliscono. Alcuni rimuovono i filtri alla disconnessione, altri solo su un’uscita pulita, altri solo se prima si disattiva l’interruttore. Disinstalla mentre il blocco è attivo, oppure termina il processo, e i filtri restano.

L’equivalente su Linux è una regola di drop o reject nel percorso di output, a volte una regola di forwarding, a volte una politica di catena modificata. Quelle regole sopravvivono al processo che le ha aggiunte perché sono stato del kernel: termina il client, fallo andare in crash o togli la corrente, e il kernel continua a scartare pacchetti senza che resti nulla per annullarlo. Un pacchetto di persistenza aggiunge un secondo strato di permanenza salvando uno snapshot dell’insieme di regole corrente e ripristinandolo all’avvio, così l’avvio successivo inizia con il blocco già installato.

Leggi lo stato WFP prima di eliminare qualsiasi cosa

Windows include gli strumenti necessari. Apri un prompt con privilegi elevati e scarica lo stato della piattaforma; il dump finisce come wfpstate.xml nella directory di lavoro.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Cerca nell’XML il nome del fornitore andato via, un’azione Block e il livello. I filtri su connect-redirect e transport sono quelli che rompono il traffico ordinario; un filtro su un livello receive-accept di solito non è la tua causa. Se il Base Filtering Engine non è affatto in esecuzione, cerca altrove, perché nient’altro può applicare quei filtri.

Controlla anche la vista firewall ordinaria, dato che la maggior parte delle persone ispeziona solo una delle due:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Quando i profili predefiniti sono attivi e nessuna regola corrisponde al traffico che fallisce, il blocco viene da un provider di terze parti e non da Windows Firewall. Questa distinzione decide quale strumento userai per la riparazione.

Leggi le regole Linux nella sintassi con cui eliminerai

iptables -S stampa le regole nella stessa forma usata per aggiungerle, il che rende l’output direttamente riutilizzabile per un’eliminazione. iptables -L -v -n aggiunge contatori di pacchetti, e quei contatori ti dicono se una regola sta davvero corrispondendo alle tue richieste fallite o se sta semplicemente ferma nella catena.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Leggi le politiche delle catene, non solo le regole: -P OUTPUT DROP blocca il traffico anche quando nessuna regola corrisponde. Ispeziona IPv6 separatamente, perché un client che installa entrambe le famiglie può lasciare in piedi il blocco IPv6 dopo che le regole IPv4 sono sparite, e il sintomo allora dipende da quale famiglia un’applicazione preferisce. Dove si usa nftables, esegui anche nft list ruleset; i due strumenti convivono tramite uno strato di compatibilità, e un solo elenco non mostra necessariamente ogni regola che può scartare un pacchetto.

Elimina l’oggetto più ristretto che spiega il guasto

Su Windows il primo passo resta il percorso di rimozione del fornitore: riesegui il programma di installazione e usa repair o uninstall, oppure esegui lo strumento di pulizia se il fornitore lo pubblica. Servizi e attività pianificate residue sono comuni, e un’attività che avvia il client all’accesso reinstalla i suoi filtri al riavvio successivo. Una disinstallazione che fallisce leggendo la chiave di registro del client di solito significa che un servizio o un’attività la tiene ancora, non che il registro sia corrotto.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

I filtri persistenti sono l’ultima risorsa. Si trovano sotto HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, un valore per filtro con chiave GUID. Esporta prima la chiave, annota i GUID che rimuovi, elimina solo i valori che appartengono al client andato via, poi riavvia così il motore ricostruisce il suo stato. Non eliminare l’intera chiave e non disabilitare il Base Filtering Engine: Windows Firewall e Defender dipendono da esso, e scambieresti un’interruzione con una peggiore.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Su Linux, prendi la riga stampata da iptables -S e sostituisci -A con -D. Eliminare l’unica regola che hai identificato è meglio che svuotare una catena, perché lascia intatta la tua politica.

sudo iptables -D OUTPUT -p udp -j REJECT

Se il drop vive in una catena definita dall’utente, elimina prima il salto a quella catena e poi rimuovi la catena con -X. Impostare una politica di catena su ACCEPT mentre le regole di drop sono ancora presenti aiuta solo i pacchetti che raggiungono affatto la decisione di politica. Svuotare ogni tabella è l’ultima risorsa: rimuove anche regole che hai aggiunto per altri motivi, e con ufw attivo lascia il servizio convinto di possedere catene che non esistono più.

Trova il proprietario che lo rimette a posto

Dopo la riparazione immediata, cerca tutto ciò che ripristinerebbe lo stato. Su Linux, controlla se un’unità di persistenza è abilitata, se il client ha un’impostazione per ripristinare il firewall all’accesso e se esiste un file di regole salvato sotto /etc. Su Windows, controlla di nuovo voci di avvio, servizi e attività pianificate, poi riavvia e rileggi lo stato con gli stessi comandi di prima.

Se il blocco torna, l’eliminazione non era la soluzione; lo era il proprietario. Annota quale client o servizio lo installa e disabilita la funzione lì, invece di combatterlo a livello di firewall dopo ogni disconnessione.

Verifica con traffico reale, non con un singolo ping

Prova una risoluzione di nome, una connessione TCP e una nuova sessione del browser, poi riavvia e ripeti gli stessi tre controlli. Un ping che funziona mentre HTTPS fallisce punta a un filtro a livello transport e non alla rete, e un blocco che riappare solo dopo il riavvio punta a un proprietario che non hai ancora trovato.

Conserva le prove: la chiave BFE esportata, o l’output di iptables -S catturato prima della modifica. Prima di dichiararlo risolto, conferma il livello da cui hai rimosso l’oggetto, il proprietario che potrebbe reinstallarlo, lo stato dopo un riavvio pulito e che la navigazione ordinaria funzioni senza alcun processo VPN in esecuzione. La pagina man di iptables(8) ha la sintassi esatta di eliminazione e di politica se scrivi la pulizia come script.