Dwa klienty VPN mogą działać obok siebie, ale ich kill switche nie łączą się w jedną politykę. Każdy klient instaluje reguły dla własnego tunelu i żaden nie wie o istnieniu drugiego. Trafiłem na to z klientem firmowym podłączonym jako pierwszy: druga aplikacja nie mogła dokończyć uzgadniania, wisiała na „Connecting” przez dziesięć minut, a pierwszy tunel po cichu przenosił wszystko. Czy druga aplikacja jest chroniona, zależy od trzech warunków, a nie od tego, czy obie ikony pokazują Połączono.

Do czego kill switch jest naprawdę ograniczony

Nic w systemie operacyjnym nie ma jednej flagi kill switcha. Klient, który taką reklamuje, instaluje zestaw reguł: odrzucaj wszystko, co nie wychodzi moim tunelem, i często fail closed, gdy tunel znika. W Linuksie to zwykle łańcuch nftables lub iptables, w Windowsie zestaw filtrów Windows Filtering Platform, w Androidzie i iOS własne trasowanie usługi tunelowej plus ustawienie systemowe blokujące połączenia bez VPN. Przewodnik po VPN w Androidzie opisuje ten model usługi, jeśli chcesz perspektywę platformy.

Zakres jest tą częścią, która ma znaczenie. Reguła w rodzaju „zezwalaj tylko na pakiety na interfejsie wyjściowym wg0” nie przejmuje się tym, czy istnieje drugi tunel. Jeśli inny klient podniesie wg1, reguły pierwszego klienta potraktują te pakiety jako zwykły ruch: zwykle odrzucany, czasem dozwolony. Tak czy inaczej decyduje pierwszy klient i nie ma pojęcia, że druga aplikacja czeka.

Trzy warunki, które decydują, kto jest objęty ochroną

Nie musisz wyliczać każdej kombinacji. Trzy pytania rozstrzygają to w kilka minut.

  1. Czy platforma w ogóle dopuszcza drugi tunel? Większość telefonów z Androidem i iPhone’ów akceptuje tylko jedną aktywną usługę VPN na profil użytkownika, więc druga aplikacja nigdy nie ma tunelu i nigdy niczego nie egzekwuje. Dostajesz jedną politykę – od aplikacji, która wygrała miejsce.
  2. Który proces jest właścicielem trasy domyślnej? Windows, macOS i Linux chętnie udźwigną dwa tunele. Trasa domyślna należy do klienta, który skonfigurował ją ostatni albo z lepszą metryką, a drugi klient jest połączony, ale bezczynny. W Linuksie tryb trasy domyślnej wg-quick używa trasowania politycznego z prywatną tabelą i regułą fwmark, więc drugi tunel wg-quick dodaje konkurencyjną regułę, zamiast zastępować pierwszą.
  3. Czy drugi klient dociera do własnego serwera? Jeśli pierwszy kill switch działa w trybie domyślnej odmowy, zewnętrzny punkt końcowy drugiej aplikacji jest po prostu kolejnym odrzuconym celem. Ponawia próby po cichu i nigdy nie zgłasza błędu.

Krótka wersja, dla wątków pomocy technicznej:

SetupWhat you actually get
Second client cannot hold a tunnelOne active policy; the other app only reports that it is waiting
Both tunnels up, second took the default routeThe 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 interfaceSecond client never connects; first tunnel unaffected
Both up, DNS written by whichever client ran lastName resolution breaks for one side when either tunnel drops

Dwa z tych wierszy wyglądają identycznie z ikony w zasobniku, dlatego ikona jest tu najgorszym dostępnym dowodem.

Co zawodzi pierwsze i jak to wygląda

Klient zawieszony na „Connecting”, gdy drugi jest zdrowy, to prawie zawsze głodzenie punktu końcowego: działający kill switch odrzuca uzgadnianie drugiego klienta z jego własnym serwerem. Potwierdź to tanio, wstrzymując reguły blokujące pierwszego klienta na jedną próbę. Jeśli drugi połączy się natychmiast, pytanie ma odpowiedź.

DNS to druga awaria. Klienci ustawiają konfigurację resolvera dla własnego interfejsu, a niektórzy po prostu nadpisują globalną listę resolverów. Przy obu aktywnych tunelach zapytania mogą wychodzić jedną stroną, choć resolver należy do drugiej. Rozłącz którąkolwiek aplikację, a ocalała zachowa nieosiągalny serwer nazw: strony zawieszają się na minutę i znów się rozwiązują, podczas gdy VPN nadal pokazuje połączenie.

Trzecia to flapping tras. Ponowne połączenia przestawiają trasę domyślną, a kill switch związany z interfejsem za nią nie podąża. Ruch, który chwilę wcześniej był w tunelu, pasuje teraz do reguły odrzucania, co po stronie użytkownika czyta się jako VPN, który losowo przestaje działać.

Sprawdź, która polityka jest naprawdę w mocy

Zrób to na nieszkodliwym ruchu, nie na czymś, za czym byś tęsknił.

W Linuksie zapytaj jądro, kto wygrywa i do czego przywiązuje się firewall. ip -4 route show default wskazuje tunel, do którego należy wyjście. ip rule show pokazuje, czy w grze jest trasowanie polityczne. sudo nft list ruleset | grep -n oifname pokazuje, czy odrzucenia są przywiązane do nazwy interfejsu, znacznika czy całego łańcucha wyjściowego.

W Windowsie ta sama historia żyje w metryce trasy i liście filtrów: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric i Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". W macOS netstat -rn -f inet | head -5 i scutil --dns | head -20.

Potem zrób krok, który ludzie pomijają: zatrzymaj tunel celowo i potwierdź, że ruch, który ma zawieść, naprawdę zawodzi. Połączona ikona to stan interfejsu, nie egzekwowanie.

Kiedy dwa klienty to zły projekt

Jeśli jedynym wymaganiem stojącym za drugą aplikacją jest więcej ochrony, usuń ją. Dwie oddziałujące polityki blokowania są mniej przewidywalne niż jedna, a każde ponowne połączenie to szansa na wylądowanie w stanie, którego żaden dostawca nie testuje.

Jeśli naprawdę potrzebujesz łańcuchowania, na przykład bramy firmowej osiąganej przez komercyjny przeskok, wybierz projekt z jednym punktem egzekwowania. To zwykle router albo jeden klient obsługujący łańcuch, a nie dwie aplikacje desktopowe ścigające się o tę samą trasę domyślną. Na urządzeniu zarządzanym trzymaj się zatwierdzonego klienta, a wszystko inne traktuj jako poza zakresem, cokolwiek pokazuje w zasobniku.

Lista kontrolna, zanim zatrzymasz oba

Przejdź listę po kolei; pierwszy punkt, który zawiedzie, jest tym do naprawy.

  • Potwierdź, że dokładnie jeden klient jest właścicielem trasy domyślnej i resolvera.
  • Jeśli chcesz drugiego klienta, zezwól wprost na punkt końcowy jego serwera i sprawdzaj ponownie po każdej aktualizacji klienta.
  • Zapisz oczekiwany wynik, gdy którykolwiek tunel padnie, i przetestuj właśnie ten przypadek.
  • Sprawdź ścieżkę awarii po restarcie, gdy kolejność startu jest inna.
  • Na profilu zarządzanym zatrzymaj się i zapytaj właściciela, zanim cokolwiek dodasz.

Jeśli trzeci krok zawiedzie, uczciwa odpowiedź brzmi: tylko jeden klient daje ci politykę. Zdecyduj, któremu ufasz, i pozwól drugiemu odejść.

Powiązane artykuły