IPv6-eliro mortas post OpenVPN-restartigo: kontrolu posedon de la prefikso

IPv6 ĉesas pasigi trafikon en la momento, kiam OpenVPN restartigas, kaj IPv4 daŭre funkcias. La tunela interfaco estis rekreita, kaj io alia, kio administris ĝian IPv6-staton, aŭ perdis la adreson aŭ perdis la itineron, kiu igas la prefikson atingebla. Tri apartaj partoj de stato estas implikitaj, kaj ĉiu havas alian posedanton: la delegita prefikso de la provizanto kaj ĝia vivodaŭro, la adresoj donitaj al VPN-klientoj, kaj la supra itinero, kiu resendas tiun klientan prefikson al la servilo. Identigu la posedanton de ĉiu parto antaŭ ol vi tuŝi ajnan demonon, ĉar restartigi la malĝustan kaŝas la problemon por unu tago kaj revenigas ĝin ĉe la sekva rekonekto.

Tri partoj de IPv6-stato, tri posedantoj

Tutmonde valida adreso interne de la tunelo mem ne sufiĉas. Supraj enkursigiloj ankoraŭ devas resendi tiun prefikson al la VPN-servilo, kaj ili ne faros tion nur ĉar la servilo hazarde havas adreson el ĝi.

Tial ankaŭ kopii publikan /64 en tunelan naĝujon estas riska. Itinero direktita al la servilo ne samas kiel prefikso, kiun la supra flanko traktas kiel on-link, kaj malkovro de najbaroj ne plenigos tiun mankon.

Legu la staton de la servilo antaŭ ol ŝanĝi ion ajn

Kaptu la staton dufoje, unufoje dum IPv6 funkcias kaj unufoje post la restartigo, tiam komparu. Nurlegaj vidoj sufiĉas, kaj ili kostas nenion dum prizorga fenestro:

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

Serĉu tri konkretajn diferencojn: itineron, kiu malaperis, adreson, kiu transiris al eksdata aŭ malvalida vivodaŭro, kaj prefikson, kiu ŝanĝiĝis post rea delegado dum la VPN-agordo ankoraŭ anoncas la malnovan.

Se la adreso malaperis sed la prefikso ne ŝanĝiĝis, la demono, kiu asignas ĝin, ĉesis administri la interfacon. Se la prefikso ŝanĝiĝis sed la adresoj ne, la klienta agordo estas eksdata. La du fiaskoj aspektas identaj el retumilo kaj havas nenion komunan.

Decidu, ĉu dhcpcd devas administri la tunelon

dhcpcd povas malkovri interfacojn kaj delegi partojn de DHCPv6-prefikso al malsupraj interfacoj, kaj ĝia agordo povas eksplicite nomi la delegajn celojn. Sen eksplicita celo, ĝia dokumentita konduto povas impliki aliajn interfacojn, kaj tiel tunelo finiĝas kun adreso, kiun neniu planis.

Du kondiĉoj devus puŝi vin lasi OpenVPN posedi la statikan adresadon de la tunelo: la servilo puŝas fiksajn adresojn en sia agordo, kaj la tunela nomo ŝanĝiĝas ĉe rekonekto. Se ambaŭ validas, intence ekskludu la tunelon de la delegada demono, kun komento, kiu diras kial.

Se anstataŭe la delegado al la tunelo estas intenca, efektivigu la traktadon de prefiksa ŝanĝo. Tio signifas reagi, kiam la delegita prefikso aŭ ĝia vivodaŭro ŝanĝiĝas, ĝisdatigi la anoncitan klientan prefikson de la servilo, kaj re-aldoni la itineron. Ekskludi la interfacon en tiu dezajno forigas la solan komponanton, kiu scias pri la nova prefikso.

Restartigi dhcpcd povas ŝajni ripari aferojn, ĉar ĝi rekreas staton, sed ĝi ankaŭ renovigas aŭ retiras agordon por interfacoj, pri kiuj vi ne pensis. Tiu riparo ne igas ĝin postulo post ĉiu VPN-restartigo. Ĝi ankaŭ restarigas la nombrilojn, kiujn vi uzis kiel pruvon. Preferu celitan reŝargon de la interfaco, kiun vi efektive ŝanĝis.

Validigu IPv6 aparte de IPv4 NAT

Konfirmu, ke plusendado estas ŝaltita kaj ke la supra itinero montras al la efektiva klienta prefikso, tiam faru novan permesitan IPv6-konekton. Kontrolu ankaŭ la propran IPv6-itineran tabelon de la kliento, ĉar kliento montranta publikan adreson ne pruvas, ke ĝia peto uzis la tunelon.

IPv4-maskado solvas alian problemon: la revenan vojon por privataj fontoj. Ĝi faras nenion por retirita IPv6-prefikso, kaj aldoni ĝin ne revenigos IPv6.

Finu per la posedregistro: kiu komponanto delegas la prefikson, kiu asignas klientajn adresojn, kiu tenas la revenan itineron, kaj kio okazas al ĉiu ĉe rekonekto. Kvar linioj en runbook ŝparas al la sekva persono restartigi tri demonojn por trovi la gravan.