Dvi VPN programos vienu metu: kuris kill switch iš tikrųjų galioja?
Antrasis VPN klientas niekada nepaveldi pirmojo kill switch. Kuri politika galioja, sprendžia trys sąlygos, ir kaip pasitikrinti savąją.
Du VPN klientai gali veikti greta, bet jų kill switch nesusilieja į vieną politiką. Kiekvienas klientas įdiegia taisykles savo tuneliui, ir nė vienas nežino, kad kitas egzistuoja. Su tuo susidūriau, kai pirmas buvo prisijungęs darbo klientas: antroji programa negalėjo užbaigti rankos paspaudimo, dešimt minučių kabojo ties „Connecting“, o pirmasis tunelis tyliai nešė viską. Ar antroji programa bus apsaugota, priklauso nuo trijų sąlygų, o ne nuo to, ar abi piktogramos rodo Prisijungta.
Ką kill switch iš tikrųjų apima
Nieko operacinėje sistemoje nėra vienos kill switch vėliavėlės. Klientas, kuris tokią reklamuoja, įdiegia taisyklių rinkinį: atmesk viską, kas neišeina per mano tunelį, ir dažnai fail closed, kai tunelis dingsta. Linuxe tai paprastai nftables arba iptables grandinė, Windowsuose Windows Filtering Platform filtrų rinkinys, Android ir iOS – pačios tunelio tarnybos maršrutizavimas plius sistemos nustatymas, blokuojantis ryšius be VPN. Android VPN vadove aprašytas šis tarnybos modelis, jei norite platformos požiūrio.
Apimtis – ta dalis, kuri svarbi. Taisyklė „leisti tik paketus išėjimo sąsajoje wg0“ nesidomi, ar egzistuoja antras tunelis. Jei kitas klientas pakelia wg1, pirmojo kliento taisyklės tuos paketus laiko įprastu srautu: dažniausiai atmetami, kartais leidžiami. Bet kuriuo atveju sprendžia pirmasis klientas, ir jis neturi supratimo, kad antroji programa laukia.
Trys sąlygos, lemiančios, kas bus uždengtas
Nereikia išvardyti kiekvienos kombinacijos. Trys klausimai tai išsprendžia per kelias minutes.
- Ar platforma apskritai leidžia antrą tunelį? Dauguma Android telefonų ir iPhone priima tik vieną aktyvią VPN tarnybą vienam naudotojo profiliui, tad antroji programa niekada neturi tunelio ir nieko neįgyvendina. Gaunate vieną politiką – iš programos, kuri laimėjo vietą.
- Kuris procesas valdo numatytąjį maršrutą? Windows, macOS ir Linux lengvai neša du tunelius. Numatytasis maršrutas priklauso klientui, kuris jį sukonfigūravo paskutinis arba su geresne metrika, o kitas klientas yra prisijungęs, bet neaktyvus. Linuxe wg-quick numatytojo maršruto režimas naudoja politikos maršrutizavimą su privačia lentele ir fwmark taisykle, todėl antras wg-quick tunelis prideda konkuruojančią taisyklę, o ne pakeičia pirmąją.
- Ar antrasis klientas pasiekia savo serverį? Jei pirmasis kill switch yra numatytai draudžiantis, antrosios programos išorinis galinis taškas yra tiesiog dar vienas atmestas adresas. Jis tyliai kartoja bandymus ir niekada nepraneša klaidos.
Trumpa versija palaikymo gijoms:
| 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 |
Dvi iš tų eilučių atrodo identiškai iš dėklo piktogramos, todėl piktograma čia yra blogiausias prieinamas įrodymas.
Kas sugenda pirmas ir kaip tai atrodo
Klientas, įstrigęs ties „Connecting“, kai kitas sveikas, beveik visada reiškia galinio taško badą: veikiantis kill switch atmeta antrojo kliento rankos paspaudimą jo paties serveriui. Patikrinkite tai pigiai sustabdę pirmojo kliento blokavimo taisykles vienam bandymui. Jei antrasis prisijungia iš karto, klausimas atsakytas.
DNS yra antras gedimas. Klientai nustato resolverio konfigūraciją savo sąsajai, o kai kurie tiesiog perrašo pasaulinį sąrašą. Kai abu tuneliai pakelti, užklausos gali išeiti per vieną pusę, nors resolveris priklauso kitai. Atjunkite bet kurią programą ir išgyvenusioji lieka su nepasiekiamu vardų serveriu: puslapiai užstringa minutei ir tada vėl išsprendžiami, o VPN vis dar rodo prisijungta.
Trečiasis – maršrutų plazdėjimas. Prisijungimai iš naujo pertvarko numatytąjį maršrutą, o prie sąsajos pririštas kill switch jo neseka. Srautas, kuris prieš akimirką buvo tunele, dabar atitinka atmetimo taisyklę, ir naudotojui tai atrodo kaip VPN, kuris atsitiktinai nustoja veikti.
Patikrinkite, kuri politika iš tikrųjų galioja
Darykite tai su nekenksmingu srautu, o ne su tuo, ko pasiilgtumėte.
Linuxe paklauskite branduolio, kas laimi ir prie ko prisiriša ugniasienė. ip -4 route show default įvardija tunelį, kuriam priklauso išėjimas. ip rule show parodo, ar žaidžiamas politikos maršrutizavimas. sudo nft list ruleset | grep -n oifname parodo, ar atmetimai pririšti prie sąsajos pavadinimo, žymės ar visos išėjimo grandinės.
Windowsuose ta pati istorija gyvena maršruto metrikoje ir filtrų sąraše: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric ir Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS – netstat -rn -f inet | head -5 ir scutil --dns | head -20.
Tada atlikite žingsnį, kurį žmonės praleidžia: sąmoningai sustabdykite tunelį ir patvirtinkite, kad srautas, kuris turėtų sugesti, tikrai sugenda. Prisijungusi piktograma yra sąsajos būsena, o ne vykdymas.
Kada du klientai yra netinkamas dizainas
Jei vienintelis reikalavimas už antrosios programos yra daugiau apsaugos, pašalinkite ją. Dvi sąveikaujančios blokavimo politikos yra mažiau nuspėjamos nei viena, ir kiekvienas prisijungimas iš naujo yra šansas atsidurti būsenoje, kurios nė vienas tiekėjas netikrina.
Jei tikrai reikia grandinimo, pavyzdžiui, įmonės šliuzo per komercinį šuolį, rinkitės dizainą su vienu vykdymo tašku. Tai paprastai reiškia maršrutizatorių arba vieną klientą, palaikantį grandinę, o ne dvi darbalaukio programas, varžančias dėl to paties numatytojo maršruto. Valdomame įrenginyje laikykitės patvirtinto kliento, o visa kita laikykite už apimties, kad ir ką jis rodytų dėkle.
Kontrolinis sąrašas prieš paliekant abu
Eikite sąrašą iš eilės; pirmasis nepavykęs punktas yra tas, kurį reikia taisyti.
- Patvirtinkite, kad tiksliai vienas klientas valdo numatytąjį maršrutą ir resolverį.
- Jei norite antrojo kliento, aiškiai leiskite jo serverio galinį tašką ir tikrinkite iš naujo po kiekvieno kliento atnaujinimo.
- Užsirašykite laukiamą rezultatą, kai krinta bet kuris tunelis, ir išbandykite būtent tą atvejį.
- Patikrinkite gedimo kelią po perkrovimo, kai paleidimo tvarka kitokia.
- Valdomame profilyje sustokite ir paklauskite savininko, prieš ką nors pridėdami.
Jei trečias žingsnis nepavyksta, sąžiningas atsakymas yra toks: politiką duoda tik vienas klientas. Nuspręskite, kuo pasitikite, ir paleiskite kitą.