L’app VPN è andata in crash: il kill switch è ancora attivo?

Partite da dove parte l’utente: la finestra del client è sparita, l’icona nella tray è svanita e il browser o carica o non carica. Quella sola osservazione non vi dice se il blocco è sopravvissuto. La risposta dipende da quale componente tiene le regole, se quel componente è morto con la finestra e se la piattaforma mantiene l’applicazione fuori dall’app. Procedete dalla finestra al processo, poi al firewall, poi al percorso reale.

Non riavviate per primo; un riavvio di solito distrugge le prove.

Partite da ciò che è ancora in esecuzione

Aprite l’elenco dei processi prima di toccare qualsiasi cosa. Un client desktop di solito si divide in un processo di interfaccia utente e in un servizio o demone, e un crash nel primo non ferma necessariamente il secondo. Su Windows il servizio può essere ancora elencato, su Linux l’unità può essere ancora attiva e su Android il tunnel appartiene al sistema una volta dato il consenso. Leggete questi tre fatti in quest’ordine.

Se il demone è vivo, probabilmente lo è anche il tunnel, e la finestra mancante è solo cosmetica.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Leggete il blocco da chi lo applica, non dall’app

Se il client implementa il suo kill switch inserendo regole del firewall, quelle regole appartengono al sistema operativo e sopravvivono al processo che le ha create. Un crash vi lascia allora bloccati senza alcuna interfaccia per disattivarlo, il che sembra una rete rotta più che una protezione. Se invece il blocco vive nel percorso dei pacchetti del client stesso, uccidere il processo rimuove il blocco nello stesso momento.

Android lo gestisce ancora in modo diverso: la VPN always-on con lockdown è un’impostazione della piattaforma, quindi il blocco persiste indipendentemente dal processo dell’app, e il sistema può riavviare il servizio. Consultate la documentazione della piattaforma per il comportamento esatto invece di supporre che coincida con un client desktop.

Distinguere un’uscita pulita da un crash

Un Quit normale di solito esegue il percorso di spegnimento del client, che rimuove le regole e chiude il tunnel di proposito. Un crash salta quel percorso e lascia tutto ciò che l’applicatore ha già installato. La differenza si vede nei timestamp delle regole rispetto all’uscita del processo, e nella presenza di un’interfaccia tunnel orfana.

Quella distinzione decide il recupero: un’uscita pulita può richiedere una nuova connessione, mentre un crash può richiedere la rimozione delle regole residue tramite l’azione di riparazione supportata del client.

Recuperate senza rompere altri controlli

Riavviate il client tramite il suo flusso di lavoro documentato, poi verificate entrambe le metà del requisito: il tunnel trasporta traffico e il blocco si applica ancora quando deve. Svuotare l’intero firewall per recuperare la connettività rimuove anche controlli non correlati, e questo scambio raramente vale la pena.

Per un crash ripetuto, raccogliete la versione del client, la build della piattaforma e i log limitati che il fornitore chiede. Un profilo client, una chiave privata o un log di connessione completo di un altro account non servono per un rapporto di crash, e includerli trasforma un caso di supporto in un problema di trattamento dei dati.

Un crash non è prova di una fuga. La prova è un pacchetto osservato uscire da un percorso che la policy doveva impedire, catturato nel momento in cui il client era spento. Testatelo di proposito, con una destinazione innocua, e annotate quale livello di applicazione ha tenuto.