Kaks VPN-rakendust korraga: milline kill switch tegelikult kehtib?
Teine VPN-klient ei päri kunagi esimese kill switchi. Milline poliitika kehtib, otsustavad kolm tingimust, ja kuidas kontrollida enda oma.
Kaks VPN-klienti võivad kõrvuti töötada, kuid nende kill switchid ei sulandu üheks poliitikaks. Iga klient paigaldab reeglid oma tunnelile ja kumbki ei tea, et teine olemas on. Mina põrkasin sellega kokku, kui esimesena oli ühendatud töökliendi: teine rakendus ei saanud kätlemist lõpetada, seisis kümme minutit „Connecting“ juures ja esimene tunnel kandis kõike vaikselt. Kas teine rakendus on kaitstud, sõltub kolmest tingimusest, mitte sellest, kas mõlemad ikoonid näitavad Ühendatud.
Millega kill switch tegelikult piirdub
Operatsioonisüsteemis pole ühtegi üksikut kill switchi lippu. Klient, mis sellist reklaamib, paigaldab reeglistiku: viska kõrvale kõik, mis ei välju minu tunnelist, ja sageli fail closed, kui tunnel kaob. Linuxis on see tavaliselt nftablesi või iptablesi ahel, Windowsis Windows Filtering Platformi filtrite kogum, Androidis ja iOS-is tunneliteenuse enda marsruutimine pluss süsteemiseade, mis blokeerib ühendused ilma VPN-ita. Androidi VPN juhend kirjeldab seda teenusemudelit, kui soovid platvormi vaadet.
Ulatus on see osa, mis loeb. Reegel nagu „luba ainult paketid väljundliidesel wg0“ ei hooli sellest, kas teine tunnel on olemas. Kui teine klient tõstab wg1, käsitlevad esimese kliendi reeglid neid pakette tavalise liiklusena: tavaliselt visatakse kõrvale, mõnikord lubatakse. Mõlemal juhul otsustab esimene klient ja tal pole aimugi, et teine rakendus ootab.
Kolm tingimust, mis otsustavad, kes on kaetud
Kõiki kombinatsioone pole vaja loetleda. Kolm küsimust lahendavad selle mõne minutiga.
- Kas platvorm üldse lubab teist tunnelit? Enamik Androidi telefone ja iPhone’e võtab vastu ainult ühe aktiivse VPN-teenuse kasutajaprofiili kohta, nii et teisel rakendusel pole kunagi tunnelit ega jõusta see midagi. Saad ühe poliitika – rakenduselt, mis koha võitis.
- Milline protsess omab vaikimisi marsruuti? Windows, macOS ja Linux kannavad mõlemat tunnelit muretult. Vaikimisi marsruut kuulub kliendile, kes selle viimasena või parema mõõdikuga seadistas, ja teine klient on ühendatud, kuid jõude. Linuxis kasutab wg-quicki vaikimisi marsruudi režiim poliitikapõhist marsruutimist privaatse tabeli ja fwmark-reegliga, nii et teine wg-quicki tunnel lisab konkureeriva reegli, mitte ei asenda esimest.
- Kas teine klient pääseb oma serverile? Kui esimene kill switch on vaikimisi keelav, on teise rakenduse välimine lõpp-punkt lihtsalt veel üks kõrvalevisatud sihtkoht. See proovib vaikselt uuesti ega teata kunagi veast.
Lühiversioon, tugilõimadele:
| 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 |
Kaks neist ridadest näevad süsteemisalve ikoonilt identsed välja, seepärast on ikoon siin halvim kättesaadav tõend.
Mis ebaõnnestub esimesena ja kuidas see välja näeb
Klient, mis jääb „Connecting“ juurde kinni, kui teine on terve, tähendab peaaegu alati lõpp-punkti nälga: töötav kill switch viskab teise kliendi kätlemise tema enda serveri poole kõrvale. Kinnita seda odavalt, peatades esimese kliendi blokeerivad reeglid üheks katseks. Kui teine ühendub kohe, on küsimus vastatud.
DNS on teine rike. Kliendid seadistavad resolveri konfiguratsiooni oma liidesele ja mõned kirjutavad lihtsalt globaalse nimekirja üle. Kui mõlemad tunnelid on üleval, võivad päringud väljuda ühelt poolt, samal ajal kui resolver kuulub teisele. Ühenda kumb tahes rakendus lahti ja ellujäänu jääb ligipääsmatu nimeserveriga: lehed takerduvad minutiks ja lahendatakse siis uuesti, samal ajal kui VPN näitab endiselt ühendatud olekut.
Kolmas on marsruutide laperdamine. Taasühendused järjestavad vaikimisi marsruudi ümber ja liidesega seotud kill switch ei järgi seda. Liiklus, mis hetk tagasi oli tunnelis, vastab nüüd kõrvaleviskamise reeglile, mis kasutaja jaoks loeb nagu VPN, mis juhuslikult töötamise lõpetab.
Kontrolli, milline poliitika tegelikult kehtib
Tee seda kahjutu liiklusega, mitte millegagi, mida sa igatsema jääksid.
Küsi Linuxis tuumalt, kes võidab ja millega tulemüür seotud on. ip -4 route show default nimetab tunneli, mis väljundit omab. ip rule show näitab, kas poliitikapõhine marsruutimine on mängus. sudo nft list ruleset | grep -n oifname näitab, kas kõrvaleviskamised on seotud liidese nime, märgise või kogu väljundahelaga.
Windowsis elab sama lugu marsruudi mõõdikus ja filtrite nimekirjas: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric ja Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS-is netstat -rn -f inet | head -5 ja scutil --dns | head -20.
Seejärel tee samm, mille inimesed vahele jätavad: peata tunnel meelega ja kinnita, et liiklus, mis peaks ebaõnnestuma, tõesti ebaõnnestub. Ühendatud ikoon on liidese olek, mitte jõustamine.
Millal on kaks klienti vale disain
Kui teise rakenduse ainus nõue on rohkem kaitset, eemalda see. Kaks vastastikku mõjuvat blokeerimispoliitikat on vähem ettearvatavad kui üks, ja iga taasühendus on võimalus sattuda olekusse, mida ükski tarnija ei testi.
Kui vajad tõesti aheldamist, näiteks ettevõtte väravat läbi kommerts-hüppe, vali disain ühe jõustamispunktiga. See tähendab tavaliselt ruuterit või üht klienti, mis ahelat toetab, mitte kahte töölauarakendust, mis sama vaikimisi marsruudi pärast võistlevad. Hallatud seadmes hoia sanktsioneeritud klienti ja käsitle kõike muud ulatusest väljas olevana, ükskõik mida see salves näitab.
Kontrollnimekiri enne, kui jätad mõlemad
Käi nimekiri järjekorras läbi; esimene ebaõnnestuv punkt on see, mida parandada.
- Kinnita, et täpselt üks klient omab vaikimisi marsruuti ja resolverit.
- Kui tahad teist klienti üles, luba selle serveri lõpp-punkt selgesõnaliselt ja kontrolli uuesti pärast iga kliendi uuendust.
- Kirjuta üles oodatav tulemus, kui kumb tahes tunnel maha kukub, ja testi just seda juhtumit.
- Kontrolli tõrketeed pärast taaskäivitust, kui käivitamise järjekord on teine.
- Hallatud profiilis peatu ja küsi omanikult enne, kui midagi lisad.
Kui kolmas samm ebaõnnestub, on aus vastus see, et poliitika annab sulle ainult üks klient. Otsusta, keda usaldad, ja lase teisel minna.