Pse një kill switch ndërpret trafikun kur ndryshon serverin
Pse një kill switch bllokon trafikun gjatë një ndryshimi serveri, çfarë bën klienti në atë dritare dhe si të dallosh një pauzë normale nga një bllokim i ngecur.
Zgjidhni një server që duket më afër, shtypni lidh, dhe shfletuesi ndalon së ngarkuari përpara se tuneli i ri të ngrihet. Ikona kalon në një gjendje lidhjeje dhe qëndron atje derisa çdo skedë të skadojë. Ajo pauzë zakonisht është kill switch-u që punon siç është projektuar: trafiku bllokohet për sa kohë klienti nuk ka një tunel për ta dërguar. Nëse pauza është e pranueshme varet nga ajo që bën klienti në ato sekonda dhe nga fakti nëse bllokimi hiqet kur thotë se hiqet.
Çfarë bën klienti midis dy serverëve
Ndryshimi i pikës fundore është disa hapa, jo një çelës i vetëm. Klienti çmonton tunelin aktual, përditëson rregullat e bllokimit, zgjidh dhe arrin pikën e re fundore jashtë tunelit, pastaj instalon rrugët e reja dhe ngre bllokimin. Hendeku që ndjeni ndodhet midis hapit të parë dhe të fundit.
Rendi këtu ka më shumë rëndësi se shpejtësia. Nëse rregullat e bllokimit hyjnë në fuqi përpara përjashtimit për pikën e re fundore, klienti nuk mund ta përfundojë shtrëngimin e duarve dhe mbetet në lidhje derisa të skadojë. Nëse përjashtimi është një kopje e adresës së serverit të vjetër, shtrëngimi i ri i duarve duket si çdo paketë tjetër dalëse dhe hidhet. Të dyja rastet duken njësoj nga shfletuesi, dhe për këtë arsye një ndryshim që rikuperohet pas gjashtë sekondash dhe një që nuk rikuperohet kurrë mund të kenë të njëjtën shkak.
Pika e re fundore ka nevojë për një vrimë në bllokim
Për të ndërtuar tunelin, klienti duhet të dërgojë paketa në adresën dhe portin e serverit të ri përmes ndërfaqes fizike, për shembull UDP 51820 për një profil tipik WireGuard ose 1194 dhe 443 për OpenVPN, çfarëdo që përcakton profili juaj. Ai trafik nuk është brenda tunelit që sapo po krijohet, prandaj një bllokim për të gjithë pajisjen e gëlltit, përveç nëse ekziston një rregull leje që përputhet.
Profilet e bazuara në emrin e hostit shtojnë një kërkesë të dytë: vetë kërkimi. Nëse klienti e zgjidh pikën fundore përpara se bllokimi të ngrihet, mund të përdorë një adresë të ruajtur në cache, por kur profili rrotullon adresat ose hyrja në cache vjetrohet, shtrëngimi i duarve shkon drejt një adrese që rregulli i lejes nuk e mbulon. IPv6 e bën këtë të dukshme, sepse një pikë fundore me dy shtresa mund të publikojë si regjistrimin A ashtu edhe AAAA, dhe një rregull leje që mbulon vetëm adresën v4 e lë klientin duke riprovuar kundër një adrese v6 të bllokuar.
Emrat e opsioneve dhe vlerat e paracaktuara ndryshojnë sipas klientit dhe versionit, prandaj lexoni listën e dokumentuar për tuajin në vend që të hamendësoni nga pamje ekrani. Referenca e cilësimeve të OpenVPN Connect në openvpn.net/connect-docs/app-settings-windows është një shembull se si një klient përshkruan opsionet e tij të bllokimit dhe të tunelit të ndarë.
Fail-closed është një makinë gjendjesh, jo një çelës
Shumica e klientëve e shprehin bllokimin si politikë muri zjarri në tre gjendje: tunel lart, me trafikun që kalon nëpër tunel dhe pa bllokim; tunel poshtë, me bllokimin aktiv; dhe tranzicion, me bllokimin aktiv plus përjashtime të përkohshme për pikën fundore. Pikërisht në gjendjen e tretë banojnë defektet, sepse duhet të ndryshojë dy herë brenda pak sekondash, dhe mosdalja prej saj duket saktësisht si një bllokim i përhershëm.
Mekanizmi ndryshon sipas platformës, dhe dështimi gjithashtu. Filtrat e Windows Filtering Platform mbajnë pesha, prandaj një filtër bllokimi që tejkalon lejen tuaj vazhdon të hedhë paketa edhe pse leja ekziston, dhe filtrat e lënë nga një proces klienti i vrarë mund ta mbajnë makinën jashtë linje pasi aplikacioni zhduket. Klientët macOS zakonisht shkruajnë rregulla pf në një ankorë, ku rendi i rregullave dhe vendimet e shpejta përcaktojnë cili rregull zbatohet. Klientët Linux zakonisht menaxhojnë një zinxhir nftables ose iptables me politikë drop dhe leje të shprehura për pikën fundore, ndërfaqen e tunelit dhe loopback. Mënyra always-on VPN e Android me opsionin për të bllokuar lidhjet pa VPN është më e rrepta në grup, sepse sistemi operativ e zbaton bllokimin për të gjithë pajisjen dhe jo për çdo aplikacion.
WireGuard meriton një shënim të vetin, sepse AllowedIPs është një përzgjedhës rrugëtimi, jo një bllokues. Ai vendos cilat destinacione hyjnë në tunel; nuk bën asgjë për të ndaluar një paketë që nuk ka ende tunel të dalë përmes Wi-Fi. Në një konfigurim vetëm me WireGuard dhe pa rregull muri zjarri, kill switch-u është në të vërtetë mungesa e një rruge, dhe pas një shtrëngimi duarsh të hedhur mund të dalë një paketë e vërtetë përmes ndërfaqes fizike.
Matni hendekun në vend që të shikoni ikonën
Vëzhgoni paketat, jo dritën e statusit. Në Linux nisni një ping të ngadaltë drejt një adrese publike në një terminal dhe kapni portin e transportit të tunelit në ndërfaqen fizike në një tjetër:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Ndryshoni serverin në klient ndërsa të dy po punojnë. Tre gjëra kanë rëndësi: sa kohë ndalen ping-ët, nëse kapja tregon se shtrëngimi i duarve arrin pikën e re fundore dhe nëse trafiku kthehet përpara ose pasi gjendja e klientit kalon në të lidhur. Nëse hendeku i ping-ëve mbaron i pari, ose bllokimi është hequr shumë herët ose tuneli është lart përpara se treguesi ta pranojë. Nëse hendeku mbaron më vonë, treguesi është tepër optimist.
Në Windows, netsh wfp show state shkruan një pamje ku mund të kërkoni filtra bllokimi që ekzistojnë ende ndërsa klienti pretendon se është i shkëputur. Në macOS, sudo pfctl -sr liston rregullat e ngarkuara dhe rendin e tyre. Lidhni cilëndo pamje me regjistrin e vetë klientit; vija kohore nga ping-u juaj ju tregon nëse bllokimi mbaroi vonë ose nuk mbaroi kurrë.
Errësim normal kundrejt bllokimit të ngecur
Pak ndërprerje është pikërisht qëllimi i funksionit, prandaj bëni triazh përpara se të ndryshoni çdo cilësim:
| 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 |
Nëse përfundoni në rreshtin e dytë ose të pestë, mos e çaktivizoni kill switch-un për provë, sepse kjo e kthen një defekt rrugëtimi në rrjedhje. Rinisni shërbimin e klientit, ose rinisni makinën atje ku filtrat mbijetojnë vrasjen e një procesi, dhe shikoni nëse bllokimi pastrohet. Nëse pastrohet, faji është në pastrimin gjatë ndryshimit dhe jo në vetë bllokimin.
Përpara ndryshimit tuaj të radhës, konfirmoni katër gjëra: leja e pikës fundore mbulon çdo familje adresash që zgjidh profili juaj, regjistri i klientit tregon tranzicionin e përfunduar, testi juaj i ping-ut mat hendekun dhe jo ikonën, dhe mbyllja e klientit rivendos lidhjen normale. Një kill switch që mban gjatë ndryshimit dhe lëshon pas tij e bën punën e vet. Një që lëshon herët, ose kurrë, ia vlen të korrigjohet.