OpenVPN rozłącza się po odnowieniu DHCP: zachowaj trasę punktu końcowego

Tunel się łączy, potem odnowienie dzierżawy na łączu dostępowym go zabija, a dziennik obwinia limit czasu, a nie trasę. W konfiguracji VPN nic się nie zmieniło i to jest wskazówka: zmieniło się coś poza nią. Zdarzenie DHCP przepisało adres lub bramę, a trasa do hosta, która utrzymywała punkt końcowy tunelu osiągalnym, teraz wskazuje następny skok, którego już nie ma. To problem własności, zanim staje się problemem routingu.

Porównaj objaw z trasami półdomyślnymi

Z redirect-gateway def1 OpenVPN instaluje 0.0.0.0/1 i 128.0.0.0/1, zamiast zastępować trasę domyślną. Razem te dwie pokrywają całą przestrzeń adresową i biją 0.0.0.0/0 samą długością prefiksu. Dlatego każde miejsce docelowe bez bardziej szczegółowego dopasowania wchodzi do tunelu.

Punkt końcowy potrzebuje wyjątku. OpenVPN dodaje trasę do hosta na adres serwera przez pierwotną bramę dostępową, zanim wejdą trasy półdomyślne, aby pakiety enkapsulowane mogły wychodzić. Gdy ten wyjątek znika albo zachowuje następny skok, którego już nie ma, własne zewnętrzne pakiety tunelu pasują do trasy półdomyślnej i są odsyłane z powrotem do tunelu. Wynikiem jest połączenie, które umiera przy następnym keepalive lub uścisku dłoni, bez niczego w dzienniku, co wyglądałoby na błąd routingu.

Potwierdź kształt tabeli, zanim cokolwiek innego dotkniesz. ip route show powinien wymienić obie połowy plus trasę do hosta dla adresu serwera; gdy brakuje trasy do hosta, reszta dochodzenia ma oczywisty punkt startowy.

Dlaczego trasy półdomyślne wygrywają bez zmiany metryki

Niższa metryka nie bije dłuższego prefiksu. Trasy /1 wygrywają, bo jądro najpierw dopasowuje najbardziej szczegółową trasę, więc podniesienie metryki na trasie domyślnej niczego nie zmienia w tym, dokąd trafia ruch kierowany do tunelu. Ściganie metryk to najczęstszy zły zakręt w tej diagnostyce.

Sprawdź wybór za pomocą ip route get 203.0.113.10, podstawiając rzeczywisty adres serwera. Odpowiedź nazywa interfejs i następny skok, których jądro naprawdę by użyło, co jest bardziej pouczające niż czytanie tabeli i rozmyślanie nad nią.

Uruchom to polecenie przed startem tunelu, gdy działa, oraz po zdarzeniu dzierżawy. Trzy odpowiedzi z jednego polecenia, a punkt rozbieżności staje się widoczny.

Zrób trzy migawki, a nie jedną

Zbierz adres dostępowy, bramę dostępową, cel punktu końcowego, wybraną trasę i wszelkie reguły polityki w trzech momentach: po skonfigurowaniu łącza dostępowego, po połączeniu VPN i po zdarzeniu dzierżawy lub operatora. Każda migawka to garść poleceń i mają sens tylko razem. Pojedyncza migawka po awarii zapisuje stan, a nie przejście. Zapisz polecenia w małym skrypcie, aby każda migawka była robiona w ten sam sposób.

Trzymaj migawki w jednym pliku ze znacznikami czasu, bo ciekawym pytaniem później jest kolejność. Czy zdarzenie DHCP przyszło przed, czy po tym, jak OpenVPN odświeżył swoją trasę? Odpowiedź decyduje, kto musi to naprawić. Znacznik czasu z niewłaściwego zegara jest gorszy niż jego brak, więc weź go z hosta, który posiada tablicę routingu.

Gdy punkt końcowy jest skonfigurowany jako nazwa, a nie adres, rozwiąż go również w każdej migawce. Zmiana DNS na łączu dostępowym może przesunąć punkt końcowy bez dotykania jakiejkolwiek trasy.

Zdecyduj, który komponent odświeża wyjątek

W systemie dhcpcd haki uruchamiają się z katalogu haków i z haka wyjścia, a tryb menedżera różni się zakresem od trybu na interfejs. Cokolwiek robi hak, musi być idempotentne, bo odnowienia mogą przychodzić seriami.

Niezawodnym właścicielem jest integracja, która zna już obie strony: menedżer sieci zarządzający połączeniem VPN albo jednostka uporządkowana po podniesieniu łącza dostępowego. Trasa statyczna dodana przez hak działa do następnej zmiany bramy, a potem zawodzi dokładnie w ten sam sposób. Jeśli jednak używasz haka, pozwól mu czytać bieżącą bramę w czasie działania, zamiast zakodować na stałe tę, którą widziałeś dzisiaj.

Zapisz właściciela w konfiguracji. Następna osoba debugująca ponowne połączenie musi wiedzieć, że za trasę wyjątku odpowiada hak, a nie VPN.

Testuj cykl życia, nie tylko ponowne połączenie

Wymuś odnowienie za pomocą dhcpcd -n eth0 albo zwalniając i ponownie biorąc dzierżawę, a potem ponownie sprawdź ip route get dla punktu końcowego. Zrób to dwa razy, bo drugi przebieg łapie haki dodające zduplikowane trasy. Potem uruchom ponownie, bo trwałość to inna właściwość niż poprawność.

Tunel, który przetrwa odnowienie i restart, ma właściciela i działający wyjątek. Ten, który przetrwa tylko ręczny restart, nie ma ani jednego, ani drugiego, i zawiedzie przy następnym zdarzeniu, którego nie możesz zaplanować.