Izhod IPv6 umre po ponovnem zagonu OpenVPN: preverite lastništvo predpone
IPv6 umre po tem, ko je tunel znova ustvarjen. Odločite, kdo ima delegirano predpono, naslove odjemalcev in povratno pot, preden karkoli znova zaženete.
IPv6 preneha prepuščati promet v trenutku, ko se OpenVPN znova zažene, IPv4 pa deluje naprej. Vmesnik tunela je bil znova ustvarjen, in nekaj drugega, kar je upravljalo njegovo stanje IPv6, je izgubilo bodisi naslov bodisi pot, ki dela predpono dosegljivo. Vključeni so trije ločeni deli stanja in vsak ima drugega lastnika: delegirana predpona ponudnika in njena življenjska doba, naslovi, dodeljeni odjemalcem VPN, in pot navzgor, ki to odjemalčevo predpono pošlje nazaj strežniku. Ugotovite lastnika vsakega dela, preden se dotaknete katerega koli demona, ker ponovni zagon napačnega problem skrije za en dan in ga vrne ob naslednji povezavi.
Trije deli stanja IPv6, trije lastniki
| 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 |
Naslov z globalnim obsegom znotraj tunela sam po sebi ni dovolj. Usmerjevalniki zgoraj morajo to predpono še vedno pošiljati nazaj proti strežniku VPN, in tega ne bodo storili samo zato, ker ima strežnik slučajno naslov iz nje.
Zato je tudi kopiranje javnega /64 v bazen tunela tvegano. Predpona, usmerjena na strežnik, ni isto kot predpona, ki jo zgornja stran obravnava kot on-link, in odkrivanje sosedov te vrzeli ne bo zapolnilo.
Preberite stanje strežnika, preden karkoli spremenite
Zajemite stanje dvakrat, enkrat medtem ko IPv6 deluje in enkrat po ponovnem zagonu, nato primerjajte. Pogledi samo za branje zadostujejo in v oknu vzdrževanja ne stanejo nič:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingPoiščite tri konkretne razlike: pot, ki je izginila, naslov, ki je prešel v zastarelo ali neveljavno življenjsko dobo, in predpono, ki se je spremenila po ponovnem delegiranju, medtem ko konfiguracija VPN še vedno oglašuje staro.
Če je naslov izginil, predpona pa je nespremenjena, je demon, ki ga dodeljuje, prenehal upravljati vmesnik. Če se je predpona spremenila, naslovi pa ne, je konfiguracija odjemalca zastarela. Obe okvari sta iz brskalnika videti enako in nimata nič skupnega.
Odločite, ali naj dhcpcd upravlja tunel
dhcpcd lahko odkriva vmesnike in delegira dele predpone DHCPv6 nižjim vmesnikom, njegova konfiguracija pa lahko izrecno poimenuje cilje delegiranja. Brez izrecnega cilja lahko njegovo dokumentirano vedenje vključi druge vmesnike, in tako tunel dobi naslov, ki ga ni nihče načrtoval.
Dva pogoja bi vas morala spodbuditi, da statično naslavljanje tunela prepustite OpenVPN: strežnik v svoji konfiguraciji potiska fiksne naslove in ime tunela se ob ponovni povezavi spremeni. Če velja oboje, namerno izključite tunel iz demona za delegiranje, s komentarjem, ki pove zakaj.
Če pa je delegiranje v tunel namerno, uvedite obravnavo spremembe predpone. To pomeni odzivati se, ko se delegirana predpona ali njena življenjska doba spremeni, posodobiti odjemalčevo predpono, ki jo oglašuje strežnik, in znova dodati pot. Izključitev vmesnika v taki zasnovi odstrani edino komponento, ki ve za novo predpono.
Ponovni zagon dhcpcd je lahko videti kot popravilo, ker znova ustvari stanje, a tudi obnovi ali prekliče konfiguracijo vmesnikom, na katere niste pomislili. Takšno obnovitev iz njega ne naredi obveznosti po vsakem ponovnem zagonu VPN. Prav tako ponastavi števce, ki ste jih uporabljali kot dokaz. Raje izberite ciljno ponovno nalaganje vmesnika, ki ste ga resnično spremenili.
Preverjajte IPv6 ločeno od IPv4 NAT
Potrdite, da je posredovanje omogočeno in da pot navzgor kaže na dejansko odjemalčevo predpono, nato vzpostavite novo dovoljeno povezavo IPv6. Preverite tudi odjemalčevo lastno usmerjevalno tabelo IPv6, ker odjemalec, ki prikazuje javni naslov, ne dokazuje, da je njegova zahteva uporabila tunel.
Maskiranje IPv4 rešuje drugo težavo: povratno pot za zasebne vire. Za preklicano predpono IPv6 ne naredi ničesar in dodajanje tega ne bo vrnilo IPv6.
Zaključite z registrom lastništva: katera komponenta delegira predpono, katera dodeljuje naslove odjemalcev, katera drži povratno pot in kaj se z vsako zgodi ob ponovni povezavi. Štiri vrstice v runbooku prihranijo naslednji osebi ponovni zagon treh demonov, da najde tistega, ki je bil pomemben.