IPv6-udgang dør efter en genstart af OpenVPN: kontrollér præfiksets ejerforhold
IPv6 dør, når tunnelen genskabes. Afgør, hvem der ejer det delegerede præfiks, klientadresserne og returruten, før du genstarter noget.
IPv6 holder op med at føre trafik i det øjeblik, OpenVPN genstarter, og IPv4 bliver ved med at virke. Tunnelinterfacet blev genskabt, og noget andet, der styrede dets IPv6-tilstand, mistede enten adressen eller ruten, der gør præfikset nåbart. Der er tre separate stykker tilstand involveret, og hver har en anden ejer: udbyderens delegerede præfiks og dets levetid, de adresser, der gives til VPN-klienter, og den opstrøms rute, der sender klientpræfikset tilbage til serveren. Identificér ejeren af hvert stykke, før du rører en daemon, fordi genstart af den forkerte skjuler problemet i en dag og bringer det tilbage ved næste genopkobling.
Tre stykker IPv6-tilstand, tre ejere
| 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 |
En adresse med globalt omfang inde i tunnelen er ikke nok i sig selv. Opstrømsroutere skal stadig sende præfikset tilbage mod VPN-serveren, og de gør det ikke, fordi serveren tilfældigvis har en adresse derfra.
Det er også derfor, det er risikabelt at kopiere et offentligt /64 ind i en tunnelpulje. Et præfiks, der rutes til serveren, er ikke det samme som et præfiks, opstrøms siden behandler som on-link, og nabo-discovery udfylder ikke hullet.
Læs serverens tilstand, før du ændrer noget
Optag tilstanden to gange, en gang mens IPv6 virker og en gang efter genstarten, og sammenlign så. Skrivebeskyttede visninger er nok, og de koster intet i et vedligeholdelsesvindue:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwarding
Led efter tre specifikke forskelle: en rute, der forsvandt, en adresse, der skiftede til en forældet eller ugyldig levetid, og et præfiks, der ændrede sig efter ny delegering, mens VPN-konfigurationen stadig annoncerer det gamle.
Hvis adressen forsvandt, men præfikset er uændret, er daemonen, der tildeler den, holdt op med at styre interfacet. Hvis præfikset ændrede sig, men adresserne ikke, er klientkonfigurationen forældet. De to fejl ser ens ud fra en browser og har intet til fælles.
Afgør, om dhcpcd skal styre tunnelen
dhcpcd kan opdage interfaces og delegere dele af et DHCPv6-præfiks til nedstrøms interfaces, og dens konfiguration kan navngive delegeringsmålene eksplicit. Uden et eksplicit mål kan dens dokumenterede adfærd involvere andre interfaces, og det er sådan en tunnel ender med en adresse, ingen havde planlagt.
To betingelser bør skubbe dig mod at lade OpenVPN eje tunnelens statiske adressering: serveren skubber faste adresser i sin konfiguration, og tunnelens navn ændres ved genopkobling. Hvis begge holder, udeluk tunnelen fra delegeringsdaemonen med vilje, med en kommentar der forklarer hvorfor.
Hvis delegering til tunnelen i stedet er tilsigtet, implementér håndteringen af præfiksskift. Det betyder at reagere, når det delegerede præfiks eller dets levetid ændres, opdatere serverens annoncerede klientpræfiks og tilføje ruten igen. At udelukke interfacet i det design fjerner den eneste komponent, der kender det nye præfiks.
Genstart af dhcpcd kan se ud til at rette tingene, fordi det genskaber tilstand, men det fornyer eller trækker også konfiguration tilbage for interfaces, du ikke tænkte på. Den gendannelse gør det ikke til et krav efter hver VPN-genstart. Det nulstiller også de tællere, du brugte som bevis. Foretræk en målrettet genindlæsning af det interface, du faktisk ændrede.
Validér IPv6 adskilt fra IPv4 NAT
Bekræft, at videresendelse er aktiveret, og at opstrømsruten peger på det faktiske klientpræfiks, og lav så en ny tilladt IPv6-forbindelse. Tjek også klientens egen IPv6-rutetabel, fordi en klient, der viser en offentlig adresse, ikke beviser, at dens anmodning brugte tunnelen.
IPv4-maskering løser et andet problem: returvejen for private kilder. Den gør intet for et tilbagetrukket IPv6-præfiks, og at tilføje den bringer ikke IPv6 tilbage.
Afslut med ejerforholdsregistreringen: hvilken komponent delegerer præfikset, hvilken tildeler klientadresser, hvilken holder returruten, og hvad der sker med hver af dem ved genopkobling. Fire linjer i en runbook sparer den næste person for at genstarte tre daemons for at finde den, der betød noget.