Miks kill switch lõikab serveri vahetamisel liikluse ära
Miks kill switch blokeerib liikluse serveri vahetamise ajal, mida klient selles aknas teeb ja kuidas eristada tavalist pausi kinnijäänud blokeeringust.
Valite serveri, mis tundub lähemal, vajutate ühenda ja brauser lõpetab laadimise enne, kui uus tunnel püsti on. Ikoon läheb ühendamise olekusse ja jääb sinna, kuni iga vahekaart aegub. See paus on tavaliselt kill switch, mis töötab nii nagu ette nähtud: liiklus on blokeeritud, kuni kliendil pole tunnelit, mille kaudu seda saata. Kas paus on vastuvõetav, sõltub sellest, mida klient nende sekundite jooksul teeb, ja sellest, kas blokeering tõstetakse siis, kui ta väidab, et tõsteti.
Mida klient kahe serveri vahel teeb
Lõpp-punkti vahetus on mitu sammu, mitte üks lüliti. Klient lammutab praeguse tunneli, uuendab oma blokeerimisreegleid, lahendab uue lõpp-punkti ja jõuab selleni väljaspool tunnelit, seejärel paigaldab uued marsruudid ja tõstab blokeeringu. Lünk, mida tunnete, asub esimese ja viimase sammu vahel.
Järjekord on siin tähtsam kui kiirus. Kui blokeerimisreeglid rakenduvad enne uue lõpp-punkti erandit, ei saa klient käepigistust lõpule viia ja jääb ühendamise olekusse kuni ajalõpuni. Kui erand on vana serveri aadressi koopia, näeb uus käepigistus välja nagu iga teine väljuv pakett ja visatakse ära. Mõlemad juhtumid näevad brauserist ühesugused välja, mistõttu kuue sekundi pärast taastuv vahetus ja see, mis ei taastu kunagi, võivad omada sama põhjust.
Uus lõpp-punkt vajab blokeeringusse auku
Tunneli ehitamiseks peab klient saatma pakette uue serveri aadressile ja pordile füüsilisel liidesel, näiteks UDP 51820 tüüpilise WireGuard-profiili puhul või 1194 ja 443 OpenVPN-i puhul, mida iganes teie enda profiil ette näeb. See liiklus ei ole tunneli sees, mis alles luuakse, seega kogu seadet hõlmav blokeering neelab selle, kui pole sobivat lubamisreeglit.
Hostinimepõhised profiilid lisavad teise nõude: otsing ise. Kui klient lahendab lõpp-punkti enne blokeeringu tõstmist, võib ta kasutada vahemällu salvestatud aadressi, kuid kui profiil aadresse pöörab või vahemällu salvestatud kirje vananeb, suundub käepigistus aadressile, mida lubamisreegel ei kata. IPv6 teeb selle nähtavaks, sest kahe virna lõpp-punkt võib avaldada nii A- kui AAAA-kirje ning ainult v4-aadressi kattev lubamisreegel jätab kliendi blokeeritud v6-aadressi vastu uuesti proovima.
Valikute nimed ja vaikeväärtused erinevad kliendi ja versiooni kaupa, seega lugege dokumenteeritud loendit oma kliendi jaoks, mitte ärge oletage ekraanipiltide põhjal. OpenVPN Connecti seadete viide aadressil openvpn.net/connect-docs/app-settings-windows on üks näide sellest, kuidas klient kirjeldab oma blokeerimis- ja jagatud tunneli valikuid.
Fail-closed on olekumasin, mitte lüliti
Enamik kliente väljendab blokeeringut tulemüüri poliitikana kolmes olekus: tunnel üleval, liiklus käib tunneli kaudu ja blokeeringut pole; tunnel maas, blokeering on aktiivne; ja üleminek, kus blokeering on aktiivne pluss ajutised erandid lõpp-punktile. Just kolmandas olekus elavad vead, sest see peab paar sekundi jooksul kaks korda muutuma, ja sealt mitte väljumine näeb täpselt välja nagu püsiv blokeering.
Mehhanism erineb platvormiti ja nii ka tõrge. Windows Filtering Platformi filtritel on kaalud, seega teie luba kaaluv blokeeriv filter jätkab pakettide äraviskamist ka siis, kui luba on olemas, ja filtrid, mille tapetud kliendiprotsess maha jättis võivad hoida masinat võrguühenduseta ka pärast rakenduse kadumist. macOS-i kliendid kirjutavad tavaliselt pf-reeglid ankrussa, kus reeglite järjekord ja kiired otsused määravad, milline reegel kehtib. Linuxi kliendid haldavad tavaliselt nftablesi või iptablesi ahelat drop-poliitikaga ja selgesõnaliste lubadega lõpp-punktile, tunneli liidesele ja loopbackile. Androidi alati sisse lülitatud VPN koos valikuga blokeerida ühendused ilma VPN-ita on rühma kõige rangem, sest operatsioonisüsteem rakendab blokeeringut kogu seadmele, mitte rakenduse kaupa.
WireGuard vajab oma märkust, sest AllowedIPs on marsruudi valija, mitte blokeerija. See otsustab, millised sihtkohad tunnelisse lähevad; see ei tee midagi, et takistada tunnelita paketil Wi-Fi kaudu väljumast. Ainult WireGuardi seadistuses ilma tulemüürireeglita on kill switch tegelikult marsruudi puudumine ja äravisatud käepigistuse järel võib füüsilisest liidesest väljuda tõeline pakett.
Mõõtke lünka, mitte ärge jälgige ikooni
Jälgige pakette, mitte olekutuld. Linuxis käivitage ühes terminalis aeglane ping avalikule aadressile ja püüdke teises terminalis füüsilisel liidesel kinni tunneli transpordiport:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Vahetage kliendis serverit, kui mõlemad töötavad. Tähtsad on kolm asja: kui kaua pingid seiskuvad, kas püüdmine näitab käepigistuse jõudmist uue lõpp-punktini ja kas liiklus taastub enne või pärast seda, kui kliendi olek muutub ühendatuks. Kui pingilünk lõpeb esimesena, on blokeering kas liiga vara tõstetud või on tunnel püsti enne, kui indikaator seda tunnistab. Kui lünk lõpeb hiljem, on indikaator liiga optimistlik.
Windowsis kirjutab netsh wfp show state hetktõmmise, millest saab otsida blokeerivaid filtreid, mis on endiselt olemas, kui klient väidab, et on ühenduseta. macOS-is loetleb sudo pfctl -sr laaditud reeglid ja nende järjekorra. Siduge kumbki hetktõmmis kliendi enda logiga; teie pingi ajajoon ütleb, kas blokeering lõppes hilja või ei lõppenud kunagi.
Tavaline pimenedus versus kinnijäänud blokeering
Mingi katkestus on selle funktsiooni mõte, seega hinnake olukorda enne mis tahes seade muutmist:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Kui satute teise või viiendasse ritta, ärge lülitage kill switchi testimiseks välja, sest see muudab marsruudivea lekkimiseks. Taaskäivitage kliendi teenus või taaskäivitage masin, kus filtrid peavad protsessi tapmisele vastu, ja vaadake, kas blokeering kaob. Kui kaob, on viga vahetamise aegses koristamises, mitte blokeeringus endas.
Enne järgmist vahetust kinnitage neli asja: lõpp-punkti luba katab iga aadressiperekonna, mille teie profiil lahendab, kliendi logi näitab ülemineku lõppemist, teie pingitest mõõdab lünka, mitte ikooni, ja kliendi sulgemine taastab tavapärase ühenduse. Kill switch, mis peab vahetuse ajal vastu ja vabastab pärast, teeb oma tööd. See, mis vabastab vara või mitte kunagi, on silumist väärt.