Co tak naprawdę blokuje OpenVPN route-nopull w wypychaniu przez serwer

Wstawiłeś route-nopull do profilu klienta, żeby tunel nie pożerał twojej trasy domyślnej, a teraz podsieć biura jest nieosiągalna, podczas gdy klient nadal twierdzi, że jest połączony. Oba spostrzeżenia są prawdziwe i nic nie zawiodło. Ta flaga każe klientowi pominąć trasy i wpisy DHCP wypychane przez serwer, co jest węższą instrukcją, niż większość ludzi się spodziewa, dodając ją. Co zostaje, to działający tunel bez zdania na temat tego, które cele mają go używać.

Ta luka to cała decyzja, o której jest ten artykuł. Albo serwer opisuje sieć, albo robi to klient, a flaga oddaje to zadanie klientowi, nie robiąc za ciebie nic z niego.

Co flaga wyłącza w chwili połączenia

Klient OpenVPN, który ciągnie, zwykle po uwierzytelnieniu odbiera od serwera pakiet: trasy, przekierowanie bramy domyślnej, serwery DNS i kilka dyrektyw strojenia. Gdy route-nopull obowiązuje, klient nadal akceptuje sesję, nadal weryfikuje certyfikaty, nadal negocjuje szyfry i keepalive, i nadal podnosi interfejs. To, co odrzuca, to zastosowanie wypychanych wierszy route i wypychanych wierszy dhcp-option, w tym DNS.

Zamieszanie bierze się ze zielonego wskaźnika obok martwej aplikacji. Tunel istnieje; mapowanie celów na ten tunel nie. Nic w panelu stanu klienta nie odróżnia „połączony i routujący” od „połączony i bezwładny”, bo z punktu widzenia tunelu oba są tym samym stanem.

Dlaczego żywy tunel nadal może nie routować niczego

Interfejs pojawia się z własnym adresem i na łączu punkt-punkt często nie ma nic konkretniejszego niż trasa do hosta w stronę partnera. Prywatna podsieć staje się osiągalna dopiero wtedy, gdy jakaś trasa ze właściwym prefiksem wskazuje na ten interfejs, a przy wyłączonym wypychaniu ta trasa nigdy nie przychodzi. Pobrany profil też zwykle nie pomoże, bo został napisany przy założeniu, że serwer dostarczy dokładnie tych informacji. Dlatego interfejs może wyglądać zdrowo, podczas gdy podsieć pozostaje ciemna.

Czytanie profilu dowodzi więc bardzo niewiele. Czytaj stan działania, na połączonej maszynie:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Adres bez trasy podsieci w drugim poleceniu jest sygnaturą tego problemu. Trzecie polecenie odpowiada wtedy na pytanie, które naprawdę interesuje użytkowników, bo podaje interfejs, który jądro wybrałoby dla konkretnego celu, a nie listę, na której użycie liczyłeś. Jeśli odpowiada przez twoje łącze fizyczne, tunelu w ogóle nie ma na ścieżce.

Rozwiązywanie nazw zawodzi z powiązanego powodu, nie z osobnego. Wypychane wpisy dhcp-option DNS są pomijane przez tę samą flagę, więc zapytania o hosty wewnętrzne idą do resolvera, którego dostarczyła sieć lokalna. Ten resolver nie ma strefy dla biura, więc zapytanie zawodzi albo zwraca odpowiedź publiczną, a awaria wygląda jak problem serwera, choć jest problemem konfiguracji klienta. Testowanie adresu przed nazwą jest tym, co rozdziela jedno i drugie.

Wybór między flagą a filtrem prefiksów

Obie opcje rozwiązują różne kształty tej samej skargi, a zły wybór tworzy stan połączony-ale-nieprzydatny. Jedna zastępuje wypychaną politykę w całości, druga redaguje ją według prefiksu. Tabela daje krótką wersję, a akapit po niej omawia część, która zaskakuje ludzi.

pull-filter to dopasowywacz prefiksów z trzema czasownikami, więc może przyjąć rodzinę wierszy, po cichu je zignorować albo całkowicie odrzucić połączenie, gdy pojawi się prefiks. Warto znać właśnie to ostatnie zachowanie: reguła odrzucenia zamienia spór o politykę w nieudany uścisk dłoni zamiast cichego pominięcia. Podręcznik OpenVPN 2.6 wymienia akceptowane prefiksy i dokładną semantykę każdego czasownika.

Częstą drogą pośrednią jest odrzucenie tylko redirect-gateway i pozwolenie, by trasy biura i DNS dotarły zgodnie z zamiarem. To utrzymuje wypychanie w działaniu dla części, które serwer rozumie lepiej niż ty, a jednocześnie zapobiega temu jednemu wierszowi, który przejąłby twoją trasę domyślną.

Dodawanie tras i resolvera ręcznie

Jeśli zachowasz flagę, profil musi powiedzieć to, co powiedziałby serwer. Dyrektywy route po stronie klienta są stosowane po nawiązaniu połączenia, więc działają obok flagi, a nie są przez nią blokowane. Umieść je w profilu, a nie w interaktywnej linii poleceń, inaczej następne ponowne połączenie nie odtworzy działającego stanu.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Wiersz DNS stoi w niezręcznym położeniu: to dyrektywa po stronie klienta, ale niektórzy klienci stosują ją tylko przez integrację DNS platformy, która może ją nadpisać, gdy zmieni się łącze. Na hoście systemd ustawienie resolvera bezpośrednio na interfejsie tunelu jest bardziej przewidywalne niż liczenie na to, że klient wygra konkurs priorytetów:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Domena routingu znaczy tyle samo co adres. Bez niej zapytania o nazwy publiczne mogą też trafiać do wewnętrznego resolvera, a każdy wewnętrzny resolver odmawiający rekurencji zepsuje przeglądanie, zostawiając działającą strefę prywatną. Z nią tylko nazwy pod tym sufiksem są kierowane do resolvera tunelu, a wszystko inne idzie łączem fizycznym.

Sprawdzanie wyniku: adres, nazwa i droga zewnętrzna

Trzy testy rozdzielają możliwe awarie. Pobierz prywatny adres po IP, potem ten sam host po nazwie, potem zwykłą stronę publiczną. Działający IP z zawodzącą nazwą wskazuje resolver; zawodzący IP z działającą nazwą wskazuje routing; gdy zawiodą oba, zwykle tunelu nie ma na ścieżce.

Potem patrz na zewnątrz, a nie do środka. Własna trasa punktu końcowego tunelu musi przetrwać zmianę, a każde blokujące niepowodzenie musi być ograniczone do tunelu bez przechwytywania punktu końcowego. Klient, który nadal przegląda po upadku tunelu, to problem polityki, nie routingu, i nie pojawi się w żadnym z trzech testów powyżej.

Zapisz ostateczną listę w dokumentacji profilu: trasy, resolver, domeny i powód istnienia każdego z nich. Ponowne połączenie, które odtwarza tę samą tabelę, jest jedynym dowodem, że lokalna polityka jest kompletna. Jeśli aplikacje nadal zawodzą przy podniesionym tunelu i wszystkich trzech testach zaliczonych, następnym miejscem do zajrzenia jest klasa problemów połączony-ale-offline, a nie certyfikaty, które już zweryfikowano.