IPv6 hält op, Verkéier duerchzeloossen, an deem Moment, wou OpenVPN nei start, an IPv4 funktionéiert weider. Den Tunnel-Interface gouf nei ugeluecht, an eppes Aneres, wat säin IPv6-Zoustand geréiert huet, huet entweder d’Adress oder de Wee verluer, deen de Prefix erreechbar mécht. Et sinn dräi getrennte Stécker Zoustand am Spill, an all huet en aneren Eegentümer: de delegéierte Prefix vum Provider a seng Liewensdauer, d’Adressen, déi un VPN-Clientë verginn ginn, an de Wee no uewen, deen dee Clientprefix zréck op de Server schéckt. Identifizéiert den Eegentümer vun all Stéck, ier Dir en Dämon beréiert, well de falschen nei starten de Problem fir een Dag verstoppt an et beim nächsten Uschloss zréckbréngt.

Dräi Stécker IPv6-Zoustand, dräi Eegentümer

StateTypical ownerWhat breaks when it is wrong
Delegated prefix and lifetimeUpstream router or provider via DHCPv6-PDClients keep addresses that the upstream no longer routes
Client addresses inside the tunnelOpenVPN server config or a delegation daemonNo global address, or an address outside the routed prefix
Return route for the client prefixUpstream router, or the server's own routing tableOutbound works, replies never arrive

Eng Adress mat globalem Ëmfang am Tunnel ass eleng net genuch. D’Routere méi uewen mussen dee Prefix ëmmer nach zréck Richtung VPN-Server schécken, an dat maache si net, well de Server zoufälleg eng Adress dovun huet.

Dofir ass et och riskant, eng ëffentlech /64 an en Tunnelpool ze kopéieren. E Prefix, deen op de Server gerout gëtt, ass net datselwecht wéi e Prefix, deen d’Uewerlee als on-link behandelt, an d’Nopesch-Entdeckung fëllt dës Lück net.

Liest den Zoustand vum Server, ier Dir eppes ännert

Hält den Zoustand zweemol fest, eng Kéier wärend IPv6 funktionéiert an eng Kéier no dem Neistart, a vergläicht duerno. Just-Liese-Vuen sinn duergen, an si kaschten näischt wärend enger Ënnerhaltsfenster:

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

Sicht no dräi spezifeschen Ënnerscheeder: engem Wee, deen verschwonnen ass, enger Adress, déi op eng al oder ongülteg Liewensdauer gewiesselt ass, an engem Prefix, deen no der Neidelegatioun geännert huet, während d’VPN-Konfiguratioun nach déi al ugekënnegt.

Wann d’Adress verschwonnen ass, awer de Prefix onverännert, huet den Dämon, deen se vergëtt, opgehalen den Interface ze geréieren. Wann de Prefix sech geännert huet, awer d’Adressen net, ass d’Clientkonfiguratioun al. Déi zwou Feeler gesinn aus engem Browser identesch aus a si hu näischt gemeinsam.

Entscheet, ob dhcpcd den Tunnel geréiere soll

dhcpcd ka Schnëttstell erausfannen an Deeler vun engem DHCPv6-Prefix un ënnescht Schnëttstellen delegéieren, an seng Konfiguratioun ka d’Delegatiounsziler explicit nennen. Ouni en explicit Zil kann säi dokumentéierte Verhalen aner Schnëttstelle mat abezéien, an esou kritt en Tunnel eng Adress, déi kee geplangt huet.

Zwou Konditioune sollten Iech dozou dréien, d’statisch Adresséierung vum Tunnel dem OpenVPN ze iwwerloossen: de Server schéckt fix Adressen a senger Konfiguratioun, an den Tunnelsnumm ännert sech beim Neiushënn. Wann béides gëllt, schléisst den Tunnel bewosst aus dem Delegatiounsdämon aus, mat engem Kommentar, dee seet firwat.

Wann d’Delegatioun op den Tunnel dogéint bewosst ass, implementéiert d’Behandele vum Prefixwiessel. Dat heescht reagéieren, wann de delegéierte Prefix oder seng Liewensdauer sech ännert, de Clientprefix, deen de Server ugekënnegt, aktualiséieren, an de Wee nees bäisetzen. Den Interface an deem Design ausschléissen hëlt déi eenzeg Komponent ewech, déi vum neie Prefix weess.

En Neistart vum dhcpcd kann et gesinn, wéi wann et Saachen a Fuedem bréngt, well et den Zoustand nei schaaf, awer et erneiert oder zitt och Konfiguratioun fir Schnëttstelle zréck, un déi Dir net geduecht hutt. Dës Erhuelung mécht et net zu enger Fuerderung no all VPN-Neistart. Et setzt och d’Zieler zréck, déi Dir als Beweis benotzt hutt. Bevirzugt eng geziilten Neiopluede vum Interface, deen Dir tatsächlech geännert hutt.

Validéiert IPv6 getrennt vum IPv4-NAT

Bestätegt, datt d’Weiderleedung aktiv ass an de Wee no uewen op den tatsächleche Clientprefix weist, a maacht dann eng nei erlaabten IPv6-Verbindung. Kuckt och d’IPv6-Routetabell vum Client selwer, well en Client, deen eng ëffentlech Adress weist, net beweist, datt seng Ufro den Tunnel benotzt huet.

IPv4-Maskerading léist en anere Problem: de Retourwee fir privat Quellen. Et mécht näischt fir en zréckgezunnene IPv6-Prefix, a seng Derbäizetzung bréngt IPv6 net zréck.

Schléisst mat dem Eegentumsregister of: wéi eng Komponent de Prefix delegéiert, wéi eng d’Clientadressen undeelt, wéi eng de Retourwee hält, a wat mat all bei Neiushluss geschitt. Véier Zeilen an engem Runbook spuere beim nächsten Mënsch dräi Dämonen ze neistarten, fir deen ze fannen, op deen et ukoum.

Ähnlech Artikelen