O interruptor de seguridade segue bloqueando o tráfico tras desconectar a VPN

O túnel desapareceu, a icona de rede parece normal e nada se carga. Desconectaches a VPN, desinstaláchela ou reiniciaches, e o bloqueo que debía protexerte durante unha caída segue en pé. A xanela do cliente non pode explicalo, porque o cliente non é o que te bloquea: a decisión escribiuse no kernel no teu nome e non se deixou nada para eliminala. En Windows ese estado vive na Plataforma de filtrado de Windows; en Linux é un conxunto de regras en iptables ou nftables, a miúdo cunha instantánea que se reproduce ao arrincar. O que segue é a orde que uso: ler o estado, eliminar o obxecto máis estreito que explica o fallo e despois atopar o que sexa que o volve pór.

Un interruptor de seguridade é estado do kernel, non un axuste

Os clientes de escritorio implementan o bloqueo engadindo filtros que denegan o tráfico fóra do túnel. En Windows son filtros WFP nas capas de redirección de conexión e de transporte, e algúns son persistentes: rexístranse no almacén de directivas de Base Filtering Engine e restáuranse cando a máquina arrinca, antes de que se execute ningún software VPN. Os clientes difiren en cando limpan. Algúns eliminan os filtros ao desconectar, outros só nunha saída limpa e outros só cando primeiro se apaga o interruptor. Desinstala mentres o bloqueo está activo, ou mata o proceso e os filtros quedan.

O equivalente en Linux é unha regra de descarte ou rexeitamento na ruta de saída, ás veces unha regra de reenvío, ás veces unha política de cadea modificada. Esas regras sobreviven ao proceso que as engadiu porque son estado do kernel: mata o cliente, faino fallar ou corta a enerxía, e o kernel segue descartando paquetes sen que quede nada para desfacer iso. Un paquete de persistencia engade unha segunda capa de permanencia ao tomar unha instantánea do conxunto de regras actual e restaurala ao arrincar, de xeito que o seguinte inicio comeza co bloqueo xa instalado.

Le o estado de WFP antes de borrar nada

Windows inclúe as ferramentas que necesitas. Executa unha consola elevada e volca o estado da plataforma; o volcado aparece como wfpstate.xml no directorio de traballo.

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

Busca no XML o nome do provedor que se foi, unha acción Block e a capa. Os filtros na redirección de conexión e no transporte son os que rompen o tráfico ordinario; un filtro nunha capa de aceptación de recepción normalmente non é a túa causa. Se Base Filtering Engine non se executa en absoluto, busca noutro sitio, porque nada máis pode aplicar eses filtros.

Comproba tamén a vista ordinaria da devasa, porque a maioría da xente só inspecciona unha das dúas:

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

Cando os perfís integrados están activados e ningunha regra coincide co tráfico que falla, o bloqueo vén dun provedor externo e non da devasa de Windows. Esa distinción decide que ferramenta usarás para a reparación.

Le as regras de Linux na sintaxe coa que vaias borrar

iptables -S imprime as regras na mesma forma que se usa para engadilas, o que fai que a saída sexa directamente reutilizable para un borrado. iptables -L -v -n engade contadores de paquetes, e eses contadores dinte se unha regra coincide realmente coas túas peticións fallidas ou simplemente está na cadea.

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

Le as políticas das cadeas, non só as regras: -P OUTPUT DROP bloquea o tráfico aínda que ningunha regra coincida. Inspecciona IPv6 por separado, porque un cliente que instala ambas as familias pode deixar o bloqueo de IPv6 no seu sitio despois de que as regras de IPv4 desaparezan, e o síntoma depende entón de que familia prefire unha aplicación. Onde se usa nftables, executa tamén nft list ruleset; as dúas ferramentas conviven mediante unha capa de compatibilidade, e unha listaxe non mostra necesariamente todas as regras que poden descartar un paquete.

Elimina o obxecto máis estreito que explica o fallo

En Windows o primeiro paso segue sendo a propia vía de eliminación do provedor: volve executar o instalador e usa reparar ou desinstalar, ou executa a ferramenta de limpeza se o provedor publica unha. Os servizos e tarefas programadas sobrantes son habituais, e unha tarefa que inicia o cliente ao iniciar sesión reinstala os seus filtros no seguinte arrinque. Unha desinstalación que falla ao ler a clave de rexistro do cliente normalmente significa que un servizo ou unha tarefa aínda a retén, non que o rexistro estea danado.

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

Os filtros persistentes son o último recurso. Viven baixo HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, un valor por filtro con clave GUID. Exporta primeiro a clave, anota os GUID que elimines, borra só os valores que pertencen ao cliente que se foi e reinicia para que o motor reconstrua o seu estado. Non borres toda a clave nin desactives Base Filtering Engine: a devasa de Windows e Defender dependen del, e cambiarías unha caída por outra peor.

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

En Linux, toma a liña que imprime iptables -S e substitúe -A por -D. Borrar a única regra que identificaches é mellor que baleirar unha cadea, porque deixa a túa propia política intacta.

sudo iptables -D OUTPUT -p udp -j REJECT

Se o descarte vive nunha cadea definida polo usuario, borra primeiro o salto a esa cadea e quita a cadea con -X despois. Pór a política dunha cadea en ACCEPT mentres as regras de descarte seguen presentes só axuda os paquetes que chegan á decisión de política. Baleirar todas as táboas é o último recurso: tamén elimina regras que engadiches por outros motivos, e con ufw activado deixa o servizo crendo que posúe cadeas que xa non existen.

Atopa o propietario que o volve pór

Despois da reparación inmediata, busca calquera cousa que puidese restaurar o estado. En Linux, comproba se hai unha unidade de persistencia habilitada, se o cliente ten un axuste de restauración da devasa ao iniciar sesión e se existe un ficheiro de regras gardado baixo /etc. En Windows, revisa de novo as entradas de inicio, os servizos e as tarefas programadas, despois reinicia e volve ler o estado cos mesmos comandos que antes.

Se o bloqueo volve, o borrado non era a solución; era o propietario. Anota que cliente ou servizo o instala e desactiva a función alí, en lugar de pelexar con ela na capa da devasa tras cada desconexión.

Verifica con tráfico real, non cun só ping

Proba unha consulta de nome, unha conexión TCP e unha sesión de navegador nova, despois reinicia e repite as mesmas tres comprobacións. Un ping que funciona mentres HTTPS falla apunta a un filtro da capa de transporte e non á rede, e un bloqueo que reaparece só tras o reinicio apunta a un propietario que aínda non atopaches.

Garda as probas: a clave BFE exportada ou a saída de iptables -S capturada antes do cambio. Antes de dalo por arranxado, confirma a capa da que eliminaches o obxecto, o propietario que podería reinstalalo, o estado tras un reinicio limpo e que a navegación ordinaria funciona sen ningún proceso VPN en marcha. A páxina do manual iptables(8) ten a sintaxe exacta de borrado e de política se automatizas a limpeza cun script.