Zergatik kill switch batek trafikoa botatzen du zerbitzaria aldatzean
Zergatik blokeatzen duen kill switch batek trafikoak zerbitzari aldaketa batean, zer egiten duen bezeroak tarte horretan eta nola bereizi etenaldi normala blokeo itsatsi batetik.
Hurbilago ematen duen zerbitzari bat aukeratzen duzu, konektatu sakatzen duzu eta nabigatzaileak karga egiteari uzten dio tunel berria prest egon aurretik. Ikonoa konektatzen egoerara pasatzen da eta han geratzen da fitxa bakoitza denboraz kanpo geratzen den bitartean. Etenaldi hori normalean kill switch-a da, diseinatu bezala lan egiten: trafikoa blokeatuta dago bezeroak bidaltzeko tunelik ez duen bitartean. Etenaldia onargarria den ala ez bezeroak segundo horietan egiten duenaren eta blokeoa kentzen duenean benetan kentzen duenaren araberakoa da.
Zer egiten du bezeroak bi zerbitzari artean
Mutur-puntu aldaketa hainbat urrats dira, etengailu bat ez. Bezeroak uneko tunela botatzen du, bere blokeo-arauak eguneratzen ditu, mutur-puntu berria ebazten du eta tunelaren kanpotik iristen zaio, gero ibilbide berriak instalatu eta blokeoa altxatzen du. Sentitzen duzun hutsunea lehen urratsaren eta azkenaren artean dago.
Hemen ordenak garrantzi handiagoa du abiadurak baino. Blokeo-arauak mutur-puntu berrirako salbuespena baino lehenago sartzen badira, bezeroak ezin du esku-ematea osatu eta konektatzen egoeran geratzen da denbora-muga arte. Salbuespena zerbitzari zahararen helbidearen kopia bada, esku-emate berria irteerako beste pakete bat bezala ikusten da eta baztertu egiten da. Bi kasuak berdin ikusten dira nabigatzailetik, eta horregatik sei segundo igarota berreskuratzen den aldaketak eta inoiz berreskuratzen ez denak arrazoi bera parteka dezakete.
Mutur-puntu berriak zulo bat behar du blokeoan
Tunela eraikitzeko, bezeroak paketeak bidali behar ditu zerbitzari berriaren helbidera eta portura interfaze fisikoan, adibidez UDP 51820 WireGuard profila tipiko baterako edo 1194 eta 443 OpenVPN-rako, zure profilak agintzen duena agintzen duela. Trafiko hori ez dago sortzear den tunelaren barruan, beraz gailu osorako blokeo batek irentsi egiten du, dagokion baimen-araua ez badago.
Ostalari-izenean oinarritutako profilek bigarren baldintza gehitzen dute: bilaketa bera. Bezeroak mutur-puntua blokeoa altxatu aurretik ebazten badu, cachean gordetako helbidea erabil dezake, baina profilek helbideak aldatzen dituenean edo cacheko sarrera zahartzen denean, esku-ematea baimen-arauak estaltzen ez duen helbide batera doa. IPv6-k ikusgai egiten du hori, pilaketa bikoiko mutur-puntu batek A eta AAAA erregistroak argitara ditzakeelako, eta v4 helbidea soilik estaltzen duen baimen-arau batek bezeroa blokeatutako v6 helbide baten aurka berriro saiatzen uzten du.
Aukera-izenak eta lehenetsitako balioak bezeroaren eta bertsioaren arabera aldatzen dira, beraz irakurri zurearentzako dokumentatutako zerrenda, pantaila-argazkietatik asmatu beharrean. OpenVPN Connect-en ezarpenen erreferentzia hemen: openvpn.net/connect-docs/app-settings-windows bezero batek bere blokeo- eta tunel zatituaren aukerak nola deskribatzen dituen adibide bat da.
Fail-closed egoera-makina bat da, ez etengailu bat
Bezero gehienek blokeoa suebaki-politika gisa adierazten dute hiru egoeratan: tunela gorantz, trafikoa tunelatik eta blokeorik ez; tunela beherantz, blokeoa aktibo; eta trantsizioa, blokeoa aktibo gehi mutur-puntuarentzako aldi baterako salbuespenak. Hirugarren egoeran bizi dira akatsak, segundo pare batetan bitan aldatu behar delako, eta hortik irtetea lortzen ez denean blokeo iraunkor baten berdin-berdin ikusten delako.
Mekanismoa plataformaren arabera aldatzen da, eta huts egitea ere bai. Windows Filtering Platformeko iragazkiek pisuak dituzte, beraz zure baimena gainditzen duen blokeo-iragazki batek paketeak botatzen jarraitzen du baimena existitzen den arren, eta hildako bezero-prozesu baten atzean utzitako iragazkiek makina lineaz kanpo eduki dezakete aplikazioa joan ondoren. macOS bezeroek pf arauak aingura batean idazten dituzte normalean, non arauen ordenak eta erabaki azkarrek zehazten duten zein arau aplikatzen den. Linux bezeroek nftables edo iptables katea kudeatzen dute normalean drop politikarekin eta baimen esplizituekin mutur-puntuarentzat, tunelaren interfazearentzat eta loopbackarentzat. Androiden always-on VPN-a, VPN gabe konexioak blokeatzeko aukerarekin, taldeko zorrotzena da, sistema eragileak blokeoa gailu osoari aplikatzen diolako, ez aplikazioka.
WireGuardek bere oharra behar du, AllowedIPs bideratze-hautatzaile bat delako, ez blokeatzaile bat. Zein helburu sartzen diren tunelera erabakitzen du; ez du ezer egiten tunelik ez duen pakete bat Wi-Fi bidez irtetea eragozteko. WireGuard soilik eta suebaki-arau gabe dagoen konfigurazio batean, kill switch-a biderik ez egotea da berez, eta baztertutako esku-emate baten ondoren pakete erreal bat irten daiteke interfaze fisikoan.
Neurtu hutsunea, ikonoari begiratu beharrean
Ikusi paketeak, ez egoera-argia. Linuxen hasi ping geldo bat helbide publiko baten aurka terminal batean eta harrapatu tunelaren garraio-portua interfaze fisikoan beste batean:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Aldatu zerbitzaria bezeroan, biak martxan dauden bitartean. Hiru gauza dira garrantzitsuak: zenbat irauten duen pingen geldialdiak, harrapaketak esku-ematea mutur-puntu berrira iristen dela erakusten duen eta trafikoa bezeroaren egoera konektatua bihurtu aurretik edo ondoren itzultzen den. Ping hutsunea lehenago amaitzen bada, blokeoa goizegi altxatu da edo tunela indikatzaileak onartu baino lehen dago martxan. Hutsunea beranduago amaitzen bada, indikatzailea baikorra da.
Windowsen, netsh wfp show state kaptura bat idazten du, eta bertan bila ditzakezu oraindik dauden blokeo-iragazkiak bezeroak deskonektatuta dagoela dioen bitartean. macOSen, sudo pfctl -sr kargatutako arauak eta haien ordena zerrendatzen ditu. Lotu edozein kaptura bezeroaren beraren erregistroarekin; zure ping-en denbora-lerroak esaten dizu blokeoa berandu amaitu zen edo ez zen inoiz amaitu.
Iluntasun normala versus blokeo itsatsia
Etenaldi apur bat funtzioaren xedea da, beraz egin triajea edozein ezarpen aldatu aurretik:
| 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 |
Bigarren edo bosgarren errenkadan amaitzen baduzu, ez desgaitu kill switch-a probatzeko, horrek bideratze-akats bat isurketa bihurtzen duelako. Berrabiarazi bezeroaren zerbitzua, edo berrabiarazi makina iragazkiek prozesu-hilketa gainditzen duten lekuan, eta ikusi blokeoa garbitzen den. Garbitzen bada, akatsa aldaketaren osteko garbiketan dago, ez blokeoan bertan.
Zure hurrengo aldaketaren aurretik, egiaztatu lau gauza: mutur-puntuaren baimenak zure profilak ebazten dituen helbide-familia guztiak estaltzen ditu, bezeroaren erregistroak trantsizioa osatu dela erakusten du, zure ping probak hutsunea neurtzen du eta ez ikonoa, eta bezeroa ixteak konektibitate normala berreskuratzen du. Aldaketan zehar eusten duen eta gero askatzen duen kill switch batek bere lana egiten du. Goizegi edo inoiz askatzen ez duenak merezi du arazketa.