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

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

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.

Relaterede artikler