L’interruptor de seguretat encara bloqueja el trànsit després de desconnectar la VPN

El túnel ha desaparegut, la icona de xarxa sembla normal i no es carrega res. Heu desconnectat la VPN, l’heu desinstal·lada o heu reiniciat, i el bloqueig que us havia de protegir durant una caiguda continua en peu. La finestra del client no ho pot explicar, perquè el client no és el que us bloqueja: la decisió es va escriure al nucli en el vostre nom, i no s’hi va deixar res per eliminar-la. A Windows aquest estat viu a la plataforma de filtratge de Windows; a Linux és un conjunt de regles a iptables o nftables, sovint amb una instantània que es reprodueix en arrencar. El que segueix és l’ordre que faig servir: llegir l’estat, eliminar l’objecte més estret que explica la fallada i després trobar qualsevol cosa que el torni a posar.

Un interruptor de seguretat és estat del nucli, no un paràmetre

Els clients d’escriptori implementen el bloqueig afegint filtres que deneguen el trànsit fora del túnel. A Windows són filtres WFP a les capes de redirecció de connexió i de transport, i alguns són persistents: es registren a la botiga de polítiques del Base Filtering Engine i es restauren quan la màquina arrenca, abans que s’executi cap programari VPN. Els clients difereixen en quan netegen. Alguns eliminen els filtres en desconnectar, altres només en una sortida neta, i altres només quan primer es desactiva l’interruptor. Desinstal·leu mentre el bloqueig és actiu, o mateu el procés i els filtres es queden.

L’equivalent a Linux és una regla de descart o de rebuig a la ruta de sortida, de vegades una regla de reenviament, de vegades una política de cadena modificada. Aquestes regles sobreviuen al procés que les va afegir perquè són estat del nucli: mateu el client, feu-lo fallar o talleu l’energia, i el nucli continua descartant paquets sense que quedi res per desfer-ho. Un paquet de persistència afegeix una segona capa de permanència fent una instantània del conjunt de regles actual i restaurant-la en arrencar, de manera que la següent arrencada comença amb el bloqueig ja instal·lat.

Llegeix l’estat WFP abans d’eliminar res

Windows inclou les eines que necessiteu. Executeu una consola elevada i aboqueu l’estat de la plataforma; l’abocament apareix com a wfpstate.xml al directori de treball.

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

Cerqueu a l’XML el nom del proveïdor desaparegut, una acció Block i la capa. Els filtres a la redirecció de connexió i al transport són els que trenquen el trànsit ordinari; un filtre a una capa d’acceptació de recepció normalment no és la vostra causa. Si el Base Filtering Engine no s’executa gens, mireu en un altre lloc, perquè res més no pot aplicar aquests filtres.

Comproveu també la vista ordinària del tallafoc, perquè la majoria de la gent només n’inspecciona una de les dues:

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

Quan els perfils integrats estan activats i cap regla coincideix amb el trànsit que falla, el bloqueig prové d’un proveïdor de tercers i no del tallafoc de Windows. Aquesta distinció decideix quina eina fareu servir per a la reparació.

Llegeix les regles de Linux en la sintaxi amb què les eliminaràs

iptables -S imprimeix les regles en la mateixa forma que s’utilitza per afegir-les, cosa que fa la sortida directament reutilitzable per a una eliminació. iptables -L -v -n afegeix comptadors de paquets, i aquests comptadors us diuen si una regla coincideix realment amb les vostres peticions fallides o només seu a la cadena.

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

Llegeix les polítiques de les cadenes, no només les regles: -P OUTPUT DROP bloqueja el trànsit fins i tot quan cap regla coincideix. Inspeccioneu IPv6 per separat, perquè un client que instal·la les dues famílies pot deixar el bloqueig d’IPv6 al seu lloc després que les regles d’IPv4 hagin desaparegut, i el símptoma aleshores depèn de quina família prefereix una aplicació. On s’utilitza nftables, executeu també nft list ruleset; les dues eines conviuen a través d’una capa de compatibilitat, i un llistat no mostra necessàriament totes les regles que poden descartar un paquet.

Elimina l’objecte més estret que explica la fallada

A Windows el primer pas continua sent el camí d’eliminació del mateix proveïdor: torneu a executar l’instal·lador i feu servir la reparació o la desinstal·lació, o executeu l’eina de neteja si el proveïdor en publica una. Els serveis i les tasques programades sobrants són habituals, i una tasca que inicia el client en iniciar sessió reinstal·la els seus filtres a la propera arrencada. Una desinstal·lació que falla en llegir la clau de registre del client normalment vol dir que un servei o una tasca encara la reté, no que el registre estigui malmès.

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

Els filtres persistents són l’últim recurs. Viuen sota HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, un valor per filtre amb clau GUID. Exporteu primer la clau, anoteu els GUID que elimineu, suprimiu només els valors que pertanyen al client desaparegut i reinicieu perquè el motor reconstrueixi el seu estat. No suprimiu tota la clau ni desactiveu el Base Filtering Engine: el tallafoc de Windows i el Defender en depenen, i canviaríeu una caiguda per una de pitjor.

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

A Linux, agafeu la línia que imprimeix iptables -S i substituïu -A per -D. Eliminar l’única regla que heu identificat és millor que buidar una cadena, perquè deixa la vostra pròpia política intacta.

sudo iptables -D OUTPUT -p udp -j REJECT

Si el descart viu en una cadena definida per l’usuari, suprimiu primer el salt a aquesta cadena i traieu la cadena amb -X després. Posar la política d’una cadena a ACCEPT mentre les regles de descart encara hi són només ajuda els paquets que arriben a la decisió de política. Buidar totes les taules és l’últim recurs: també elimina regles que heu afegit per altres motius, i amb ufw activat deixa el servei creient que posseeix cadenes que ja no existeixen.

Troba el propietari que el torna a posar

Després de la reparació immediata, busqueu qualsevol cosa que pogués restaurar l’estat. A Linux, comproveu si hi ha una unitat de persistència activada, si el client té un paràmetre de restauració del tallafoc en iniciar sessió i si existeix un fitxer de regles desat sota /etc. A Windows, torneu a comprovar les entrades d’inici, els serveis i les tasques programades, i reinicieu i torneu a llegir l’estat amb les mateixes ordres que abans.

Si el bloqueig torna, l’eliminació no era la solució; ho era el propietari. Anoteu quin client o servei l’instal·la i desactiveu la funció allà, en lloc de lluitar-hi a la capa del tallafoc després de cada desconnexió.

Verifica amb trànsit real, no amb un sol ping

Proveu una consulta de nom, una connexió TCP i una sessió de navegador nova, i reinicieu i repetiu les mateixes tres comprovacions. Un ping que funciona mentre HTTPS falla apunta a un filtre de la capa de transport i no a la xarxa, i un bloqueig que només reapareix després del reinici apunta a un propietari que encara no heu trobat.

Guardeu les proves: la clau BFE exportada o la sortida d’iptables -S capturada abans del canvi. Abans de donar-ho per arreglat, confirmeu la capa d’on heu eliminat l’objecte, el propietari que el podria reinstal·lar, l’estat després d’un reinici net i que la navegació ordinària funciona sense cap procés VPN en marxa. La pàgina del manual iptables(8) té la sintaxi exacta d’eliminació i de política si programeu la neteja.