OpenVPN: local a adres tunelu, dwa różne gniazda

Klient odmawia startu i skarży się, że nie może powiązać adresu lokalnego, a oczywista poprawka wygląda na wskazanie go na adres tunelu, który spodziewa się otrzymać. To nie może działać, a powód warto zrozumieć: zanim tunel istnieje, nie ma adresu wewnętrznego, a gniazdo kontaktujące się z serwerem musi powstać najpierw. W grę wchodzą dwa różne adresy i tylko jeden z nich można wybrać lokalnie.

Błąd wiązania wskazuje adres lokalny

Gdy OpenVPN zgłasza, że nie może powiązać adresu lokalnego, mówi o gnieździe transportowym: punkcie końcowym UDP lub TCP, który przenosi zaszyfrowane połączenie do peera.

Jawna dyrektywa local prosi demona o powiązanie tego gniazda z konkretnym adresem lokalnym. Adres musi istnieć w przestrzeni nazw sieci, w której działa proces, i musi być przypisywalny w chwili startu klienta.

Publiczny adres tłumaczony na routerze lub na brzegu chmury nie jest adresem lokalnym, który demon może powiązać, nawet jeśli to on jest adresem widzianym przez serwer. Ta różnica wyjaśnia, dlaczego jeden profil działa w domu, a zawodzi na instancji w chmurze. Wyjaśnia też, dlaczego dodanie publicznego adresu do interfejsu loopback nie pomaga, bo transport brałby wtedy źródło z adresu, do którego sieć nie potrafi routować z powrotem. Przeczytaj listę interfejsów, zanim zmienisz profil.

Co tak naprawdę wybierają local i remote

remote nazywa peera, z którym należy się połączyć. local wiąże bliższy koniec tego samego gniazda. nobind pozwala systemowi operacyjnemu wybrać zarówno adres lokalny, jak i port, dlatego klienci za domowymi routerami zwykle działają bez żadnej z tych dyrektyw.

Żadna z tych dyrektyw nie ma nic wspólnego z adresem wewnątrz tunelu.

W kontenerze lub przestrzeni nazw sieci obowiązuje ta sama zasada, tylko z węższymi granicami: adresów hosta nie ma w środku, więc linia local skopiowana z konfiguracji hosta zawodzi z zupełnie innego powodu niż błędny adres.

ip -brief address show
ip route get 203.0.113.10

Adres wewnętrzny pochodzi z serwera

Adres wewnątrz tunelu jest negocjowany lub przydzielany po ustanowieniu kanału sterującego. W dynamicznej puli serwer decyduje o nim w chwili połączenia, a przy konfiguracji przypisanej do klienta może być stały dla danej tożsamości.

Zapisanie local z adresem wewnętrznym nie prosi serwera o przydzielenie tego adresu. W najlepszym razie wiązanie się nie uda; w najgorszym klient znajdzie niepowiązany adres hosta o tej samej wartości i zacznie używać go do transportu.

Interfejsy do czytania też są inne. Parametry ifconfig i konfiguracja puli opisują wnętrze, natomiast remote, local, proto i nobind opisują zewnętrze. Rozdzielenie tych dwóch list wyjaśnia niemal każdy mylący przykład znajdowany na forum. Właśnie dlatego podręcznik OpenVPN 2.6 dokumentuje je w osobnych sekcjach.

Pułapka: pełny tunel, który przechwytuje własny transport

Gdy tunel działa i przenosi trasę domyślną, pakiety, które go utrzymują, nie mogą być do niego routowane. To problem routingu, a nie adresowania, i demon radzi sobie z nim, instalując bardziej szczegółową trasę do adresu samego serwera przez pierwotną bramę.

Jeśli przypniesz transport do konkretnego adresu lokalnego, a później zmienisz ścieżkę, której ten adres używa, zewnętrzne połączenie może zgubić drogę, podczas gdy wnętrze pozostanie skonfigurowane. Tunel nadal zgłasza połączenie, bo wnętrze jest w porządku. Zepsuty jest tylko transport, dlatego logi czyta się jak sprzeczności.

Objawy wyglądają wtedy jak tunel, który się łączy i zastyga, albo taki, który łączy się ponownie w pętli bez użytecznego błędu. Sprawdź trasę do adresu peera, zanim sprawdzisz cokolwiek wewnątrz tunelu, i potwierdź, że powiązany adres lokalny nadal należy do interfejsu, którego oczekiwałeś.

Nawyk, który zapobiega zamieszaniu

Przeczytaj każdy adres w profilu i zdecyduj, do której warstwy należy, zanim go zmienisz.

Jeśli nazywa dalszy koniec transportu albo wiąże jego bliższy koniec, jest adresem zewnętrznym i musi istnieć przed startem. Jeśli opisuje to, co dzieje się wewnątrz tunelu, pochodzi z serwera lub z topologii i żadna lokalna dyrektywa nie może go zastąpić.

Zapisz obie listy w notatkach wdrożeniowych obok profilu. Następna sesja rozwiązywania problemów zaczyna się wtedy od warstwy, a nie od domysłu.