Wyjście IPv6 umiera po restarcie OpenVPN: sprawdź własność prefiksu

IPv6 przestaje przepuszczać ruch w chwili, gdy OpenVPN restartuje, a IPv4 nadal działa. Interfejs tunelu został odtworzony, a coś innego, co zarządzało jego stanem IPv6, straciło albo adres, albo trasę, która czyni prefiks osiągalnym. Zaangażowane są trzy odrębne części stanu i każda ma innego właściciela: delegowany prefiks dostawcy i jego czas życia, adresy przydzielane klientom VPN oraz trasa w górę, która odsyła ten prefiks klienta do serwera. Zidentyfikuj właściciela każdej części, zanim dotkniesz jakiegokolwiek demona, bo restart niewłaściwego ukrywa problem na dzień i przywraca go przy następnym połączeniu.

Trzy części stanu IPv6, trzech właścicieli

Adres o zasięgu globalnym wewnątrz tunelu sam w sobie nie wystarcza. Routery wyżej muszą nadal odsyłać ten prefiks do serwera VPN i nie zrobią tego tylko dlatego, że serwer przypadkiem ma adres z niego.

Dlatego kopiowanie publicznego /64 do puli tunelu jest ryzykowne. Prefiks trasowany do serwera to nie to samo co prefiks, który strona wyżej traktuje jako on-link, a wykrywanie sąsiadów nie wypełni tej luki.

Przeczytaj stan serwera, zanim cokolwiek zmienisz

Przechwyć stan dwa razy, raz gdy IPv6 działa i raz po restarcie, a potem porównaj. Widoki tylko do odczytu wystarczą i nic nie kosztują w oknie serwisowym:

ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwarding

Szukaj trzech konkretnych różnic: trasy, która zniknęła, adresu, który przeszedł na przestarzały lub nieprawidłowy czas życia, oraz prefiksu, który zmienił się po ponownym delegowaniu, podczas gdy konfiguracja VPN nadal ogłasza stary.

Jeśli adres zniknął, ale prefiks się nie zmienił, demon, który go przydziela, przestał zarządzać interfejsem. Jeśli prefiks się zmienił, ale adresy nie, konfiguracja klienta jest przestarzała. Obie awarie wyglądają z przeglądarki identycznie i nie mają nic wspólnego.

Zdecyduj, czy dhcpcd ma zarządzać tunelem

dhcpcd potrafi wykrywać interfejsy i delegować części prefiksu DHCPv6 do interfejsów poniżej, a jego konfiguracja może wprost nazwać cele delegowania. Bez wyraźnego celu jego udokumentowane zachowanie może obejmować inne interfejsy i tak tunel dostaje adres, którego nikt nie zaplanował.

Dwa warunki powinny skłonić cię do oddania statycznego adresowania tunelu OpenVPN: serwer wypycha stałe adresy w swojej konfiguracji, a nazwa tunelu zmienia się przy ponownym połączeniu. Jeśli oba zachodzą, świadomie wyklucz tunel z demona delegowania, z komentarzem, który mówi dlaczego.

Jeśli zamiast tego delegowanie do tunelu jest zamierzone, wdroż obsługę zmiany prefiksu. To znaczy reagować, gdy delegowany prefiks lub jego czas życia się zmienia, aktualizować ogłaszany przez serwer prefiks klienta i ponownie dodawać trasę. Wykluczenie interfejsu w takim projekcie usuwa jedyny komponent, który zna nowy prefiks.

Restart dhcpcd może wyglądać na naprawę, bo odtwarza stan, ale odnawia też lub wycofuje konfigurację interfejsów, o których nie myślałeś. Takie odzyskanie nie czyni go obowiązkowym po każdym restarcie VPN. Zeruje też liczniki, których używałeś jako dowodu. Preferuj ukierunkowane przeładowanie tego interfejsu, który naprawdę zmieniłeś.

Weryfikuj IPv6 oddzielnie od NAT IPv4

Potwierdź, że przekazywanie jest włączone i że trasa w górę wskazuje rzeczywisty prefiks klienta, a następnie nawiąż nowe dozwolone połączenie IPv6. Sprawdź też własną tablicę tras IPv6 klienta, bo klient pokazujący publiczny adres nie dowodzi, że jego żądanie szło tunelem.

Maskowanie IPv4 rozwiązuje inny problem: drogę powrotną dla prywatnych źródeł. Nic nie robi dla wycofanego prefiksu IPv6, a dodanie go nie przywróci IPv6.

Zakończ rejestrem własności: który komponent deleguje prefiks, który przydziela adresy klientów, który trzyma trasę powrotną i co dzieje się z każdym przy ponownym połączeniu. Cztery linijki w runbooku oszczędzają następnej osobie restartu trzech demonów, żeby znaleźć ten, który miał znaczenie.