Comutatorul de siguranță blochează în continuare traficul după deconectarea VPN-ului

Tunelul a dispărut, pictograma de rețea arată normal și nimic nu se încarcă. Ai deconectat VPN-ul, l-ai dezinstalat sau ai repornit, iar blocajul care trebuia să te protejeze în timpul unei căderi încă stă în picioare. Fereastra clientului nu poate explica, pentru că nu clientul te blochează: decizia a fost scrisă în kernel în numele tău și nimic nu a fost lăsat în urmă ca să o elimine. În Windows starea aceea stă în Windows Filtering Platform; în Linux este un set de reguli în iptables sau nftables, adesea cu un instantaneu care este reaplicat la pornire. Ce urmează este ordinea pe care o folosesc: citește starea, șterge cel mai îngust obiect care explică defecțiunea, apoi găsește orice îl pune la loc.

Un comutator de siguranță este stare de kernel, nu o setare

Clienții desktop implementează blocarea adăugând filtre care refuză traficul din afara tunelului. În Windows acestea sunt filtre WFP la nivelurile connect-redirect și transport, iar unele sunt persistente: sunt înregistrate în depozitul de politici al Base Filtering Engine și restaurate la pornirea mașinii, înainte ca vreun software VPN să ruleze. Clienții diferă în privința momentului curățării. Unii elimină filtrele la deconectare, unii doar la o ieșire curată, iar unii doar când comutatorul este oprit mai întâi. Dezinstalează cât timp blocajul este activ, sau omoară procesul, și filtrele rămân.

Echivalentul în Linux este o regulă drop sau reject pe calea de ieșire, uneori o regulă de forwarding, uneori o politică de lanț modificată. Acele reguli supraviețuiesc procesului care le-a adăugat pentru că sunt stare de kernel: omoară clientul, provoacă un crash sau taie curentul, iar kernelul continuă să arunce pachete fără ca nimic să rămână pentru a anula asta. Un pachet de persistență adaugă un al doilea strat de permanență luând un instantaneu al setului curent de reguli și restaurându-l la pornire, așa că următoarea pornire începe cu blocajul deja instalat.

Citește starea WFP înainte de a șterge ceva

Windows vine cu instrumentele de care ai nevoie. Rulează un prompt cu privilegii și exportă starea platformei; dumpul ajunge ca wfpstate.xml în directorul de lucru.

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

Caută în XML numele furnizorului care a plecat, o acțiune Block și nivelul. Filtrele de pe connect-redirect și transport sunt cele care strică traficul obișnuit; un filtru pe un nivel receive-accept de obicei nu este cauza ta. Dacă Base Filtering Engine nu rulează deloc, caută în altă parte, pentru că nimic altceva nu poate impune acele filtre.

Verifică și vizualizarea obișnuită a firewall-ului, pentru că majoritatea oamenilor inspectează doar una din două:

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

Când profilele încorporate sunt pornite și nicio regulă nu corespunde traficului care eșuează, blocajul vine de la un furnizor terț, nu de la Windows Firewall. Această distincție decide ce instrument vei folosi pentru reparație.

Citește regulile Linux în sintaxa cu care vei șterge

iptables -S afișează regulile în aceeași formă folosită la adăugare, ceea ce face ieșirea direct reutilizabilă pentru o ștergere. iptables -L -v -n adaugă contoare de pachete, iar acele contoare îți spun dacă o regulă chiar corespunde cererilor tale eșuate sau doar stă în lanț.

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

Citește politicile lanțurilor, nu doar regulile: -P OUTPUT DROP blochează traficul chiar când nicio regulă nu corespunde. Inspectează IPv6 separat, pentru că un client care instalează ambele familii poate lăsa blocajul IPv6 pe loc după ce regulile IPv4 au dispărut, iar simptomul depinde atunci de familia preferată de aplicație. Unde se folosește nftables, rulează și nft list ruleset; cele două instrumente coexistă printr-un strat de compatibilitate, iar o singură listare nu arată neapărat fiecare regulă care poate arunca un pachet.

Șterge cel mai îngust obiect care explică defecțiunea

În Windows primul pas este încă calea de eliminare a furnizorului: rulează din nou instalatorul și folosește repair sau uninstall, sau rulează instrumentul de curățare dacă furnizorul publică unul. Servicii și sarcini programate rămase sunt frecvente, iar o sarcină care pornește clientul la logon reinstalează filtrele la următoarea pornire. O dezinstalare care eșuează la citirea cheii de registru a clientului înseamnă de obicei că un serviciu sau o sarcină încă o ține, nu că registrul este corupt.

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

Filtrele persistente sunt ultima soluție. Ele stau sub HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, o valoare per filtru cu cheie GUID. Exportă întâi cheia, notează GUID-urile pe care le elimini, șterge doar valorile care aparțin clientului plecat, apoi repornește ca motorul să-și reconstruiască starea. Nu șterge toată cheia și nu dezactiva Base Filtering Engine: Windows Firewall și Defender depind de el, iar ai schimba o întrerupere pe una mai rea.

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

În Linux, ia linia afișată de iptables -S și înlocuiește -A cu -D. Ștergerea singurei reguli pe care ai identificat-o bate golirea unui lanț, pentru că propria politică rămâne intactă.

sudo iptables -D OUTPUT -p udp -j REJECT

Dacă drop-ul stă într-un lanț definit de utilizator, șterge mai întâi saltul către acel lanț și apoi elimină lanțul cu -X. Setarea politicii lanțului pe ACCEPT cât timp regulile drop încă există ajută doar pachetele care ajung măcar la decizia de politică. Golirea tuturor tabelelor este ultima soluție: elimină și reguli adăugate din alte motive, iar cu ufw activat lasă serviciul să creadă că deține lanțuri care nu mai există.

Găsește proprietarul care îl pune la loc

După reparația imediată, caută ce ar restaura starea. În Linux, verifică dacă o unitate de persistență este activă, dacă clientul are o setare de restaurare a firewall-ului la logon și dacă există un fișier de reguli salvat sub /etc. În Windows, verifică din nou intrările de pornire, serviciile și sarcinile programate, apoi repornește și recitește starea cu aceleași comenzi ca înainte.

Dacă blocajul revine, ștergerea nu a fost soluția; proprietarul a fost. Notează care client sau serviciu îl instalează și dezactivează funcția acolo, în loc să te lupți cu ea la nivelul firewall-ului după fiecare deconectare.

Verifică cu trafic real, nu cu un singur ping

Testează o rezolvare de nume, o conexiune TCP și o sesiune nouă de browser, apoi repornește și repetă aceleași trei verificări. Un ping care funcționează când HTTPS eșuează indică un filtru la nivelul transport, nu rețeaua, iar un blocaj care reapare doar după repornire indică un proprietar pe care încă nu l-ai găsit.

Păstrează dovezile: cheia BFE exportată, sau ieșirea iptables -S capturată înainte de schimbare. Înainte să spui că e rezolvat, confirmă nivelul din care ai eliminat obiectul, proprietarul care l-ar putea reinstala, starea după o pornire curată și că navigarea obișnuită funcționează fără proces VPN. Pagina de manual iptables(8) are sintaxa exactă de ștergere și de politică dacă scrii curățarea ca script.