Dvě aplikace VPN najednou: který kill switch vlastně platí?

Dva klienti VPN mohou běžet vedle sebe, ale jejich kill switche se neslévají do jediné politiky. Každý klient instaluje pravidla pro svůj vlastní tunel a žádný z nich neví, že ten druhý existuje. Narazil jsem na to s firemním klientem připojeným jako první: druhá aplikace nedokončila handshake, zůstala deset minut na „Connecting“ a první tunel všechno tiše přenášel. Zda bude druhá aplikace chráněná, závisí na třech podmínkách, ne na tom, zda obě ikony říkají Připojeno.

K čemu je kill switch vlastně omezený

Nic v operačním systému nemá jediný přepínač kill switch. Klient, který nějaký inzeruje, nainstaluje sadu pravidel: zahazuj vše, co neodchází mým tunelem, a často fail closed, když tunel zmizí. V Linuxu je to obvykle řetěz nftables nebo iptables, ve Windows sada filtrů Windows Filtering Platform, v Androidu a iOS vlastní směrování tunelové služby plus systémové nastavení, které blokuje připojení bez VPN. Průvodce VPN v Androidu tento model služby popisuje, pokud chcete pohled platformy.

Rozsah je ta část, na které záleží. Pravidlo typu „povol jen pakety na výstupním rozhraní wg0“ se nestará o to, zda existuje druhý tunel. Když jiný klient zvedne wg1, pravidla prvního klienta považují tyto pakety za běžný provoz: obvykle zahozené, občas povolené. Ať tak či onak, rozhoduje první klient a nemá tušení, že druhá aplikace čeká.

Tři podmínky, které rozhodují, kdo bude krytý

Nemusíte vyjmenovat každou kombinaci. Tři otázky to vyřeší za pár minut.

1. Povoluje platforma vůbec druhý tunel? Většina telefonů s Androidem a iPhonů přijímá jen jednu aktivní službu VPN na uživatelský profil, takže druhá aplikace nikdy nemá tunel a nikdy nic nevynucuje. Dostanete jednu politiku – od aplikace, která místo vyhrála.
2. Který proces vlastní výchozí trasu? Windows, macOS a Linux unesou dva tunely bez potíží. Výchozí trasa patří klientu, který ji nastavil naposledy nebo s lepší metrikou, a druhý klient je připojený, ale nečinný. V Linuxu používá režim výchozí trasy wg-quick politické směrování se soukromou tabulkou a pravidlem fwmark, takže druhý tunel wg-quick přidá konkurenční pravidlo, místo aby to první nahradil.
3. Dostane se druhý klient na svůj vlastní server? Je-li první kill switch v režimu výchozího odmítnutí, je vnější koncový bod druhé aplikace jen další zahozený cíl. Zkouší to znovu tiše a nikdy neohlásí chybu.

Krátká verze pro supportní vlákna:

Dva z těchto řádků vypadají z ikony v oznamovací oblasti stejně, a proto je ikona tady nejhorší dostupný důkaz.

Co selže první a jak to vypadá

Klient uvízlý na „Connecting“, zatímco druhý je zdravý, je téměř vždy hladovění koncového bodu: běžící kill switch zahazuje handshake druhého klienta k jeho vlastnímu serveru. Potvrďte to levně pozastavením blokovacích pravidel prvního klienta na jeden pokus. Pokud se druhý připojí okamžitě, otázka je zodpovězená.

DNS je druhá porucha. Klienti nastavují konfiguraci resolveru pro své vlastní rozhraní a někteří prostě přepíšou globální seznam resolverů. Když jsou oba tunely nahoře, dotazy mohou odcházet jednou stranou, zatímco resolver patří té druhé. Odpojte kteroukoli aplikaci a přeživší si podrží nedostupný nameserver: stránky se na minutu zaseknou a pak se zase přeloží, zatímco VPN stále ukazuje připojeno.

Třetí je flapping tras. Opětovná připojení přehazují výchozí trasu a kill switch vázaný na rozhraní ji nenásleduje. Provoz, který byl před chvílí v tunelu, teď odpovídá pravidlu zahazování, což se uživateli čte jako VPN, která náhodně přestane fungovat.

Ověřte, která politika skutečně platí

Dělejte to s neškodným provozem, ne s něčím, co by vám chybělo.

V Linuxu se zeptejte jádra, kdo vyhrává a k čemu se firewall váže. ip -4 route show default pojmenuje tunel, kterému patří výstup. ip rule show ukáže, zda je ve hře politické směrování. sudo nft list ruleset | grep -n oifname ukáže, zda jsou zahazování vázaná na název rozhraní, značku nebo celý výstupní řetěz.

Ve Windows žije stejný příběh v metrice trasy a seznamu filtrů: 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.

Pak udělejte krok, který lidé přeskakují: zastavte tunel schválně a potvrďte, že provoz, u kterého čekáte selhání, opravdu selže. Připojená ikona je stav rozhraní, ne vynucení.

Kdy jsou dva klienti špatný návrh

Je-li jediným požadavkem za druhou aplikací větší ochrana, odstraňte ji. Dvě vzájemně působící blokovací politiky jsou méně předvídatelné než jedna a každé opětovné připojení je šance skončit ve stavu, který žádný dodavatel netestuje.

Pokud opravdu potřebujete řetězení, například firemní bránu dosaženou přes komerční přeskok, vyberte návrh s jediným místem vynucení. To obvykle znamená router nebo jediného klienta podporujícího řetěz, ne dvě desktopové aplikace závodící o stejnou výchozí trasu. Na spravovaném zařízení si nechte schváleného klienta a všechno ostatní považujte za mimo rozsah, ať v oznamovací oblasti ukazuje cokoli.

Kontrolní seznam, než si oba necháte

Projděte seznam popořadě; první položka, která selže, je ta, kterou je třeba opravit.

• Potvrďte, že právě jeden klient vlastní výchozí trasu a resolver.
• Chcete-li druhého klienta, povolte výslovně koncový bod jeho serveru a po každé aktualizaci klienta to zkontrolujte znovu.
• Zapište očekávaný výsledek, když jeden z tunelů spadne, a otestujte právě ten případ.
• Zkontrolujte cestu selhání po restartu, kdy je pořadí spouštění jiné.
• Na spravovaném profilu se zastavte a před přidáním čehokoli se zeptejte vlastníka.

Selže-li třetí krok, poctivá odpověď je, že vám politiku dává jen jeden klient. Rozhodněte, kterému věříte, a nechte druhý jít.