Kill switch bllokon serverin VPN para se të rrjedhë çdo trafik
Cilën fazë bllokon një kill switch: kërkimi i pikës fundore, rruga e jashtme, rruga e kthimit dhe përjashtimet e vjetruara të partnerëve — me numërues në vend të hamendjeve.
Kill switch-et dështojnë në një drejtim që njerëzit nuk e presin: janë ndërtuar për të bllokuar trafikun ndërsa tuneli është poshtë, dhe paketat që ndërtojnë tunelin janë vetë trafik. Kjo është e gjithë e meta. Një grup rregullash që hedh poshtë çdo gjë që nuk del përmes tunelit hedh poshtë edhe shtrëngimin e duarve që do ta ngrinte atë, ndaj klienti riprovan në cikël dhe gabimi i atribuohet fazës që kontrollohet e para. Përpara se të zgjerohet një mur zjarri, zbuloni se cila nga tri fazat po refuzohet: kërkimi i emrit, paketa e jashtme drejt partnerit apo përgjigjja që kthehet.
Si varen nga njëri-tjetri tuneli dhe transporti i tij
Lexoni një klient VPN si dy gjendje rrjeti që ndajnë një shteg të vetëm soketi. Përpara se tuneli të ekzistojë, klienti hap një soket në përshtatësin fizik dhe dërgon kuadro të kriptuara në adresën dhe portën e partnerit. Vetëm pasi ai shkëmbim ka sukses, ai krijon pajisjen e tunelit dhe instalon rrugët. Një kill switch është një politikë për gjendjen e dytë, e shkruar aq gjerësisht sa vlen për të dyja.
Rregullat e bazuara në ndërfaqe janë forma e zakonshme: pranoni atë që del përmes tun0 ose wg0, hidhni poshtë pjesën tjetër të shtegut të daljes. Ai formulim nuk mund të përjashtojë lidhjen e vetë klientit me serverin, ndaj një zbatim i saktë e shton atë përjashtim në mënyrë të qartë, dhe edhe ju kur shkruani rregulla me dorë. Rregullat për çdo aplikacion në Windows dhe macOS shmangin një pjesë të kësaj duke përputhur një proces në vend të një ndërfaqeje, por procesi duhet të dalë gjithsesi para se tuneli të ekzistojë.
Tri faza, sipas rendit në të cilin ndodhin
Faza e parë është zgjidhja. Kur profili ruan një emër hosti në vend të një adrese fjalë për fjalë, klienti ka nevojë për një përgjigje DNS përpara se të dërgojë çdo gjë. Një profil që e drejton DNS-në drejt zgjidhësit të tunelit krijon një rrugë pa krye: zgjidhësi arrihet vetëm përmes tunelit që kërkimi duhet ta mundësonte. Zgjidhja jashtë tunelit, ose fiksimi i pikës fundore në një adresë, e heq këtë paqartësi.
Faza e dytë është paketa e jashtme, e cila duhet t'i mbijetojë në këtë rend fillimisht rrugëtimit e pastaj murit të zjarrit. wireguard-tools merr përsipër gjysmën e rrugëtimit të kësaj për WireGuard duke shënuar paketat e veta dhe duke shtuar një rregull politike që ato të anashkalojnë rrugën e parazgjedhur që sapo instaloi; faqja e manualit të wg-quick përshkruan atë rregull dhe tabelën që përdor. Rindërtoni atë rrugëtim me dorë, ose lini një mjet të dytë të rishkruajë rregullat, dhe paketat e shënuara mund të dërgohen përsëri në tunelin që duhet të krijonin.
Faza e tretë është rruga e kthimit. Një shtrëngim duarsh pa përgjigje nuk është provë e një hedhjeje në dalje; është njëlloj i përputhshëm me një rregull hyrjeje të serverit ose me një pajisje NAT që harroi hartëzimin. Ndajini këto përpara se të prekni klientin.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Klientët regjistrojnë simptomën që zbulojnë, jo fazën që dështoi, ndaj tabela zakonisht është më e shpejtë se regjistri.
Numëruesit vendosin më shpejt se regjistrat
Në Linux, nft list ruleset ose iptables -vnL OUTPUT shtyp një numërues paketash për çdo rregull. Lidhu një herë, lëre të dështojë dhe pastaj lexo përsëri numëruesit. Një rregull, numëruesi i të cilit lëvizi, është një rregull që e goditi shtrëngimi i duarve; nëse askund nuk lëvizi gjë, paketa nuk arriti kurrë te muri i zjarrit. Kam parë një grup rregullash të hedhë poshtë shtrëngimin e vet të duarve, dhe vetëm numëruesit e thanë.
Për të dalluar kurrë nuk arriti te muri i zjarrit nga kurrë nuk doli nga hosti, vëzhgoni vetë ndërfaqen. ip -s link show dev wlan0 raporton paketat e dërguara, dhe tcpdump -ni wlan0 udp port 51820 tregon kuadrot. Nëse mbetet i sheshtë ndërsa klienti riprovan, defekti është mbi netfilter: mungon një rrugë drejt partnerit, një rregull politike tregon një pajisje që ende nuk ekziston, ose një gabim soketi që klienti e gëlltit.
Testoni përjashtimet me adresa dokumentacioni si 203.0.113.10, që një rrëshqitje të mos mund të sondojë hostin e dikujt tjetër.
Një përjashtim i vjetruar i pikës fundore lexohet si një rënie e serverit
Versioni më mashtrues shfaqet pasi adresa e partnerit ndryshon: një shërbim adresash dinamike e ka zhvendosur, hosti është rindërtuar, ose adresa e daljes së rrjetit tuaj është ndryshe. Përjashtimi ende emërton adresën e vjetër, ndaj paketat drejt asaj të re bien mbi rregullin e hedhjes. I njëjti konfigurim funksiononte dje, dhe për këtë arsye njerëzit fillojnë me diagnostikimin e serverit.
Një emër hosti brenda një rregulli muri zjarri nuk ju shpëton. Në nftables emri zgjidhet kur ngarkohet grupi i rregullave, ndaj fikson adresën që ekzistonte në atë moment dhe vjetrohet si një adresë fjalë për fjalë. Zgjidhja e qëndrueshme është të përditësohet përjashtimi kur ndryshon pika fundore dhe të mbahet i ngushtë: një adresë partneri, një port transporti. Një interval mjaft i gjerë për t'i mbijetuar një ndryshimi adrese është gjithashtu mjaft i gjerë për të lënë të dalë trafik të palidhur.
Kur kill switch-i ekzekutohet në hostin e serverit
E njëjta varësi ekziston në skajin tjetër, dhe atje është më e lehtë të të shpëtojë. Nëse makina që shërben si serveri juaj VPN ekzekuton gjithashtu një klient desktop me kill switch, ose një profil muri zjarri të kopjuar nga një laptop, rregullat e saj të hedhjes vlejnë për shërbimin që i përfundon tunelet. Përgjigjet ndaj shtrëngimit të duarve të klientit hidhen poshtë, ndaj çdo klient dështon të lidhet ndërsa serveri duket i shëndetshëm dhe ndërfaqja e tunelit rri e papërdorur.
Ai host ka nevojë për tri pranime të ngushta përpara hedhjes: portën e dëgjimit në ndërfaqen fizike, ndërfaqen e tunelit për trafikun e dekriptuar dhe përcjelljen nga tuneli drejt asaj që klientët duhet të arrijnë. Lexoni grupin e instaluar me nft list ruleset, iptables -S, ose pfctl -sr , përpara se të ndryshoni çdo gjë, dhe mbani mend se një grup rregullash i ruajtur i mbijeton rinisjes, ndaj një gabim atje i mbijeton procesit që e bëri.
Rendi i rikuperimit që e mban makinën të mbyllur
Punoni nga profili nga jashtë. Lexoni adresën dhe portën e partnerit që përdor klienti, konfirmoni që emri i hostit zgjidhet pa tunelin, pastaj shtoni një përjashtim për atë adresë dhe port vetëm në përshtatësin fizik. Rilidhuni dhe vëzhgoni numëruesin e dërgimit; një shtrëngim duarsh i përfunduar është sinjali që faza e dytë është rregulluar.
Lëreni pjesën tjetër të politikës së hedhjes në vend gjatë testimit. Një kontroll i padëmshëm është të provoni një lidhje me një adresë dokumentacioni të palidhur dhe të konfirmoni se skadon ende, gjë që tregon se kill switch-i funksionon dhe nuk është i fikur. Shtrëngoni përjashtimin kur tuneli të jetë i qëndrueshëm, dhe mos lini një leje të përhershme për gjithçka për binarin e klientit vetëm sepse është i përshtatshëm.
Nëse tuneli ngrihet dhe aplikacioni ende dështon, fazat e mbetura nuk janë kjo: DNS i ndarë, MTU dhe rrugëtimi për çdo aplikacion secili prodhon një tunel të lidhur me trafik të prishur, dhe secili ka një kontroll të parë të ndryshëm.