Supraviețuiește un kill switch VPN unei reporniri? Cum verifici

Repornirea este cea mai obișnuită metodă prin care oamenii testează un kill switch și este testul care minte cel mai des. Căsuța din client este doar o preferință; contează dacă ceva impune o blocare între momentul în care stiva de rețea se ridică și momentul în care tunelul este efectiv stabilit. Pe Windows acel ceva este de obicei un filtru în Windows Filtering Platform, pe Linux un set de reguli încărcat de o unitate, pe macOS o ancoră pf, pe Android steagurile sistemului pentru always-on și blocare. Aceste aranjamente se comportă foarte diferit de-a lungul unei reporniri și doar cele la nivel de platformă sunt la locul lor înainte ca cineva să se poată autentifica.

O repornire pune trei întrebări separate

Împarte întrebarea. Întâi, politica există pe disc într-o formă pe care ceva o citește la pornire? Al doilea, acel cititor rulează înainte ca vreun trafic să poată ieși? Al treilea, politica acoperă traficul care te interesează, adică fiecare proces, ambele familii de adrese și DNS. Un da la prima și un nu la a doua produc exact defecțiunea pe care oamenii o raportează ca kill switch care nu supraviețuiește repornirii: traficul scapă câteva secunde la pornire și nimeni nu observă până nu se uită cineva.

Ține straturile separate. Un set de reguli de firewall salvat, un serviciu care pornește la boot și o preferință a clientului sunt trei obiecte diferite cu trei durate de viață diferite. Preferința supraviețuiește repornirilor pentru că este o valoare într-un fișier de configurare. Regulile sunt singurul lucru care blochează pachete, și ele dispar împreună cu nucleul care le ținea.

Găsește obiectul care reface blocarea

Pe Linux regulile netfilter trăiesc în nucleu. Nimic nu le rescrie la pornire dacă nu ai aranjat asta: iptables-save plus netfilter-persistent, nftables.service încarcă /etc/nftables.conf, sau o unitate systemd care rulează propriul tău script. Verifică ce este activat în loc de ce îți amintești că ai configurat.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Un set de reguli gol câteva secunde după pornire este răspunsul la întrebarea din titlu. Pe Windows întreabă serviciul clientului cum pornește, apoi extrage starea filtrului de platformă în timp ce tunelul este jos.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

A doua comandă scrie wfpstate.xml în directorul curent. Caută filtre cu o acțiune de blocare care există deja înainte ca clientul să se conecteze. Base Filtering Engine pornește devreme la boot și reface filtrele adăugate cu steagul persistent, de aceea unele kill switch-uri blochează traficul înainte să existe vreo fereastră de client, iar altele nu. Pe macOS sudo pfctl -s info raportează dacă pf este activat, sudo pfctl -s rules arată ce este încărcat, iar clienții VPN își atașează de obicei regulile la o ancoră în loc de setul principal. O regulă care numește utun3 poate indica altă interfață după următoarea pornire, pentru că numărul respectiv este atribuit la rulare.

Urmărește golul dintre ridicarea rețelei și ridicarea tunelului

Intervalul periculos nu este toată repornirea, este golul. Interfața primește un lease și o rută implicită într-un moment, serviciul VPN pornește în altul, iar tunelul se autentifică și mai târziu, uneori doar după ce un utilizator se autentifică și rulează un agent de acreditări. Dacă blocarea este aplicată ultima, tot ce este în gol iese în clar.

Pe gazde systemd citește ordinea în loc să o ghicești. Rulează systemctl cat pe unitățile VPN și de firewall și caută After= sau Before= față de network-pre.target și network-online.target. O unitate de firewall ordonată după network-online.target pierde în fața interfeței; cea cerută de și ordonată înainte de network-pre.target câștigă. Pe Windows întrebările echivalente sunt tipul de pornire al serviciului și dependențele lui, pentru că un serviciu setat pe Manual nu poate bloca un proces la boot. Dacă cerința ta include trafic înainte de autentificare, doar un aranjament la nivel de dispozitiv o satisface: un tunel de dispozitiv Always On VPN se autentifică cu un certificat de mașină și se conectează înainte ca utilizatorul să se autentifice, și Microsoft documentează configurația tunelului de dispozitiv separat de tunelul de utilizator. Android ia cealaltă cale, impune VPN always-on și blochează conexiunile fără el din sistem și nu dintr-un proces de aplicație.

Rulează testul, apoi compară două cronologii

Repornește cu o destinație care nu costă nimic dacă se scurge, și capturează starea în timpul golului, nu după el. Cea mai curată metodă este o sondă de pornire: o unitate oneshot sau o sarcină programată care pornește cât mai devreme permite platforma, înregistrează ruta implicită și starea firewall-ului, încearcă o singură cerere cu un timeout scurt și adaugă o linie la un fișier local. Compară acea înregistrare cu ora de pornire a serviciului VPN din journalctl -b -u sau din jurnalul sistemului.

Apoi rulează testul obișnuit: tunel sus, întrerupe conexiunea, urmărește dacă traficul direct este blocat, restaurează. Trecerea celui de-al doilea și eșecul la primul este rezultatul normal și înseamnă că impunerea este pe partea clientului, aplicată când clientul se conectează, nu la pornire. Pe ultima mașină pe care am auditat-o, blocarea venea dintr-un script dispatcher al NetworkManager: prezent și corect și inutil pentru secundele dinainte ca interfața să se ridice. Notează ambele rezultate, pentru că supraviețuirea unei reporniri înseamnă ceva doar când spui ce strat a supraviețuit și din ce moment.

Închide golul fără să-ți tai calea de întoarcere

Dacă blocarea lipsește la boot, coboară impunerea un strat mai jos în loc să adaugi o a doua regulă de client. Salvează setul de reguli și încarcă-l dintr-o unitate ordonată înainte ca rețeaua să fie utilizabilă, și asigură-te că acea unitate nu are nevoie de o interogare DNS sau de o montare de rețea pe care ar trebui să o protejeze. Domeniul contează la fel de mult ca momentul: regulile care se potrivesc cu un ID de utilizator sau cu un cgroup lasă fiecare daemon de sistem în afara blocării, iar un set de reguli care tratează doar IPv4 lasă IPv6 și DNS accesibile.

Păstrează-ți o cale de întoarcere. O mașină care blochează tot la boot și apoi nu se poate autentifica nu are deloc rețea, iar remediul nu este să ștergi blocarea, ci să repari acreditarea sau ordinea. Menține o procedură documentată pentru consola locală și o excepție îngustă și deliberată pentru ce are tunelul cu adevărat nevoie, cum ar fi adresa serverului și resolver-ul folosit înainte ca tunelul să existe.

Înainte să ai încredere în aranjament, confirmă patru lucruri în ordine. Politica este stocată unde citește pornirea. Acel cititor rulează înainte ca interfața să fie utilizabilă. Blocarea acoperă ambele familii de adrese și DNS. VPN-ul se poate încă autentifica în timp ce blocarea este activă. Când toate patru se verifică, o repornire nu schimbă nimic.