Dwa adresy usługi na jednym kliencie OpenVPN: iroute i lo

Aplikacja odpowiada na swoim adresie tunelu, a adres, który dla niej udokumentowano, donikąd nie prowadzi. Nic w dzienniku OpenVPN się nie skarży, peer wygląda na połączony, a koncentrator wymienia dokładnie jednego klienta. Luka polega na tym, że drugi adres na kliencie to dwa odrębne fakty: host musi go posiadać, a koncentrator musi wiedzieć, który peer go posiada. Zajmij się jednym bez drugiego, a ruch albo ginie na koncentratorze, albo przychodzi bez trasy do domu.

Alias jest lokalny, własność jest zdalna

Adres tunelu jest negocjowany, więc obie strony poznają go podczas uścisku dłoni. Dodatkowy adres usługi nie jest negocjowany wcale, dlatego dodanie go samo w sobie niczego nie zmienia na koncentratorze. Klient może od razu posiadać adres, a serwer nadal będzie wysyłał ten ruch swoją domyślną trasą albo go odrzuci. Trzeba utworzyć dwa rekordy, w dwóch różnych miejscach.

Na kliencie adres należy do hosta, a loopback jest naturalnym domem tożsamości usługi, która nigdy nie powinna pojawić się na łączu fizycznym. Na koncentratorze mapowanie peera na prefiks jest osobną deklaracją, którą czyta tylko serwer. Żaden z rekordów nie implikuje drugiego.

Trzymaj oba zakresy osobno także w swoich notatkach. Adresy w przykładzie są wartościami dokumentacyjnymi, a nakładanie ich na prawdziwą sieć LAN to najszybszy sposób, by działająca konfiguracja wyglądała na zepsutą.

Dodaj adres na kliencie trwale

Umieść adres usługi na loopbacku z prefiksem hosta, aby host traktował go jako lokalne wejście, a nie jako podsieć, do której trzeba dotrzeć. ip address add 10.66.0.10/32 dev lo robi to dla jednego adresu, a powtórzenie polecenia dla drugiego adresu modeluje dwie usługi.

Uruchom to jako jednorazowy test, a następnie przenieś do tego, co zarządza konfiguracją sieci hosta, ponieważ dodatek w czasie działania znika po restarcie, a duplikaty gromadzą się między ponownymi połączeniami. Jednostka systemd uporządkowana po sieci to jedna opcja, a menedżer sieci dystrybucji to druga. Cokolwiek wybierzesz, adres musi istnieć, zanim aplikacja się zwiąże, inaczej usługa wstaje na złym gnieździe. Sprawdź za pomocą ip address show dev lo po restarcie, a nie po ręcznym poleceniu.

Wiazanie to decyzja odrębna od adresowania. Aplikacja nasłuchująca na każdym adresie przyjmuje ruch na interfejsach, których nigdy nie zamierzano, więc skieruj ją na konkretny adres usługi. Wtedy lokalna polityka wejścia ma co dokładnie dopasować.

Zażądaj go w pliku CCD, który koncentrator naprawdę czyta

Na serwerze deklaracja własności trafia do pliku dla danego klienta wybieranego przez uwierzytelnioną nazwę wspólną, w katalogu wskazanym przez client-config-dir. Linia to iroute 10.66.0.10 255.255.255.255, po jednej na adres, i mówi serwerowi, który peer ma odbierać ruch do tego celu.

Dwa szczegóły psują to po cichu. Nazwa pliku musi odpowiadać nazwie, której serwer naprawdę używa, a ta się różni, gdy w grze jest username-as-common-name. I iroute działa tylko w trybie TUN ze skonfigurowanym katalogiem konfiguracji klienta, więc ta sama linia nic nie robi we wdrożeniu mostkowym. Dodawaj linie do istniejącego pliku, zamiast go zastępować, bo może już zawierać stały adres lub opcje push. Dokumentacja OpenVPN 2.6 opisuje zarówno katalog, jak i dyrektywę własności.

Własne jądro koncentratora też potrzebuje ścieżki do tych celów, aby ruch generowany lokalnie wchodził do procesu tunelu. route 10.66.0.10 255.255.255.255 w konfiguracji serwera obejmuje ruch, który serwer sam tworzy, a inni klienci potrzebują push "route 10.66.0.10 255.255.255.255", aby sami poznali cel.

Routing i autoryzacja pozostają rozdzielone. Wypchnięta trasa mówi klientowi, gdzie wysyłać pakiety, i niczego nie przyznaje; usługa nadal musi zaakceptować wywołującego na własnych warunkach.

Sprawdź politykę wejścia i trasę odpowiedzi

Pakiet zaadresowany do aliasu dociera do właściciela hosta jako lokalne wejście, więc pytanie brzmi, czy lokalna zapora dopuszcza to źródło i port. Zezwól na konkretny port usługi z zakresu źródeł VPN, zamiast otwierać cały adres.

Odpowiedzi potrzebują trasy powrotnej do wywołującego. Dla wywołującego w normalnej puli tunelu ta ścieżka już istnieje, bo niesie ją urządzenie tunelu. Wywołujący za inną trasowaną siecią potrzebuje także trasy powrotnej tej sieci, i tutaj konfiguracje asymetryczne gubią pakiety.

Uważaj na drugiego słuchacza na tym samym porcie związanego z innym adresem, bo jądro dostarcza do tego gniazda, które pasuje, a wyniki wyglądają losowo. Sprawdź za pomocą ss -lntp i potwierdź, że związany adres to alias usługi. NAT źródłowy nie jest tu potrzebny, a dodanie go ukrywa tożsamość wywołującego, od której zależą twoje dzienniki.

Testuj adresy i własność osobno

Testuj w dwóch krokach. Najpierw potwierdź, że host będący właścicielem dociera do usługi na swoim aliasie sam z siebie, co oddziela problemy wiązania i zapory od routingu. Następnie testuj z prawdziwego wywołującego VPN, używając uwierzytelniania samej aplikacji. Gdy pierwsze przechodzi, a drugie zawodzi, brakujący element jest po stronie koncentratora.

Sprawdź też tryby awarii, które przeżywają połączenie: alias pozostaje przypisany, gdy tunel jest wyłączony, a koncentrator zachowuje swoją trasę, gdy peera nie ma. Żaden obiekt sam nie dowodzi, że usługa jest osiągalna, dlatego test dwuetapowy bije jeden ping z laptopa.