IPv6-utgang dør etter en OpenVPN-omstart: sjekk hvem som eier prefikset
IPv6 dør etter at tunnelen er gjenskapt. Bestem hvem som eier det delegerte prefikset, klientadressene og returruten før du starter noe på nytt.
IPv6 slutter å føre trafikk i det øyeblikket OpenVPN starter på nytt, og IPv4 fortsetter å virke. Tunnelgrensesnittet ble gjenskapt, og noe annet som administrerte IPv6-tilstanden dets, mistet enten adressen eller ruten som gjør prefikset tilgjengelig. Tre separate deler av tilstanden er involvert, og hver har en annen eier: leverandørens delegerte prefiks og levetiden dens, adressene som gis til VPN-klienter, og oppstrømsruten som sender klientprefikset tilbake til serveren. Identifiser eieren av hver del før du berører en daemon, fordi omstart av feil en skjuler problemet i en dag og bringer det tilbake ved neste tilkobling.
Tre deler IPv6-tilstand, tre eiere
| 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 inne i tunnelen er ikke nok alene. Oppstrømsrutere må fortsatt sende prefikset tilbake mot VPN-serveren, og de gjør det ikke fordi serveren tilfeldigvis har en adresse fra det.
Derfor er det også risikabelt å kopiere et offentlig /64 inn i en tunnelpool. Et prefiks som rutes til serveren er ikke det samme som et prefiks oppstrømssiden behandler som on-link, og nabo-oppdagelse fyller ikke dette gapet.
Les serverens tilstand før du endrer noe
Ta opp tilstanden to ganger, én gang mens IPv6 virker og én gang etter omstarten, og sammenlign. Skrivebeskyttede visninger er nok, og de koster ingenting i et vedlikeholdsvindu:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingSe etter tre konkrete forskjeller: en rute som forsvant, en adresse som flyttet til en utdatert eller ugyldig levetid, og et prefiks som endret seg etter ny delegering mens VPN-konfigurasjonen fortsatt annonserer det gamle.
Hvis adressen forsvant men prefikset er uendret, har daemonen som tildeler den sluttet å administrere grensesnittet. Hvis prefikset endret seg men ikke adressene, er klientkonfigurasjonen utdatert. De to feilene ser identiske ut fra en nettleser og har ingenting til felles.
Bestem om dhcpcd skal administrere tunnelen
dhcpcd kan oppdage grensesnitt og delegere deler av et DHCPv6-prefiks til nedstrøms grensesnitt, og konfigurasjonen kan navngi delegeringsmålene eksplisitt. Uten et eksplisitt mål kan den dokumenterte oppførselen involvere andre grensesnitt, og det er slik en tunnel ender med en adresse ingen hadde planlagt.
To forhold bør skyve deg mot å la OpenVPN eie tunnelens statiske adressering: serveren skyver faste adresser i konfigurasjonen sin, og tunnelnavnet endres ved gjenoppkobling. Hvis begge gjelder, utelukker du tunnelen fra delegeringsdaemonen med vilje, med en kommentar som sier hvorfor.
Hvis delegering til tunnelen derimot er tilsiktet, implementer håndteringen av prefiksendringer. Det betyr å reagere når det delegerte prefikset eller levetiden endres, oppdatere serverens annonserte klientprefiks og legge ruten til på nytt. Å utelukke grensesnittet i det designet fjerner den eneste komponenten som kjenner det nye prefikset.
Omstart av dhcpcd kan se ut som det fikser ting fordi det gjenoppretter tilstand, men det fornyer eller trekker også tilbake konfigurasjon for grensesnitt du ikke tenkte på. Den gjenopprettingen gjør det ikke til et krav etter hver VPN-omstart. Det nullstiller også tellerne du brukte som bevis. Foretrekk en målrettet innlasting av grensesnittet du faktisk endret.
Valider IPv6 separat fra IPv4 NAT
Bekreft at videresending er aktivert og at oppstrømsruten peker på det faktiske klientprefikset, og lag deretter en ny tillatt IPv6-tilkobling. Sjekk også klientens egen IPv6-rutetabell, fordi en klient som viser en offentlig adresse ikke beviser at forespørselen brukte tunnelen.
IPv4-maskering løser et annet problem: returveien for private kilder. Den gjør ingenting for et tilbaketrukket IPv6-prefiks, og å legge den til bringer ikke IPv6 tilbake.
Avslutt med eierregisteret: hvilken komponent som delegerer prefikset, hvilken som tildeler klientadresser, hvilken som holder returruten, og hva som skjer med hver av dem ved gjenoppkobling. Fire linjer i en runbook sparer neste person for å starte tre daemoner på nytt for å finne den som betydde noe.