Dwa klienty VPN naraz: kto wygrywa trasę domyślną?

Uruchamianie dwóch klientów VPN naraz to spór o routing, a nie ustawienie prywatności. Tunel, który posiada bardziej szczegółową trasę, odbiera ruch, a drugi pozostaje połączony, ale bezczynny. Brama korporacyjna widzi wtedy połączenie przychodzące z osobistego wyjścia, podczas gdy klient korporacyjny na twoim komputerze nadal widzi każdy adapter. Rozstrzygnięcie, który z tych dwóch faktów ma znaczenie, to całe ćwiczenie.

Tablica tras wybiera jednego zwycięzcę

Przechwyć tablicę przed i po uruchomieniu klienta korporacyjnego, i czytaj kolumnę interfejsu, a nie tylko cel. Zwykła trasa domyślna z zewnętrznego tunelu łatwo ustępuje, bo para /1 jest bardziej szczegółowa niż /0. Dosłowna para 0.0.0.0/1 i 128.0.0.0/1 obejmuje całą przestrzeń IPv4 w dwóch połowach i bije każdą pojedynczą trasę domyślną. Po zainstalowaniu zewnętrzny tunel nadal wygląda na połączony i nic nie przenosi.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

Routing oparty na politykach może całkowicie ominąć główną tablicę, więc czytaj zarówno reguły, jak i trasy. Reguła, która wysyła oznaczony ruch do innej tablicy, wygrywa przed sprawdzeniem głównej tablicy. Dzięki temu jedna aplikacja może pozostać na łączu fizycznym, podczas gdy wszystko inne korzysta z tunelu.

ip rule show

Windows rozstrzyga to metrykami

W systemie Windows zwycięzcą jest trasa o najniższej metryce dla celu, a dwa klienty mogą oba zainstalować trasę domyślną z różnymi metrykami. Czytaj tablicę i konfigurację interfejsu razem, bo adapter o niższej metryce nie zawsze jest tym, którego oczekujesz. Klient, który ustawia także metrykę interfejsu, może przesunąć trasę domyślną bez dodawania choćby jednej trasy. Przegrywający adapter pozostaje włączony i po prostu nic nie odbiera.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

Porównaj oba wyjścia i nazwij interfejs, który posiada 0.0.0.0/0. Jeśli oba klienty go sobie roszczą, decyduje metryka, dlatego test kolejności połączeń może wyglądać niekonsekwentnie na różnych maszynach. Jeśli żadne wyjście nie pokazuje bramy domyślnej, klient nie działa w pełnym tunelu i argument łańcucha jest bez znaczenia.

Dwóch obserwatorów, dwa różne widoki

Zdalna brama widzi jedno połączenie przychodzące z zewnętrznego wyjścia oraz wszystko, co klient przekazuje do swojego tunelu. Lokalny klient widzi adaptery, trasy i istnienie innego tunelu, ponieważ działa z uprawnieniami do ich tworzenia. Rozdzielenie tych widoków to sedno; twierdzenie, że klient nie może tego zauważyć, nie jest.

Załóż, że klient może wyliczyć, co chce, i planuj pod widok bramy. Projekt, który zależy od tego, że klient pozostanie ślepy, jest jedną aktualizację od zepsucia.

DNS i IPv6 to miejsca, w których łańcuch przecieka

DNS podąża za tym ustawieniem resolvera, które wygra, i nie jest to koniecznie ścieżka, którą podążają pakiety. Korporacyjny resolver osiągany przez tunel korporacyjny jest spójny z projektem; lokalny resolver osiągany poza nim nie jest, i ujawnia nazwy, które tunel miał ukryć. IPv6 to drugi przeciek: host z podwójnym stosem nadal używa IPv6 wobec celów, które tunel przenosi tylko przez IPv4. Sprawdzaj rodziny osobno, bo tunel tylko dla IPv4 nic nie mówi o trasach lub resolverach IPv6.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

Napraw resolver i trasę IPv6 świadomie, zamiast piętrzyć drugi tunel na wierzchu. Podwójna enkapsulacja kosztuje też MTU, więc mniejsze wewnętrzne MTU to pierwsza rzecz do wypróbowania, gdy strony się zacinają po podniesieniu łańcucha. Resolver, który odpowiada szybko, nie jest dowodem, że jest właściwy.