IPv6-utgang døyr etter ein OpenVPN-omstart: sjekk kven som eig prefikset

IPv6 sluttar å føre trafikk i det augeblikket OpenVPN startar på nytt, og IPv4 held fram med å verke. Tunnelgrensesnittet vart gjenskapt, og noko anna som styrte IPv6-tilstanden til grensesnittet, mista anten adressa eller ruta som gjer prefikset tilgjengeleg. Tre separate delar av tilstanden er involvert, og kvar har ein annan eigar: det delegerte prefikset til leverandøren og levetida, adressene som blir gjevne til VPN-klientar, og oppstraumsruta som sender klientprefikset tilbake til serveren. Identifiser eigaren av kvar del før du rører ein daemon, fordi omstart av feil ein gøymer problemet i ein dag og bringar det tilbake ved neste tilkopling.

Tre delar IPv6-tilstand, tre eigarar

Ei adresse med globalt omfang inne i tunnelen er ikkje nok åleine. Oppstraumsrutarar må framleis sende prefikset tilbake mot VPN-serveren, og dei gjer det ikkje fordi serveren tilfeldigvis har ei adresse frå det.

Difor er det òg risikabelt å kopiere eit offentleg /64 inn i ein tunnelpool. Eit prefiks som blir ruta til serveren er ikkje det same som eit prefiks oppstraumssida handsamar som on-link, og nabo-oppdaging fyller ikkje dette gapet.

Les tilstanden til serveren før du endrar noko

Ta opp tilstanden to gonger, éin gong medan IPv6 verkar og éin gong etter omstarten, og samanlikn. Skriveverna visingar er nok, og dei kostar ingenting i eit vedlikehaldsvindauge:

ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwarding

Sjå etter tre konkrete skilnader: ei rute som forsvann, ei adresse som flytta til ei utdatert eller ugyldig levetid, og eit prefiks som endra seg etter ny delegering medan VPN-konfigurasjonen framleis annonserer det gamle.

Viss adressa forsvann men prefikset er uendra, har daemonen som tildeler ho slutta å styre grensesnittet. Viss prefikset endra seg men ikkje adressene, er klientkonfigurasjonen utdatert. Dei to feila ser identiske ut frå ein nettlesar og har ingenting til felles.

Avgjer om dhcpcd skal styre tunnelen

dhcpcd kan oppdage grensesnitt og delegere delar av eit DHCPv6-prefiks til nedstraums grensesnitt, og konfigurasjonen kan namngje delegeringsmåla eksplisitt. Utan eit eksplisitt mål kan den dokumenterte åtferda involvere andre grensesnitt, og det er slik ein tunnel endar med ei adresse ingen hadde planlagt.

To vilkår bør skyve deg mot å la OpenVPN eige den statiske adresseringa til tunnelen: serveren skyv faste adresser i konfigurasjonen sin, og tunnelnavnet endrar seg ved gjenoppkopling. Viss begge gjeld, utelukkar du tunnelen frå delegeringsdaemonen med vilje, med ein kommentar som seier kvifor.

Viss delegering til tunnelen derimot er tilsikta, implementer handteringa av prefiksendringar. Det betyr å reagere når det delegerte prefikset eller levetida endrar seg, oppdatere det annonserte klientprefikset til serveren og leggje ruta til på nytt. Å utelukke grensesnittet i det designet fjernar den einaste komponenten som kjenner det nye prefikset.

Omstart av dhcpcd kan sjå ut som det fiksar ting fordi det gjenopprettar tilstand, men det fornyar eller trekkjer òg tilbake konfigurasjon for grensesnitt du ikkje tenkte på. Den gjenopprettinga gjer det ikkje til eit krav etter kvar VPN-omstart. Det nullstiller òg teljarane du brukte som prov. Føretrekk ei målretta innlasting av grensesnittet du faktisk endra.

Valider IPv6 separat frå IPv4 NAT

Stadfest at videresending er slått på og at oppstraumsruta peikar på det faktiske klientprefikset, og lag deretter ei ny tillaten IPv6-tilkopling. Sjekk òg den eigen IPv6-rutetabellen til klienten, fordi ein klient som viser ei offentleg adresse ikkje provar at førespurnaden brukte tunnelen.

IPv4-maskering løyser eit anna problem: returvegen for private kjelder. Ho gjer ingenting for eit tilbaketrekte IPv6-prefiks, og å leggje ho til bringar ikkje IPv6 tilbake.

Avslutt med eigarregisteret: kva komponent som delegerer prefikset, kva som tildeler klientadresser, kva som held returruta, og kva som skjer med kvar av dei ved gjenoppkopling. Fire linjer i ein runbook sparer neste person å starte tre daemonar på nytt for å finne den som betydde noko.