L’aplicació VPN s’ha penjat: l’interruptor de seguretat encara està activat?

Comenceu on comença l’usuari: la finestra del client ha desaparegut, la icona de la safata s’ha esfumat i el navegador o carrega o no carrega. Aquesta observació sola no us pot dir si el bloqueig ha sobreviscut. La resposta depèn de quin component té les regles, si aquest component ha mort amb la finestra i si la plataforma manté l’aplicació de les regles fora del programa. Avanceu des de la finestra fins al procés, després fins al tallafoc i després fins al camí real.

No reinicieu primer; un reinici normalment destrueix les proves.

Comenceu per allò que encara s’executa

Obriu la llista de processos abans de tocar res. Un client d’escriptori normalment es divideix en un procés d’interfície d’usuari i un servei o dimoni, i una fallada del primer no atura necessàriament el segon. A Windows el servei pot continuar a la llista, a Linux la unitat pot continuar activa i a Android el túnel pertany al sistema un cop donat el consentiment. Llegiu aquests tres fets en aquest ordre.

Si el dimoni és viu, el túnel probablement també ho és, i la finestra que falta és només cosmètica.

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

Llegiu el bloqueig des de l’aplicador, no des de l’aplicació

Si el client implementa el seu interruptor de seguretat inserint regles de tallafoc, aquestes regles pertanyen al sistema operatiu i sobreviuen al procés que les va crear. Aleshores una fallada us deixa bloquejats sense cap interfície per desactivar-ho, cosa que sembla una xarxa trencada més que una protecció. Si en canvi el bloqueig viu dins del camí de paquets del propi client, matar el procés elimina el bloqueig en el mateix moment.

Android ho gestiona encara d’una altra manera: l’always-on VPN amb lockdown és un paràmetre de la plataforma, així que el bloqueig persisteix independentment del procés de l’aplicació, i el sistema pot reiniciar el servei. Consulteu la documentació de la plataforma per al comportament exacte en lloc de suposar que coincideix amb un client d’escriptori.

Distingiu una sortida neta d’una fallada

Un Quit normal normalment executa el camí d’aturada del client, que elimina regles i tanca el túnel a propòsit. Una fallada salta aquest camí i deixa el que l’aplicador ja ha instal·lat. La diferència es veu en les marques de temps de les regles respecte a la sortida del procés, i en si encara existeix una interfície de túnel antiga sense propietari.

Aquesta distinció decideix la vostra recuperació: una sortida neta pot necessitar una connexió nova, mentre que una fallada pot necessitar que les regles sobrants s’eliminin mitjançant l’acció de reparació admesa pel client.

Recupereu-vos sense trencar altres controls

Reinicieu el client pel seu flux de treball documentat i després comproveu les dues meitats del requisit: el túnel transporta trànsit i el bloqueig encara s’aplica quan toca. Buidar tot el tallafoc per recuperar la connectivitat també elimina controls no relacionats, i aquest intercanvi poques vegades val la pena.

Per a una fallada repetida, recolliu la versió del client, la compilació de la plataforma i els registres limitats que demana el proveïdor. Un perfil de client, una clau privada o un registre complet de connexió d’un altre compte no calen per a un informe de fallada, i incloure’ls converteix un cas de suport en un problema de tractament de dades.

Una fallada no és prova d’una fuita. La prova és un paquet observat que surt per un camí que la política havia d’impedir, capturat en el moment en què el client estava aturat. Proveu-ho deliberadament, amb una destinació innòcua, i anoteu quina capa d’aplicació va aguantar.