IPv6-uitgang sterf ná ’n OpenVPN-herbegin: kyk wie die voorvoegsel besit
IPv6 sterf sodra die tonnel herskep word. Besluit wie die gedelegeerde voorvoegsel, die kliëntadresse en die terugroete besit voordat jy enigiets herbegin.
IPv6 hou op om verkeer deur te stuur die oomblik wanneer OpenVPN herbegin, en IPv4 bly werk. Die tonnelkoppelvlak is herskep, en iets anders wat sy IPv6-toestand bestuur het, het óf die adres verloor óf die roete verloor wat die voorvoegsel bereikbaar maak. Drie afsonderlike stukke toestand is betrokke, en elkeen het ’n ander eienaar: die verskaffer se gedelegeerde voorvoegsel en sy leeftyd, die adresse wat aan VPN-kliënte gegee word, en die opstroomroete wat daardie kliëntvoorvoegsel terug na die bediener stuur. Identifiseer die eienaar van elkeen voordat jy ’n daemon aanraak, want om die verkeerde een te herbegin verberg die probleem vir ’n dag en bring dit terug by die volgende heraansluiting.
Drie stukke IPv6-toestand, drie eienaars
| 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 |
’n Adres met globale omvang binne die tonnel is op sy eie nie genoeg nie. Opstroomroeteerders moet daardie voorvoegsel steeds terug na die VPN-bediener stuur, en hulle sal dit nie doen omdat die bediener toevallig ’n adres daaruit het nie.
Dit is ook waarom dit riskant is om ’n publieke /64 in ’n tonnelpoel te kopieer. ’n Voorvoegsel wat na die bediener gerouteer word, is nie dieselfde as ’n voorvoegsel wat die opstroom as on-link beskou nie, en buurontdekking sal nie die gaping vul nie.
Lees die bediener se toestand voordat jy iets verander
Neem die toestand twee keer op, een keer terwyl IPv6 werk en een keer ná die herbegin, en vergelyk dit dan. Leesalleen-aansigte is genoeg, en dit kos niks tydens ’n instandhoudingsvenster nie:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingSoek na drie spesifieke verskille: ’n roete wat verdwyn het, ’n adres wat na ’n verouderde of ongeldige leeftyd verskuif het, en ’n voorvoegsel wat ná herdelegering verander het terwyl die VPN-konfigurasie nog die oue adverteer.
As die adres verdwyn het maar die voorvoegsel onveranderd is, het die daemon wat dit toeken opgehou om die koppelvlak te bestuur. As die voorvoegsel verander het maar die adresse nie, is die kliëntkonfigurasie verouderd. Die twee foute lyk identies vanuit ’n blaaier en het niks gemeen nie.
Besluit of dhcpcd die tonnel moet bestuur
dhcpcd kan koppelvlakke ontdek en dele van ’n DHCPv6-voorvoegsel aan stroomaf-koppelvlakke delegeer, en sy konfigurasie kan die delegeringsteikens eksplisiet noem. Sonder ’n eksplisiete teiken kan sy gedokumenteerde gedrag ander koppelvlakke betrek, en dit is hoe ’n tonnel uiteindelik ’n adres kry wat niemand beplan het nie.
Twee voorwaardes behoort jou daartoe te dryf om OpenVPN die tonnel se statiese adressering te laat besit: die bediener stuur vaste adresse in sy konfigurasie, en die tonnelnaam verander by heraansluiting. As albei geld, sluit die tonnel doelbewus uit by die delegeringsdaemon, met ’n opmerking wat sê waarom.
As delegering na die tonnel eerder doelbewus is, implementeer die hantering van voorvoegselveranderinge. Dit beteken om te reageer wanneer die gedelegeerde voorvoegsel of sy leeftyd verander, die bediener se geadverteerde kliëntvoorvoegsel by te werk, en die roete weer by te voeg. Om die koppelvlak in daardie ontwerp uit te sluit, verwyder die enigste komponent wat van die nuwe voorvoegsel weet.
Om dhcpcd te herbegin kan lyk of dit dinge regmaak omdat dit toestand herskep, maar dit hernu of trek ook konfigurasie vir koppelvlakke in waaroor jy nie gedink het nie. Daardie herstel maak dit nie ’n vereiste ná elke VPN-herbegin nie. Dit stel ook die tellers terug wat jy as bewys gebruik het. Verkies ’n gerigte herlaai van die koppelvlak wat jy werklik verander het.
Valideer IPv6 apart van IPv4-NAT
Bevestig dat aanstuur geaktiveer is en dat die opstroomroete na die werklike kliëntvoorvoegsel wys, en maak dan ’n vars toegelate IPv6-verbinding. Kyk ook na die kliënt se eie IPv6-roetetabel, want ’n kliënt wat ’n publieke adres wys, bewys nie dat sy versoek die tonnel gebruik het nie.
IPv4-masquerading los ’n ander probleem op: die terugpad vir privaat bronne. Dit doen niks vir ’n onttrekte IPv6-voorvoegsel nie, en om dit by te voeg sal IPv6 nie terugbring nie.
Sluit af met die eienaarskaprekord: watter komponent die voorvoegsel delegeer, watter een kliëntadresse toeken, watter een die terugroete hou, en wat met elkeen gebeur by heraansluiting. Vier reëls in ’n runbook spaar die volgende persoon daarvan om drie daemons te herbegin om die een te vind wat saak gemaak het.