Dwa klienty VPN, jedna tablica routingu: kto zdobywa trasę domyślną

Wygląda to tak, jakby dwa klienty VPN walczyły o to samo gniazdo, a oczywistym rozwiązaniem musi być odinstalowanie jednego. W praktyce rzadko dotykają tego samego gniazda. Każde połączenie przepisuje tablicę routingu systemu operacyjnego, a profil pełnego tunelu zajmuje trasę domyślną. Zwykle wygrywa ten, kto połączył się ostatni, dlatego objaw zdaje się przenosić między klientami.

Konflikt mieszka w tablicy routingu

Adapter wirtualny plus trasa domyślna to sposób, w jaki pełny tunel przechwytuje ruch. Gdy drugi klient instaluje własną trasę domyślną, starszy wpis zostaje zastąpiony lub obniżony metryką, i każdy cel jedzie teraz przez nowszy tunel. Pierwszy klient pozostaje połączony i nadal pokazuje zieloną ikonę, więc interfejs działa, choć ścieżka zniknęła. Właśnie to oddzielenie stanu połączenia od stanu routingu czyni zachowanie mylącym.

Klienty są redaktorami jednej wspólnej tablicy. Wiedza, która zmiana była ostatnia, wyjaśnia niemal każdy objaw.

Przeczytaj, który tunel włada bieżącą ścieżką

Sprawdź rzeczywistą decyzję, zamiast ufać klientowi, który zgłasza połączenie. Zapytaj system, który interfejs niósłby konkretny cel.

ip route get 10.20.0.5
route print -4

Pierwsze polecenie nazywa interfejs i adres źródłowy dla jednego celu, i to jest dokładnie to pytanie, które cię interesuje. Zrzut tras pokazuje w Windows konkurujące wpisy domyślne i ich metryki, więc widzisz, który wygrywa teraz. Uruchom wyszukiwanie dla hosta w każdej sieci zdalnej, bo jeden cel może być poprawny, gdy druga sieć jest nieosiągalna. Jeśli odpowiedź wskazuje zły tunel, ponowne połączenie nie pomoże; polityka routingu musi się zmienić.

Powstrzymaj drugiego klienta przed roszczeniem sobie wszystkiego

Jeden klient powinien władać trasą domyślną, a drugi nieść tylko własne prefiksy. OpenVPN klienty mogą odrzucić to, co serwer wypycha.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ignoruje każdą wypchniętą trasę, podczas gdy pull-filter ignore "redirect-gateway" odrzuca tylko dyrektywę trasy domyślnej i zachowuje wypchnięty DNS oraz inne opcje. Wybierz między nimi według tego, ile konfiguracji serwera jeszcze chcesz, a następnie dodaj konkretne prefiksy potrzebne drugiej sieci. Pamiętaj o DNS, bo resolver wypchnięty przez tunel, który nie niesie zapytań, nic nie zwraca. Przetestuj jednego znanego hosta w każdej sieci i potwierdź adres źródłowy widziany przez stronę zdalną.

Nakładających się podsieci nie da się obejść

Gdy obie sieci publikują ten sam prefiks, jądro trzyma jeden wpis dla dwóch różnych miejsc i musi wybrać. Trasa hosta nie może wymyślić brakującego rozróżnienia, a korekta metryki też nie. Przenumeruj jedną stronę albo pozwól jej administratorowi przetłumaczyć zakres zdalny, aby prefiksy się różniły. Sprawdź prawdziwe podsieci, zanim obwinisz klienty, bo domyślny 192.168.1.0/24 routera domowego zderza się z zakresem biurowym częściej, niż ktoś się spodziewa. Zapisz oba zakresy w zgłoszeniu, aby następna zmiana nie odtworzyła nakładania.

Oddziel też dwa cele: dotarcie do obu sieci to problem routingu, a łączenie tuneli w łańcuch dla prywatności to inny projekt z dodatkowym operatorem na ścieżce. Nie używaj jednego do rozwiązania drugiego.