Rakenduse kill switch versus tulemüüri kill switch: mida kumb blokeerib

Funktsioonide nimekirjas olev kill switch ei ütle peaaegu midagi selle kohta, mis juhtub siis, kui tunnel katkeb. Üks teostus sulgeb valitud protsessid, teine paigaldab paketifiltrid operatsioonisüsteemi piirile ja kolmas lihtsalt üritab uuesti ühenduda. Erinevus ilmneb sekundites pärast riket, mitte seadete ekraanil. Käige need kontrollid järjest läbi ja peatuge esimesel, millele te ei suuda ausalt vastata, sest seal lõpeb teie tegelik katvus.

Nimetage esmalt jõustamismehhanism

Protsessi lõpetamine on rakenduse elutsükli funktsioon. See leiab pärast tuvastatud tunneli riket valitud programmid ja sulgeb need. Kõik, mis ei ole põhiprotsess, jääb ellu: abiteenused, taustasünkroonimine ja iga sekund hiljem käivitatud rakendus, neil kõigil on oma elutsükkel ja oma ajastus.

Paketifiltreerimine on operatsioonisüsteemi funktsioon. See keeldub liiklusest, mis ei järgi lubatud teed, mis on tugevam lubadus, kuid ainult ulatuses, millega reegel tegelikult kattub. Aadressipere, liides, välistatud rakendused ja erandid otsustavad selle, mitte kliendi silt.

Kas blokeering elab kliendist kauem?

Esitage neli küsimust selles järjekorras: mis juhtub krahhi korral, käsitsi väljumisel, väljalogimisel ja taaskäivitamisel. Reegel, mida klient ise haldab, eemaldatakse tavaliselt korrektsel sulgemisel ja sageli jääb alles pärast krahhi. Platvormi hoidlasse paigaldatud reegel võib käituda vastupidi: jääda alles nii kliendist kui mõnikord ka desinstallimisest.

Sulgege klient keset pikka allalaadimist ja vaadake, kas ülekanne seiskub või jätkub.

Otsige tavalisi auke

IPv6 on esimene. IPv4-aadresside jaoks kirjutatud reegel jätab IPv6-liikluse puutumata ja paljud kliendid kirjutavad ainult v4 poole. Teine on liides: USB-tethering, teine Wi-Fi-adapter ja mobiilmodem ei pruugi kuuluda peamise ühendusega piiratud reeglisse. Välistatud rakendused ja kohaliku võrgu erandid on kolmas.

Windowsis saate paigaldatud reegleid lugeda, selle asemel et lülitit usaldada: Get-NetFirewallRule -DisplayName '*VPN*' ja netsh wfp show filters näitavad mõlemad, mis olemas on. Linuxis katavad iptables -S, ip6tables -S ja nft list ruleset tavalised juhtumid ning kõigi kolme võrdlemine ongi mõte.

DNS on tavaline leke

TCP blokeerimine, jättes UDP 53 avatuks, annab väga veenva kill switchi, mis vastab siiski igale hostinime päringule. Sama kehtib siis, kui DNS antakse teise liidese resolverile, või kui klient blokeerib ainult v4 ja resolver on kättesaadav v6 kaudu.

Kui tunnel on maas, lahendage üks tuntud nimi ja vaadake, kas vastus tuleb tagasi. Kui tuleb, ei ole liiklus täielikult blokeeritud, ükskõik mida olekuikoon ütleb.

Testige üleminekut, mitte lülitit

VPN-i väljalülitamine selle enda menüüst on korrektne sulgemine ja korrektset juhtumit käsitleb iga teostus hästi. Oluline üleminek on järsk: tapke tunneli protsess, tõmmake võrk välja, laske serveril vastamine lõpetada. Seejärel käivitage päring ja vaadake, kas see ebaõnnestub või kasutab vaikselt füüsilist ühendust.

Ühe sülearvuti tulemus ei kandu üle telefonile ega ruuterile. Erinevad platvormi API-d, erinevad vaikeväärtused ja Androidis on erinevus terav: blokeerimisega always-on režiimi jõustab süsteem, mitte klient, seega see töötab edasi ka siis, kui klient ei tööta. Androidi VPN-i juhend kirjeldab seda jaotust.

Jätke tagasitee

Süsteemitasandil blokeerimisel on vastupidine rikkerežiim. Kliendist kauem püsivad filtrid võivad jätta masina pärast desinstallimist täiesti võrguühenduseta, mis on tugikõne ilma ilmse põhjuseta. Enne mis tahes kill switchi lubamist, mis kirjutab platvormi reegleid, pange kirja, kuidas seda eemaldatakse, ja hoidke müüja parandustee seal, kust te selle leiate.

Kui te ei suuda oma kliendi jaoks vastata krahhi, IPv6, DNS-i ja ülemineku kontrollidele, käsitlege seda rakendustasandi lülitina teadaolevate aukudega ja planeerige vastavalt.