Adres IP WAN się zmienił, a tunel padł: kontrole po kolei

Tunel pada, router zapisuje ponowne połączenie, a w sieci LAN nic się nie przesunęło. Nowy adres WAN unieważnia połączenie zewnętrzne, nie zmieniając niczego wewnątrz: adres źródłowy klienta się zmienił, stary stan NAT wskazuje źródło, które już nie istnieje, a zdalny peer może nadal wysyłać na poprzedni adres. Odzyskiwanie to normalne zachowanie, a użyteczne pytanie brzmi, który stan nie został zaktualizowany.

Nazwij zdarzenie, zanim przeczytasz log

Sprawdź, co rzeczywiście stało się w warstwie dostępu. Odnowienie dzierżawy od dostawcy to jedno zdarzenie. Sesja PPPoE, która połączyła się ponownie, to inne. Zrestartowany modem światłowodowy albo przełączenie WAN z jednego łącza na drugie zmienia adres zewnętrzny lub jego ścieżkę w trzeci sposób. To nie są te same zdarzenia i nie zostawiają tego samego osadu.

Wiersz ponownego połączenia w logu VPN też nie jest dowodem zmiany WAN. Limit bezczynności, interwał ponownego uwierzytelnienia i wykrywanie martwego peera dają ponowne połączenia bez żadnej zmiany adresu. Przed wyciągnięciem wniosków porównaj znaczniki czasu z logu dostępu z logiem VPN i utrzymuj okno porównania wystarczająco szerokie, aby wychwycić zmianę, która nastąpiła w nocy.

Roaming i ponowne łączenie to różne protokoły

WireGuard ma uwierzytelniony roaming wbudowany w protokół: gdy peer otrzyma poprawnie uwierzytelniony pakiet z nowego adresu źródłowego, aktualizuje punkt końcowy tego peera. Szybki start WireGuard opisuje konfigurację peera, która to umożliwia, dlatego klient na zmieniającym się adresie często wraca bez widocznego restartu.

OpenVPN domyślnie zachowuje się inaczej. Sesja UDP może się zakończyć i połączyć ponownie, a opcjonalne zachowanie float pozwala uwierzytelnionemu peerowi kontynuować z nowego adresu tam, gdzie konfiguracja na to pozwala. Tunele oparte na TCP są surowsze, ponieważ samo połączenie jest związane z parą adresów. Ta różnica decyduje o tym, czy odzyskiwanie wygląda na niewidoczne, czy za każdym razem zgłasza się w logu.

Żadne z tych zachowań nie mówi nic o aplikacjach wewnątrz. Odzyskany tunel nie przywraca sesji TCP, którą peer już uznał za martwą.

Stan, którego tunel nie posiada

Stan tłumaczenia i routingu przeżywa ponowne połączenie w sposób, który zaskakuje ludzi. Wpis conntrack utworzony dla starego źródła trzyma ścieżkę odpowiedzi zakotwiczoną pod adresem, który już nie istnieje, i wygasa według własnego harmonogramu, a nie wtedy, gdy tunel wrócił. Restart usługi tunelu nie skraca tego oczekiwania, więc naprawione łącze może jeszcze przez jakiś czas wyglądać na zepsute.

Trasy i reguły polityki mogą odwoływać się do starej bramy lub interfejsu. Zestaw reguł, który był poprawny przed przełączeniem WAN, może wskazywać urządzenie, które teraz nie działa, co daje tunel zgłaszający połączenie i ruch, który nigdzie nie dociera. Dynamiczny DNS dla serwera, który hostujesz, to osobny problem od klienta uzyskującego nowe źródło. Wpis trzeba zaktualizować, aby klienci zdalni mogli cię znaleźć, i żadna konfiguracja po stronie klienta nie zrekompensuje adresu, którego tłumaczenie wyżej w sieci nie przekazuje.

Uporządkuj kontrole od zewnątrz do wewnątrz

Poniższa kolejność biegnie od połączenia zewnętrznego do środka, a zatrzymanie się na pierwszym nieudanym kroku czyni ją użyteczną: każda kontrola wyklucza warstwę nad sobą. Zachowaj tę kolejność nawet wtedy, gdy usterka wygląda oczywiście.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Pierwsze polecenie pokazuje bieżący punkt końcowy i wiek uścisku dłoni dla każdego peera. Drugie i trzecie pokazują, czy interfejs zewnętrzny i trasa do punktu końcowego wciąż mają sens. Liczba conntrack to zgrubna kontrola stanu pozostałego po poprzednim adresie, a dziennik jest miejscem, w którym zapisuje się powód ponownego połączenia.

Potem testuj z klienta LAN, a nie z routera. Ping wysłany przez sam router używa innej ścieżki niż ruch przekazywany, więc udany ping z routera dowodzi istnienia tunelu i niczego nie mówi o osiągalności klienta.

Ustal oczekiwane zachowanie i zapisz je

Ponowne łączenie to prawidłowe zachowanie w większości wdrożeń, więc celem nie jest mu zapobiegać. Ustal zamiast tego, co ma się dziać z ruchem podczas przerwy: zatrzymać go, przytrzymać czy przełączyć na inną ścieżkę. Ta decyzja należy do firewalla i polityki routingu, a nie do profilu VPN.

Zapisuj zdarzenia dostępu i czasy ponownego połączenia razem przez tydzień. Powtarzające się zmiany bez pasującego zdarzenia dostępu wskazują na usługę dostępu, a wymiana profilu VPN nie naprawi łącza, które stale negocjuje od nowa. Jedna para wpisów w tej samej minucie rozstrzyga sprawę dla tego zdarzenia i daje następnemu linię bazową.