Dve aplikaciji VPN hkrati: kateri kill switch dejansko velja?
Drugi odjemalec VPN nikoli ne podeduje kill switcha prvega. Katera politika velja, odločajo trije pogoji — in kako preveriti svojo.
Dva odjemalca VPN lahko delujeta drug ob drugem, vendar se njuni kill switchi ne združijo v eno politiko. Vsak odjemalec namesti pravila za svoj predor in noben ne ve, da drugi obstaja. Na to sem naletel s službenim odjemalcem, povezanim prvim: druga aplikacija ni mogla dokončati rokovanja, deset minut je stala na »Connecting«, prvi predor pa je tiho nosil vse. Ali bo druga aplikacija zaščitena, je odvisno od treh pogojev, ne od tega, ali obe ikoni kažeta Povezano.
Na kaj je kill switch dejansko omejen
Nič v operacijskem sistemu nima ene same zastavice kill switch. Odjemalec, ki jo oglašuje, namesti nabor pravil: zavrzi vse, kar ne izhaja skozi moj predor, in pogosto fail closed, ko predor izgine. V Linuxu je to običajno veriga nftables ali iptables, v Windowsu nabor filtrov Windows Filtering Platform, v Androidu in iOSu lastno usmerjanje predorske storitve plus sistemska nastavitev, ki blokira povezave brez VPN. Vodnik po VPN v Androidu opisuje ta model storitve, če želite pogled s platforme.
Obseg je tisti del, ki šteje. Pravilo, kot je »dovoli samo pakete na izhodnem vmesniku wg0«, se ne meni, ali obstaja drugi predor. Če drug odjemalec dvigne wg1, pravila prvega odjemalca ta paketa obravnavajo kot običajen promet: običajno zavržen, včasih dovoljen. Kakor koli že, odloča prvi odjemalec in nima pojma, da druga aplikacija čaka.
Trije pogoji, ki odločajo, kdo bo pokrit
Ni treba našteti vsake kombinacije. Tri vprašanja to razrešijo v nekaj minutah.
- Ali platforma sploh dovoli drugi predor? Večina telefonov Android in iPhoneov sprejme samo eno dejavno storitev VPN na uporabniški profil, zato druga aplikacija nikoli nima predora in nikoli ničesar ne uveljavlja. Dobite eno politiko — od aplikacije, ki je dobila mesto.
- Kateri proces ima privzeto pot? Windows, macOS in Linux zlahka nosijo dva predora. Privzeta pot pripada odjemalcu, ki jo je nastavil zadnji ali z boljšo metriko, drugi odjemalec pa je povezan, a nedejaven. V Linuxu način privzete poti v wg-quick uporablja usmerjanje po politiki z zasebno tabelo in pravilom fwmark, zato drugi predor wg-quick doda konkurenčno pravilo, namesto da bi zamenjal prvega.
- Ali lahko drugi odjemalec doseže svoj strežnik? Če je prvi kill switch privzeto zaprt, je zunanja končna točka druge aplikacije le še en zavržen cilj. Tiho poskuša znova in nikoli ne javi napake.
Kratka različica za niti podpore:
| 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 |
Dve od teh vrstic sta z ikone v sistemski pladnji videti enaki, zato je ikona tu najslabši razpoložljivi dokaz.
Kaj odpove prvo in kako to izgleda
Odjemalec, obtičan na »Connecting«, medtem ko je drugi zdrav, je skoraj vedno lakota po končni točki: delujoči kill switch zavrže rokovanje drugega odjemalca do njegovega lastnega strežnika. To poceni potrdite tako, da za en poskus začasno ustavite pravila blokiranja prvega odjemalca. Če se drugi poveže takoj, je vprašanje odgovorjeno.
DNS je druga okvara. Odjemalci nastavijo konfiguracijo razreševalnika za svoj vmesnik, nekateri pa preprosto prepišejo globalni seznam. Z obema predoroma vzpostavljenima lahko poizvedbe odhajajo skozi eno stran, medtem ko razreševalnik pripada drugi. Odklopite katero koli aplikacijo in preživeli obdrži nedosegljiv strežnik imen: strani se za minuto ustavijo in se nato znova razrešijo, medtem ko VPN še vedno prikazuje povezano.
Tretji je plapolanje poti. Ponovne povezave preuredijo privzeto pot, kill switch, vezan na vmesnik, pa ji ne sledi. Promet, ki je bil trenutek prej v predoru, zdaj ustreza pravilu zavrnitve, kar se na strani uporabnika bere kot VPN, ki naključno preneha delovati.
Preverite, katera politika je res v veljavi
To naredite z neškodljivim prometom, ne s čim, kar bi vam manjkalo.
V Linuxu vprašajte jedro, kdo zmaga in na kaj se veže požarni zid. ip -4 route show default poimenuje predor, ki ima izhod. ip rule show pokaže, ali je v igri usmerjanje po politiki. sudo nft list ruleset | grep -n oifname pokaže, ali so zavrnitve vezane na ime vmesnika, oznako ali celotno izhodno verigo.
V Windowsu ista zgodba živi v metriki poti in seznamu filtrov: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric in Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". V macOSu netstat -rn -f inet | head -5 in scutil --dns | head -20.
Nato naredite korak, ki ga ljudje preskočijo: namenoma ustavite predor in potrdite, da promet, za katerega pričakujete, da bo propadel, res propade. Povezana ikona je stanje vmesnika, ne uveljavljanje.
Kdaj sta dva odjemalca napačna zasnova
Če je edina zahteva za drugo aplikacijo več zaščite, jo odstranite. Dve medsebojno delujoči politiki blokiranja sta manj predvidljivi kot ena, vsaka ponovna povezava pa je priložnost, da pristanete v stanju, ki ga noben ponudnik ne testira.
Če res potrebujete veriženje, na primer korporativni prehod prek komercialnega skoka, izberite zasnovo z eno točko uveljavljanja. To običajno pomeni usmerjevalnik ali enega odjemalca, ki podpira verigo, ne dveh namiznih aplikacij, ki se potegujeta za isto privzeto pot. Na upravljani napravi obdržite odobrenega odjemalca, vse drugo pa obravnavajte kot zunaj obsega, karkoli prikazuje v pladnju.
Kontrolni seznam, preden obdržite oba
Pojdite po seznamu po vrsti; prva postavka, ki odpove, je tista, ki jo je treba popraviti.
- Potrdite, da ima natanko en odjemalec privzeto pot in razreševalnik.
- Če želite drugi odjemalec dejavno, izrecno dovolite končno točko njegovega strežnika in znova preverite po vsaki posodobitvi odjemalca.
- Zapišite pričakovani izid, ko pade kateri koli predor, in preizkusite natanko ta primer.
- Preverite pot okvare po ponovnem zagonu, ko je vrstni red zagona drugačen.
- Na upravljanem profilu se ustavite in pred dodajanjem česarkoli vprašajte lastnika.
Če tretji korak odpove, je pošten odgovor, da vam politiko daje samo en odjemalec. Odločite se, kateremu zaupate, in pustite drugega.