IPv6 výstup selhává po restartu OpenVPN: zkontrolujte vlastnictví prefixu

IPv6 přestane předávat provoz ve chvíli, kdy se OpenVPN restartuje, a IPv4 dál funguje. Rozhraní tunelu bylo znovu vytvořeno a něco jiného, co spravovalo jeho stav IPv6, buď ztratilo adresu, nebo ztratilo trasu, která činí prefix dostupným. Jsou zapojeny tři oddělené kusy stavu a každý má jiného vlastníka: delegovaný prefix poskytovatele a jeho životnost, adresy předané klientům VPN a trasa směrem nahoru, která ten klientský prefix posílá zpět na server. Určete vlastníka každého z nich, než se dotknete jakéhokoli démona, protože restart nesprávného skryje problém na den a vrátí ho při dalším připojení.

Tři kusy stavu IPv6, tři vlastníci

Adresa s globálním rozsahem uvnitř tunelu sama o sobě nestačí. Směrovače výš stále musí posílat ten prefix zpět k serveru VPN, a neudělají to jen proto, že server má náhodou adresu z něj.

Proto je také riskantní kopírovat veřejný /64 do fondu tunelu. Prefix směrovaný na server není totéž co prefix, který výš považuje za on-link, a objevování sousedů tuto mezeru nevyplní.

Přečtěte stav serveru, než cokoli změníte

Zachyťte stav dvakrát, jednou když IPv6 funguje a jednou po restartu, a pak je porovnejte. Zobrazení pouze pro čtení stačí a během okna údržby nic nestojí:

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

Hledejte tři konkrétní rozdíly: trasu, která zmizela, adresu, která přešla na zastaralou nebo neplatnou životnost, a prefix, který se po opětovné delegaci změnil, zatímco konfigurace VPN stále inzeruje ten starý.

Pokud adresa zmizela, ale prefix se nezměnil, démon, který ji přiděluje, přestal spravovat rozhraní. Pokud se prefix změnil, ale adresy ne, konfigurace klienta je zastaralá. Obě selhání vypadají z prohlížeče stejně a nemají nic společného.

Rozhodněte, zda má dhcpcd spravovat tunel

dhcpcd umí objevovat rozhraní a delegovat části prefixu DHCPv6 na navazující rozhraní a jeho konfigurace umí výslovně pojmenovat cíle delegace. Bez výslovného cíle může jeho dokumentované chování zahrnout jiná rozhraní, a tak se tunel ocitne s adresou, kterou nikdo neplánoval.

K tomu, abyste nechali OpenVPN vlastnit statické adresování tunelu, by vás měly vést dvě podmínky: server vnucuje pevné adresy ve své konfiguraci a název tunelu se při opětovném připojení mění. Pokud platí obě, vylučte tunel z démona delegace záměrně, s komentářem, který říká proč.

Pokud je delegace do tunelu naopak záměrná, nasaďte ošetření změny prefixu. To znamená reagovat, když se delegovaný prefix nebo jeho životnost změní, aktualizovat klientům inzerovaný prefix serveru a znovu přidat trasu. Vyloučení rozhraní v takovém návrhu odstraní jedinou komponentu, která o novém prefixu ví.

Restart dhcpcd může vypadat, že věci opraví, protože znovu vytvoří stav, ale také obnoví nebo odebere konfiguraci rozhraním, na která jste nemysleli. Takové zotavení z něj nedělá povinnost po každém restartu VPN. Také vynuluje čítače, které jste používali jako důkaz. Dejte přednost cílenému znovunačtení rozhraní, které jste skutečně změnili.

Ověřujte IPv6 odděleně od IPv4 NAT

Potvrďte, že je zapnuté předávání a že trasa výš míří na skutečný klientský prefix, a pak navazte nové povolené připojení IPv6. Zkontrolujte i vlastní směrovací tabulku IPv6 klienta, protože klient zobrazující veřejnou adresu nedokazuje, že jeho požadavek šel tunelem.

Maskování IPv4 řeší jiný problém: zpětnou cestu pro soukromé zdroje. Pro odejmutý prefix IPv6 nedělá nic a jeho přidání IPv6 nevrátí.

Uzavřete záznamem o vlastnictví: která komponenta prefix deleguje, která přiděluje adresy klientů, která drží zpětnou trasu a co se s každou stane při opětovném připojení. Čtyři řádky v runbooku ušetří dalšímu člověku restart tří démonů, aby našel ten, na kterém záleželo.