Dve aplikácie VPN naraz: ktorý kill switch vlastne platí?

Dvaja klienti VPN môžu bežať vedľa seba, ale ich kill switche sa nezlúčia do jedinej politiky. Každý klient inštaluje pravidlá pre svoj vlastný tunel a ani jeden nevie, že ten druhý existuje. Narazil som na to s firemným klientom pripojeným ako prvý: druhá aplikácia nedokončila handshake, zostala desať minút na „Connecting“ a prvý tunel všetko ticho prenášal. Či bude druhá aplikácia chránená, závisí od troch podmienok, nie od toho, či obe ikony hovoria Pripojené.

Na čo je kill switch vlastne obmedzený

Nič v operačnom systéme nemá jediný prepínač kill switch. Klient, ktorý nejaký inzeruje, nainštaluje sadu pravidiel: zahadzuj všetko, čo neodchádza mojím tunelom, a často fail closed, keď tunel zmizne. V Linuxe je to zvyčajne reťaz nftables alebo iptables, vo Windows sada filtrov Windows Filtering Platform, v Androide a iOS vlastné smerovanie tunelovej služby plus systémové nastavenie, ktoré blokuje pripojenia bez VPN. Sprievodca VPN v Androide tento model služby popisuje, ak chcete pohľad platformy.

Rozsah je tá časť, na ktorej záleží. Pravidlo typu „povoľ len pakety na výstupnom rozhraní wg0“ sa nestará o to, či existuje druhý tunel. Keď iný klient zdvihne wg1, pravidlá prvého klienta považujú tieto pakety za bežnú prevádzku: zvyčajne zahodené, občas povolené. Tak či onak rozhoduje prvý klient a nemá potuchy, že druhá aplikácia čaká.

Tri podmienky, ktoré rozhodujú, kto bude krytý

Nemusíte vymenovať každú kombináciu. Tri otázky to vyriešia za pár minút.

1. Povoľuje platforma vôbec druhý tunel? Väčšina telefónov s Androidom a iPhonov prijíma len jednu aktívnu službu VPN na používateľský profil, takže druhá aplikácia nikdy nemá tunel a nikdy nič nevynucuje. Dostanete jednu politiku – od aplikácie, ktorá miesto vyhrala.
2. Ktorý proces vlastní predvolenú trasu? Windows, macOS a Linux unesú dva tunely bez problémov. Predvolená trasa patrí klientovi, ktorý ju nastavil naposledy alebo s lepšou metrikou, a druhý klient je pripojený, ale nečinný. V Linuxe používa režim predvolenej trasy wg-quick politické smerovanie so súkromnou tabuľkou a pravidlom fwmark, takže druhý tunel wg-quick pridá konkurenčné pravidlo, namiesto toho aby to prvé nahradil.
3. Dostane sa druhý klient na svoj vlastný server? Ak je prvý kill switch v režime predvoleného odmietnutia, je vonkajší koncový bod druhej aplikácie len ďalší zahodený cieľ. Skúša to znova ticho a nikdy neohlási chybu.

Krátka verzia pre supportné vlákna:

Dva z týchto riadkov vyzerajú z ikony v oznamovacej oblasti rovnako, a preto je ikona tu najhorší dostupný dôkaz.

Čo zlyhá prvé a ako to vyzerá

Klient uviaznutý na „Connecting“, kým druhý je zdravý, je takmer vždy hladovanie koncového bodu: bežiaci kill switch zahadzuje handshake druhého klienta k jeho vlastnému serveru. Potvrďte to lacno pozastavením blokovacích pravidiel prvého klienta na jeden pokus. Ak sa druhý pripojí okamžite, otázka je zodpovedaná.

DNS je druhá porucha. Klienti nastavujú konfiguráciu resolvera pre svoje vlastné rozhranie a niektorí jednoducho prepíšu globálny zoznam resolverov. Keď sú oba tunely hore, dotazy môžu odchádzať jednou stranou, kým resolver patrí tej druhej. Odpojte ktorúkoľvek aplikáciu a tá, ktorá prežije, si podrží nedostupný nameserver: stránky sa na minútu zaseknú a potom sa zase preložia, kým VPN stále ukazuje pripojené.

Tretia je flapping trás. Opätovné pripojenia prehadzujú predvolenú trasu a kill switch viazaný na rozhranie ju nenásleduje. Prevádzka, ktorá bola pred chvíľou v tuneli, teraz zodpovedá pravidlu zahadzovania, čo sa používateľovi číta ako VPN, ktorá náhodne prestane fungovať.

Overte, ktorá politika skutočne platí

Robte to s neškodnou prevádzkou, nie s niečím, čo by vám chýbalo.

V Linuxe sa opýtajte jadra, kto vyhráva a na čo sa firewall viaže. ip -4 route show default pomenuje tunel, ktorému patrí výstup. ip rule show ukáže, či je v hre politické smerovanie. sudo nft list ruleset | grep -n oifname ukáže, či sú zahadzovania viazané na názov rozhrania, značku alebo celý výstupný reťaz.

Vo Windows žije rovnaký príbeh v metrike trasy a zozname filtrov: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric a Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". V macOS netstat -rn -f inet | head -5 a scutil --dns | head -20.

Potom urobte krok, ktorý ľudia preskakujú: zastavte tunel naschvál a potvrďte, že prevádzka, pri ktorej čakáte zlyhanie, naozaj zlyhá. Pripojená ikona je stav rozhrania, nie vynútenie.

Kedy sú dvaja klienti zlý návrh

Ak je jedinou požiadavkou za druhou aplikáciou väčšia ochrana, odstráňte ju. Dve vzájomne pôsobiace blokovacie politiky sú menej predvídateľné ako jedna a každé opätovné pripojenie je šanca skončiť v stave, ktorý žiadny dodávateľ netestuje.

Ak naozaj potrebujete reťazenie, napríklad firemnú bránu dosiahnutú cez komerčný preskok, vyberte návrh s jediným miestom vynútenia. To zvyčajne znamená router alebo jediného klienta podporujúceho reťaz, nie dve desktopové aplikácie pretekajúce o rovnakú predvolenú trasu. Na spravovanom zariadení si nechajte schváleného klienta a všetko ostatné považujte za mimo rozsahu, nech v oznamovacej oblasti ukazuje čokoľvek.

Kontrolný zoznam, kým si oboch necháte

Prejdite zoznam po poradí; prvá položka, ktorá zlyhá, je tá, ktorú treba opraviť.

• Potvrďte, že práve jeden klient vlastní predvolenú trasu a resolver.
• Ak chcete druhého klienta, povoľte výslovne koncový bod jeho servera a po každej aktualizácii klienta to skontrolujte znova.
• Zapíšte očakávaný výsledok, keď jeden z tunelov spadne, a otestujte práve ten prípad.
• Skontrolujte cestu zlyhania po reštarte, keď je poradie spúšťania iné.
• Na spravovanom profile sa zastavte a pred pridaním čohokoľvek sa opýtajte vlastníka.

Ak zlyhá tretí krok, úprimná odpoveď je, že politiku vám dáva len jeden klient. Rozhodnite, ktorému veríte, a nechajte druhý ísť.