Dalja IPv6 vdes pas një rinisjeje të OpenVPN: kontrolloni pronësinë e prefiksit
IPv6 vdes pasi tuneli rikrijohet. Vendosni kush zotëron prefiksin e deleguar, adresat e klientëve dhe rrugën e kthimit para se të rinisni çdo gjë.
IPv6 ndalon kalimin e trafikut në momentin kur OpenVPN riniset, dhe IPv4 vazhdon të funksionojë. Ndërfaqja e tunelit u rikrijua, dhe diçka tjetër që menaxhonte gjendjen e saj IPv6 humbi ose adresën ose rrugën që e bën prefiksin të arritshëm. Janë të përfshira tre pjesë të ndryshme të gjendjes, dhe secila ka një pronar tjetër: prefiksi i deleguar i ofruesit dhe jetëgjatësia e tij, adresat që u jepen klientëve VPN, dhe rruga e sipërme që e kthen atë prefiks klienti te serveri. Identifikoni pronarin e secilës pjesë para se të prekni ndonjë demon, sepse rinisja e të gabuarit e fsheh problemin për një ditë dhe e kthen atë në lidhjen tjetër.
Tri pjesë të gjendjes IPv6, tre pronarë
| 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 |
Një adresë me shtrirje globale brenda tunelit nuk mjafton vetëm. Ruterat e sipërm duhet ende ta dërgojnë atë prefiks përsëri drejt serverit VPN, dhe nuk do ta bëjnë vetëm sepse serveri ka rastësisht një adresë prej tij.
Për këtë arsye është gjithashtu e rrezikshme kopjimi i një /64 publik në një pishinë tuneli. Një prefiks i rrugëzuar drejt serverit nuk është i njëjtë me një prefiks që ana e sipërme e trajton si on-link, dhe zbulimi i fqinjëve nuk do ta mbushë këtë hendek.
Lexoni gjendjen e serverit para se të ndryshoni ndonjë gjë
Kapni gjendjen dy herë, një herë ndërsa IPv6 funksionon dhe një herë pas rinisjes, pastaj krahasoni. Pamjet vetëm-lexim mjaftojnë, dhe nuk kushtojnë asgjë gjatë një dritareje mirëmbajtjeje:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingKërkoni tre dallime të veçanta: një rrugë që u zhduk, një adresë që kaloi në një jetëgjatësi të vjetëruar ose të pavlefshme, dhe një prefiks që ndryshoi pas ridelegimit ndërsa konfigurimi VPN vazhdon të shpallë atë të vjetrin.
Nëse adresa u zhduk por prefiksi nuk ndryshoi, demoni që e cakton ndaloi menaxhimin e ndërfaqes. Nëse prefiksi ndryshoi por adresat jo, konfigurimi i klientit është i vjetëruar. Dy dështimet duken identike nga shfletuesi dhe nuk kanë asgjë të përbashkët.
Vendosni nëse dhcpcd duhet të menaxhojë tunelin
dhcpcd mund të zbulojë ndërfaqe dhe të delegojë pjesë të një prefiksi DHCPv6 tek ndërfaqet e poshtme, dhe konfigurimi i tij mund t'i emërojë shprehimisht objektivat e delegimit. Pa një objektiv të qartë, sjellja e tij e dokumentuar mund të përfshijë ndërfaqe të tjera, dhe kështu një tunel përfundon me një adresë që askush nuk e kishte planifikuar.
Dy kushte duhet t'ju shtyjnë ta lini OpenVPN të zotërojë adresimin statik të tunelit: serveri shtyn adresa fikse në konfigurimin e tij, dhe emri i tunelit ndryshon gjatë rilidhjes. Nëse të dyja vlejnë, përjashtoni tunelin nga demoni i delegimit me qëllim, me një koment që thotë pse.
Nëse përkundrazi delegimi te tuneli është i qëllimshëm, zbatoni trajtimin e ndryshimit të prefiksit. Kjo do të thotë të reagoni kur prefiksi i deleguar ose jetëgjatësia e tij ndryshon, të përditësoni prefiksin e klientit të shpallur nga serveri, dhe të shtoni përsëri rrugën. Përjashtimi i ndërfaqes në atë dizajn heq komponentin e vetëm që e njeh prefiksin e ri.
Rinisja e dhcpcd mund të duket se i rregullon gjërat sepse rikrijon gjendjen, por gjithashtu rinovon ose tërheq konfigurimin për ndërfaqe për të cilat nuk po mendonit. Ai rikuperim nuk e bën atë të detyrueshëm pas çdo rinisjeje VPN. Ai gjithashtu rivendos numëruesit që po përdornit si provë. Preferoni një ringarkim të synuar të ndërfaqes që ndryshuat vërtet.
Validoni IPv6 veçmas nga NAT-i IPv4
Konfirmoni që përcjellja është e aktivizuar dhe që rruga e sipërme tregon prefiksin real të klientit, pastaj bëni një lidhje të re IPv6 të lejuar. Kontrolloni gjithashtu tabelën e rrugëve IPv6 të vetë klientit, sepse një klient që shfaq një adresë publike nuk dëshmon që kërkesa e tij përdori tunelin.
Maskimi IPv4 zgjidh një problem tjetër: rrugën e kthimit për burimet private. Nuk bën asgjë për një prefiks IPv6 të tërhequr, dhe shtimi i tij nuk do ta kthejë IPv6.
Përfundoni me regjistrin e pronësisë: cili komponent delegon prefiksin, cili cakton adresat e klientëve, cili mban rrugën e kthimit, dhe çfarë ndodh me secilin në rilidhje. Katër rreshta në një runbook i kursejnë një njeriu tjetër rinisjen e tre demonëve për të gjetur atë që kishte rëndësi.