Dy aplikacione VPN njëherësh: cili kill switch zbatohet në të vërtetë?
Një klient i dytë VPN nuk trashëgon kurrë kill switch-in e të parit. Tri kushte përcaktojnë cila politikë zbatohet, dhe si ta verifikoni tuajën.
Dy klientë VPN mund të punojnë krah për krah, por kill switch-et e tyre nuk bashkohen në një politikë të vetme. Secili klient instalon rregulla për tunelin e vet dhe asnjëri nuk e di se ekziston tjetri. Këtë e hasa me një klient pune të lidhur i pari: aplikacioni i dytë nuk arrinte ta përfundonte shtrëngimin e duarve, qëndroi në „Connecting“ për dhjetë minuta dhe tuneli i parë transportonte gjithçka në heshtje. Nëse aplikacioni i dytë mbrohet varet nga tri kushte, jo nga fakti nëse të dy ikonat thonë Lidhur.
Ku është i kufizuar në të vërtetë një kill switch
Asgjë në sistemin operativ nuk ka një flamur të vetëm kill switch. Një klient që reklamon një të tillë instalon një grup rregullash: hidh poshtë gjithçka që nuk del përmes tunelit tim dhe shpesh fail closed kur tuneli zhduket. Në Linux zakonisht është një zinxhir nftables ose iptables, në Windows një grup filtrash të Windows Filtering Platform, në Android dhe iOS rrugëtimi i vetë shërbimit të tunelit plus cilësimi i sistemit që bllokon lidhjet pa VPN. Udhëzuesi i VPN për Android e përshkruan atë model shërbimi nëse doni këndvështrimin e platformës.
Shtrirja është pjesa që ka rëndësi. Një rregull si „lejo vetëm paketat në ndërfaqen dalëse wg0“ nuk interesohet nëse ekziston një tunel i dytë. Nëse një klient tjetër ngre wg1, rregullat e klientit të parë i trajtojnë ato paketa si trafik të zakonshëm: zakonisht hidhen poshtë, ndonjëherë lejohen. Në çdo rast vendos klienti i parë dhe nuk e ka idenë se një aplikacion i dytë po pret.
Tri kushte që vendosin kush mbulohet
Nuk ju duhet të numëroni çdo kombinim. Tri pyetje e zgjidhin për disa minuta.
- A e lejon platforma fare një tunel të dytë? Shumica e telefonave Android dhe iPhone pranojnë vetëm një shërbim VPN aktiv për profil përdoruesi, kështu që aplikacioni i dytë nuk ka kurrë tunel dhe nuk zbaton kurrë asgjë. Ju merrni një politikë të vetme, nga aplikacioni që fitoi vendin.
- Cili proces zotëron rrugën e paracaktuar? Windows, macOS dhe Linux mbajnë pa problem dy tunele. Rruga e paracaktuar i përket klientit që e konfiguroi i fundit ose me metrikën më të mirë, dhe klienti tjetër është i lidhur por joaktiv. Në Linux mënyra e rrugës së paracaktuar e wg-quick përdor rrugëtim sipas politikës me një tabelë private dhe një rregull fwmark, kështu që një tunel i dytë wg-quick shton një rregull konkurrues në vend që të zëvendësojë të parin.
- A arrin klienti i dytë te serveri i vet? Nëse kill switch-i i parë është default-deny, pika e jashtme fundore e aplikacionit të dytë është thjesht një destinacion tjetër i hedhur poshtë. Ai riprovo në heshtje dhe nuk raporton kurrë gabim.
Versioni i shkurtër, për temat e mbështetjes:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Dy nga ato rreshta duken identikë nga ikona në tabaka e sistemit, prandaj ikona është prova më e dobët e disponueshme këtu.
Çfarë dështon i pari dhe si duket
Një klient i ngecur në „Connecting“ ndërsa tjetri është i shëndoshë është pothuajse gjithmonë uri për pikë fundore: kill switch-i aktiv hedh poshtë shtrëngimin e duarve të klientit të dytë drejt serverit të vet. Verifikojeni lirë duke ndalur përkohësisht rregullat bllokuese të klientit të parë për një provë. Nëse i dyti lidhet menjëherë, pyetja është përgjigjur.
DNS është dështimi i dytë. Klientët vendosin konfigurimin e zgjidhësit për ndërfaqen e tyre, dhe disa thjesht mbishkruajnë listën globale. Me të dy tunelat lart, pyetjet mund të dalin nga njëra anë ndërsa zgjidhësi i përket tjetrës. Shkëputni cilindo aplikacion dhe ai që mbijeton mban një server emrash të paarritshëm: faqet ngecin për një minutë dhe pastaj zgjidhen përsëri, ndërsa VPN vazhdon të tregojë të lidhur.
I treti është dridhja e rrugëve. Rilidhjet rirenditin rrugën e paracaktuar, dhe një kill switch i lidhur me ndërfaqen nuk e ndjek. Trafiku që ishte një çast më parë në tunel tani përputhet me një rregull hedhjeje, gjë që nga ana e përdoruesit lexohet si një VPN që ndalon rastësisht së punuari.
Verifikoni cila politikë është vërtet në fuqi
Bëjeni këtë me trafik të padëmshëm, jo me diçka që do t’ju mungonte.
Në Linux pyesni kernelin kush fiton dhe ku lidhet muri i zjarrit. ip -4 route show default emërton tunelin që zotëron daljen. ip rule show tregon nëse rrugëtimi sipas politikës është në lojë. sudo nft list ruleset | grep -n oifname tregon nëse hedhjet janë të lidhura me një emër ndërfaqeje, një shenjë apo të gjithë zinxhirin dalës.
Në Windows e njëjta histori jeton në metrikën e rrugës dhe listën e filtrave: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric dhe Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Në macOS, netstat -rn -f inet | head -5 dhe scutil --dns | head -20.
Pastaj bëni hapin që njerëzit e kapërcejnë: ndaloni tunelin me qëllim dhe konfirmoni se trafiku që prisni të dështojë dështon vërtet. Një ikonë e lidhur është gjendje e ndërfaqes, jo zbatim.
Kur dy klientë janë dizajni i gabuar
Nëse kërkesa e vetme pas aplikacionit të dytë është më shumë mbrojtje, hiqeni. Dy politika bllokuese që ndërveprojnë janë më pak të parashikueshme se një, dhe çdo rilidhje është një shans për të përfunduar në një gjendje që asnjë furnizues nuk e teston.
Nëse ju nevojitet vërtet zinxhirim, për shembull një portë korporative e arritur përmes një hop-i komercial, zgjidhni një dizajn me një pikë të vetme zbatimi. Kjo zakonisht do të thotë një ruter ose një klient i vetëm që mbështet zinxhirin, jo dy aplikacione desktop që garojnë për të njëjtën rrugë të paracaktuar. Në një pajisje të menaxhuar mbani klientin e miratuar dhe trajtoni çdo gjë tjetër si jashtë fushëveprimit, çfarëdo që tregon në tabaka.
Listë kontrolli përpara se t’i mbani të dy
Kaloni listën me radhë; pika e parë që dështon është ajo që duhet rregulluar.
- Konfirmoni se saktësisht një klient zotëron rrugën e paracaktuar dhe zgjidhësin.
- Nëse doni klientin e dytë lart, lejoni shprehimisht pikën fundore të serverit të tij dhe rikontrolloni pas çdo përditësimi të klientit.
- Shkruani rezultatin e pritur kur bie cilido tunel dhe provoni pikërisht atë rast.
- Kontrolloni rrugën e dështimit pas një rindezjeje, kur rendi i nisjes është i ndryshëm.
- Në një profil të menaxhuar, ndaloni dhe pyesni pronarin përpara se të shtoni çdo gjë.
Nëse hapi i tretë dështon, përgjigjja e sinqertë është se vetëm një klient po ju jep një politikë. Vendosni cilit i besoni dhe lëreni tjetrin të shkojë.