Dwa klienty VPN na jednym pulpicie: co koliduje i co działa

Drugi klient łączy się, zasoby pierwszego przestają się rozwiązywać, a zgłoszenie mówi, że VPN służbowy zepsuł ten prywatny. Nic nie jest zepsute w sensie usterki: oba klienty robiły to, do czego zostały zaprojektowane, a maszyna ma tylko jedną tablicę routingu. Kolizja dotyczy czterech zasobów, które każdy klient uznaje za własne. Przejdź przez nie po kolei, a poprawka zwykle staje się decyzją projektową, a nie naprawą.

Krok 1: ustal, który klient posiada wyjście

Przeczytaj bieżącą decyzję wyjścia, zanim cokolwiek zmienisz. Wyszukanie trasy do adresu publicznego mówi, którego interfejsu i następnego skoku użyłby pakiet teraz, i to jest odpowiedź, kto wygrał. Porównaj to z nazwami interfejsów utworzonych przez klienty, które zwykle zawierają nazwę produktu lub protokołu. Jeśli wyszukanie wskazuje tunel, którego się nie spodziewałeś, kolizję już znalazłeś.

ip route get 1.1.1.1
ip route show default
route print

Niektóre klienty wcale nie zastępują trasy domyślnej; dodają dwie połowy, jedną dla dolnej połowy przestrzeni adresowej i jedną dla górnej, które razem obejmują wszystko. To pozostawia widoczną oryginalną trasę domyślną i sprawia, że ręczna naprawa wygląda poprawnie, podczas gdy ruch nadal wychodzi przez tunel. Czytaj metrykę i długość prefiksu, nie tylko obecność wpisu domyślnego.

Zatrzymaj się, jeśli oba klienty domagają się tego samego prefiksu z tą samą metryką. Jądro wybierze jeden, a drugi będzie wyglądał na połączony, nic nie przenosząc.

Krok 2: sprawdź resolver i nakładające się prefiksy

DNS to druga kolizja i daje charakterystyczny objaw: nazwy zawodzą, podczas gdy adresy działają. Każdy klient narzuca swój resolver, a ostatni zapisujący wygrywa dla kolejnych zapytań. Zapytaj usługę resolwera, czego używa dla każdego łącza, zamiast czytać stronę ustawień klienta.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Następnie porównaj prywatne prefiksy używane przez obie sieci. Jeśli obie strony przydzielają z tego samego zakresu, żadne rozwiązanie po stronie klienta tego nie naprawi, bo maszyna nie potrafi powiedzieć, które miejsce docelowe 10.0.0.0/8 należy do którego tunelu. Jedną stronę trzeba przenumerować lub przetłumaczyć, a to rozmowa z właścicielami sieci, nie zmiana konfiguracji. Nakładanie się to jedyna kolizja, w której uczciwa odpowiedź brzmi, że projekt musi się zmienić.

Zatrzymaj się tutaj, jeśli prefiksy się nakładają. Wszystko dalej na tej liście zakłada, że tak nie jest.

Krok 3: wybierz wzorzec separacji, który się utrzyma

Niezawodne wzorce unikają uruchamiania dwóch klientów przeciw tej samej tablicy routingu. Jeden klient z polityką split-tunelu, która dociera do obu sieci prywatnych jest najprostszy, pod warunkiem że cele się nie nakładają, a właściciel polityki się zgadza. Maszyna wirtualna lub przestrzeń nazw sieci to następny krok, bo każda dostaje własną tablicę i własny resolver.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Przestrzeń nazw daje taką samą separację jak maszyna wirtualna bez drugiego systemu operacyjnego, ale ma szorstkie krawędzie: urządzenie tunelu trzeba do niej przenieść, a aplikację uruchomić w jej wnętrzu. Osobne urządzenie fizyczne jest często najmniej zaskakującą opcją dla prywatnego VPN obok zarządzanego klienta służbowego. Układanie jednego tunelu w drugim nie jest wzorcem separacji; wewnętrzny punkt końcowy musi pozostać osiągalny przez zewnętrzny tunel, a taki układ dokłada jeszcze problemy z MTU i opóźnieniami.

Wybierz jeden wzorzec i zapisz dlaczego. Mieszanie przestrzeni nazw dla jednej aplikacji z split-tunellem dla reszty odtwarza pierwotną kolizję w trudniejszej do debugowania formie.

Krok 4: zweryfikuj obie sieci z tej samej sesji

Przetestuj jeden zasób w każdej sieci prywatnej ze środowiska, w którym aplikacja naprawdę działa, a nie ze swojej powłoki, jeśli aplikacja działa w przestrzeni nazw. Sprawdź razem interfejs wyjścia, rozwiązany adres i kod odpowiedzi, ponieważ sukces w jednym z trzech może ukryć błąd w pozostałych. Powtórz po restarcie, bo kolejność uruchamiania klientów decyduje o tym, kto wygrywa. Właśnie tę kolejność ludzie zapominają zapisać.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Zapisz wersje klientów, interfejsy, stan resolwera i prefiksy dla każdej sieci. Gdy klient się aktualizuje i zmienia zachowanie tras, ten zapis jest różnicą między pięciominutową poprawką a przebudową. Następna osoba nie podzieli twojej pamięci co do tego, który tunel wstał pierwszy.

Lista jest kompletna, gdy potrafisz nazwać interfejs, który posiada trasę domyślną, resolver używany przez każdą nazwę, wzorzec oddzielający drugi tunel i wynik jednego żądania na sieć po restarcie. Cokolwiek mniej to konfiguracja, która dziś działa przypadkiem.