Dwie bramy, jedna VPN: dlaczego OpenVPN wybiera złe łącze wyjściowe

Dwa łącza wyjściowe, jeden tunel, a ruch wychodzi przez to, którego nie wybrałeś. Prywatne podsieci są osiągalne, dziennik zgłasza udane połączenie, i to właśnie mierzone łącze je niesie. Nic w wyjściu OpenVPN nie wspomina bramy, bo klient nigdy żadnej nie wybrał. Otworzył gniazdo do zdalnego adresu i pozwolił jądru zdecydować, jak dotrzeć do tego adresu.

Adres tunelu nie jest punktem końcowym

W każdej sesji istnieją dwie różne ścieżki. Ścieżka zewnętrzna niesie szyfrowany transport do publicznego adresu serwera. Ścieżka wewnętrzna niesie wszystko, co serwer wpycha do tunelu, a reguły routingu jednej nie wpływają na drugą.

Wpis remote w profilu nazywa cel zewnętrzny, więc to ten adres trzeba przypiąć. To także wartość, która się zmienia, gdy nazwa hosta rozwiązuje się inaczej albo profil wymienia kilka wpisów remote.

Znajdź adres, na który klient faktycznie zadzwonił

Czytaj żywe gniazdo, a nie plik konfiguracji. Tabela gniazd pokazuje peera, z którym proces faktycznie się połączył, i to jest wartość, z którą wyjątek musi się zgadzać. Profil można edytować po rozpoczęciu sesji, a gniazdo jest jedynym dowodem na to, na co zadzwoniono:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Linia dziennika podaje adres i port peera w chwili połączenia. Jeśli nie zgadza się z profilem, coś przed klientem przepisuje cel, zanim połączenie się zacznie.

Sprawdź także rodzinę adresów. Profil z dwoma stosami może łączyć się przez IPv6, podczas gdy wyjątek obejmuje tylko IPv4, i wtedy ruch podlega innej regule niż ta, którą napisałeś. To samo dotyczy proxy, które odpowiada w imieniu punktu końcowego. Oba przypadki dają tunel, który działa, podczas gdy twoja trasa nic nie robi.

Przypnij punkt końcowy i przeczytaj kolejność polityki

Trasa do hosta jest bardziej szczegółowa niż jakakolwiek trasa domyślna. Dlatego /32 dla adresu peera wygrywa w tabeli, która go zawiera. Zwykła forma wymienia bramę i urządzenie wprost:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Ta trasa pomaga tylko wtedy, gdy wyszukiwanie dotrze do tej tabeli. Reguły polityki są oceniane po kolei i pierwsze dopasowanie decyduje, więc reguła, która wysyła wszystko do drugiej tabeli, omija twoją trasę do hosta w main. Przeczytaj reguły, zanim uznasz trasę za miarodajną:

ip rule show
ip route get 203.0.113.40

Zapytaj drugie polecenie z tym samym adresem źródłowym lub znacznikiem, którego używa klient, gdy polityka od nich zależy. Podaje trasę, którą wybrałoby jądro, co jest dowodem dotyczącym wyszukiwania, a nie dowodem, że żywe gniazdo korzysta z tej ścieżki.

Gdy punkt końcowy się przesuwa

Nazwa hosta rozwiązująca się na kilka adresów unieważnia stałą /32, gdy tylko odpowiedź się zmieni. Profil z wieloma liniami remote ma ten sam problem, bo klient może wylądować na dowolnym z nich. Odświeżaj trasę z własnych hooków cyklu życia klienta, zamiast dodawać ją ręcznie. Skrypt up, który czyta wynegocjowanego peera i instaluje trasę do hosta, utrzymuje wyjątek zgodny z rzeczywistością, a pasujący skrypt down usuwa go.

Zapisuj odświeżanie w tym samym miejscu co resztę konfiguracji routingu hosta. Trasa, która istnieje tylko do następnego restartu, jest testem, nie poprawką.

Trzymaj politykę wewnętrzną osobno

Przesunięcie ścieżki zewnętrznej nie daje dostępu do nowej podsieci prywatnej i nie zmienia, jakie cele serwer wpycha do tunelu. Trasa dolnej warstwy wybiera kabel; wpchnięte trasy wybierają, co wchodzi do tunelu. Rozdzielenie tych dwóch decyzji czyni podział przewidywalnym.

Jeśli celem jest tylko trzymanie szyfrowanego transportu z dala od mierzonego łącza, zostaw trasę domyślną w spokoju i dodaj jedyny wyjątek dla hosta. Zastąpienie maszynowej trasy domyślnej, by przenieść jedno połączenie VPN, psuje każdą inną aplikację na hoście.

Potwierdź wynik dwoma niezależnymi obserwacjami: lokalnym adresem i urządzeniem gniazda oraz trasą, na którą rozwiązuje się prywatny cel. Gdy oba odpowiadają twojemu zamiarowi, podział jest prawdziwy. Podręcznik OpenVPN 2.6 omawia opcje remote i lokalnego wiązania, które decydują, na jaki adres klient dzwoni.