IPv6 výstup zomiera po reštarte OpenVPN: skontrolujte vlastníctvo prefixu
IPv6 zomiera po opätovnom vytvorení tunela. Rozhodnite, komu patrí delegovaný prefix, adresy klientov a návratová trasa, skôr než čokoľvek reštartujete.
IPv6 prestane prechádzať prevádzku v momente, keď sa OpenVPN reštartuje, a IPv4 funguje ďalej. Rozhranie tunela bolo vytvorené znova a niečo iné, čo spravovalo jeho stav IPv6, stratilo buď adresu, alebo trasu, ktorá robí prefix dostupným. Ide o tri oddelené časti stavu a každá má iného vlastníka: delegovaný prefix poskytovateľa a jeho životnosť, adresy pridelené klientom VPN a trasa nahor, ktorá vracia ten klientsky prefix serveru. Určite vlastníka každej časti skôr, než sa dotknete akéhokoľvek démona, pretože reštart nesprávneho problém na deň skryje a vráti ho pri ďalšom pripojení.
Tri časti stavu IPv6, traja vlastníci
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Adresa s globálnym rozsahom vo vnútri tunela sama nestačí. Smerovače vyššie musia ten prefix stále posielať späť k serveru VPN, a neurobia to len preto, že server má náhodou adresu z neho.
Preto je tiež riskantné kopírovať verejný /64 do fondu tunela. Prefix smerovaný na server nie je to isté ako prefix, ktorý horná strana považuje za on-link, a objavovanie susedov túto medzeru nevyplní.
Prečítajte si stav servera, skôr než čokoľvek zmeníte
Zachyťte stav dvakrát, raz keď IPv6 funguje a raz po reštarte, a potom ich porovnajte. Zobrazenia len na čítanie stačia a počas okna údržby nič nestoja:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingHľadajte tri konkrétne rozdiely: trasu, ktorá zmizla, adresu, ktorá prešla na zastaranú alebo neplatnú životnosť, a prefix, ktorý sa zmenil po opätovnom delegovaní, kým konfigurácia VPN stále inzeruje ten starý.
Ak adresa zmizla, ale prefix sa nezmenil, démon, ktorý ju prideľuje, prestal spravovať rozhranie. Ak sa prefix zmenil, ale adresy nie, konfigurácia klienta je zastaraná. Obe poruchy vyzerajú z prehliadača rovnako a nemajú nič spoločné.
Rozhodnite, či má dhcpcd spravovať tunel
dhcpcd dokáže objavovať rozhrania a delegovať časti prefixu DHCPv6 nižším rozhraniam a jeho konfigurácia môže výslovne pomenovať ciele delegovania. Bez výslovného cieľa môže jeho dokumentované správanie zahŕňať iné rozhrania, a tak sa tunel ocitne s adresou, ktorú nikto neplánoval.
Dve podmienky by vás mali viesť k tomu, aby ste statické adresovanie tunela nechali na OpenVPN: server vnucuje pevné adresy vo svojej konfigurácii a názov tunela sa pri opätovnom pripojení mení. Ak platia obe, zámerne vylúčte tunel z démona delegovania, s komentárom, ktorý vysvetlí prečo.
Ak je delegovanie do tunela naopak zámerné, implementujte spracovanie zmeny prefixu. To znamená reagovať, keď sa delegovaný prefix alebo jeho životnosť zmení, aktualizovať serverom inzerovaný klientsky prefix a znova pridať trasu. Vylúčenie rozhrania v takom návrhu odstráni jediný komponent, ktorý o novom prefixe vie.
Reštart dhcpcd môže vyzerať, že veci opraví, pretože znova vytvorí stav, ale tiež obnovuje alebo odoberá konfiguráciu rozhraniam, na ktoré ste nemysleli. Také obnovenie z neho nerobí povinnosť po každom reštarte VPN. Tiež vynuluje počítadlá, ktoré ste používali ako dôkaz. Uprednostnite cielené opätovné načítanie rozhrania, ktoré ste skutočne zmenili.
Overujte IPv6 oddelene od IPv4 NAT
Potvrďte, že preposielanie je zapnuté a že trasa nahor ukazuje na skutočný klientsky prefix, a potom nadviažte nové povolené pripojenie IPv6. Skontrolujte aj vlastnú smerovaciu tabuľku IPv6 klienta, pretože klient zobrazujúci verejnú adresu nedokazuje, že jeho požiadavka išla tunelom.
Maskovanie IPv4 rieši iný problém: návratovú cestu pre súkromné zdroje. Pre odobraný prefix IPv6 nerobí nič a jeho pridanie IPv6 nevráti.
Ukončite záznamom o vlastníctve: ktorý komponent prefix deleguje, ktorý prideľuje adresy klientov, ktorý drží návratovú trasu a čo sa s každým stane pri opätovnom pripojení. Štyri riadky v runbooku ušetria ďalšiemu človeku reštart troch démonov, aby našiel ten, na ktorom záležalo.