IPv6 išėjimas miršta po OpenVPN perkrovimo: patikrinkite prefikso nuosavybę
IPv6 miršta, kai tunelis sukuriamas iš naujo. Nuspręskite, kam priklauso deleguotas prefiksas, klientų adresai ir grįžimo maršrutas, prieš ką nors perkraudami.
IPv6 nustoja praleisti srautą tą akimirką, kai OpenVPN persikrauna, o IPv4 toliau veikia. Tunelio sąsaja buvo sukurta iš naujo, ir kažkas kita, kas valdė jos IPv6 būseną, prarado arba adresą, arba maršrutą, kuris padaro prefiksą pasiekiamą. Dalyvauja trys atskiros būsenos dalys, ir kiekviena turi skirtingą savininką: teikėjo deleguotas prefiksas ir jo galiojimo trukmė, VPN klientams suteikti adresai ir aukštupio maršrutas, kuris tą kliento prefiksą grąžina serveriui. Nustatykite kiekvienos dalies savininką, prieš liesdami bet kurį demoną, nes netinkamo perkrovimas paslepia problemą vienai dienai ir grąžina ją kitam prisijungimui.
Trys IPv6 būsenos dalys, trys savininkai
| 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 |
Visuotinės apimties adresas tunelio viduje pats savaime nepakanka. Aukštupio maršrutizatoriai vis tiek turi siųsti tą prefiksą atgal VPN serveriui, ir jie to nedarys vien todėl, kad serveris atsitiktinai turi adresą iš jo.
Štai kodėl viešo /64 kopijavimas į tunelio telkinį yra rizikingas. Prefiksas, nukreiptas į serverį, nėra tas pats, ką aukštupys laiko on-link, ir kaimynų aptikimas šios spragos neužpildys.
Perskaitykite serverio būseną, prieš ką nors keisdami
Užfiksuokite būseną du kartus, vieną kartą kol IPv6 veikia, ir vieną kartą po perkrovimo, tada palyginkite. Tik skaitymo rodinių pakanka, ir priežiūros lange jie nieko nekainuoja:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingIeškokite trijų konkrečių skirtumų: išnykusio maršruto, adreso, kuris perėjo į pasenusią arba negaliojančią galiojimo trukmę, ir prefikso, kuris pasikeitė po pakartotinio delegavimo, nors VPN konfigūracija vis dar skelbia senąjį.
Jei adresas išnyko, bet prefiksas nepakito, jį priskiriantis demonas nustojo valdyti sąsają. Jei prefiksas pasikeitė, bet adresai ne, kliento konfigūracija pasenusi. Abi gedimai iš naršyklės atrodo vienodai ir neturi nieko bendra.
Nuspręskite, ar dhcpcd turi valdyti tunelį
dhcpcd gali aptikti sąsajas ir deleguoti DHCPv6 prefikso dalis žemutinėms sąsajoms, o jo konfigūracija gali aiškiai įvardyti delegavimo tikslus. Be aiškaus tikslo jo dokumentuotas elgesys gali apimti kitas sąsajas, ir taip tunelis gauna adresą, kurio niekas neplanavo.
Dvi sąlygos turėtų paskatinti jus leisti OpenVPN valdyti statinį tunelio adresavimą: serveris savo konfigūracijoje stumia fiksuotus adresus, ir tunelio pavadinimas keičiasi prisijungus iš naujo. Jei galioja abi, sąmoningai išskirkite tunelį iš delegavimo demono, su komentaru, kuriame nurodyta priežastis.
Jei delegavimas į tunelį yra sąmoningas, įdiekite prefikso pasikeitimo apdorojimą. Tai reiškia reaguoti, kai pasikeičia deleguotas prefiksas ar jo galiojimo trukmė, atnaujinti serverio skelbiamą kliento prefiksą ir vėl pridėti maršrutą. Sąsajos išskyrimas tokiame projekte pašalina vienintelį komponentą, kuris žino apie naują prefiksą.
dhcpcd perkrovimas gali atrodyti, kad viską sutvarko, nes sukuria būseną iš naujo, bet jis taip pat atnaujina arba atšaukia konfigūraciją sąsajoms, apie kurias negalvojote. Toks atkūrimas nepadaro jo privalomu po kiekvieno VPN perkrovimo. Jis taip pat nunulina skaitiklius, kuriuos naudojote kaip įrodymą. Pirmenybę teikite tiksliniam sąsajos, kurią tikrai pakeitėte, perkrovimui.
Tikrinkite IPv6 atskirai nuo IPv4 NAT
Patvirtinkite, kad persiuntimas įjungtas ir aukštupio maršrutas rodo į tikrąjį kliento prefiksą, tada užmegzkite naują leidžiamą IPv6 ryšį. Patikrinkite ir paties kliento IPv6 maršrutų lentelę, nes klientas, rodantis viešą adresą, neįrodo, kad jo užklausa naudojo tunelį.
IPv4 maskavimas sprendžia kitą problemą: grįžimo kelią privatiems šaltiniams. Jis nieko nedaro atšauktam IPv6 prefiksui, ir jo pridėjimas negrąžins IPv6.
Užbaikite nuosavybės registru: kuris komponentas deleguoja prefiksą, kuris priskiria klientų adresus, kuris laiko grįžimo maršrutą, ir kas atsitinka kiekvienam prisijungus iš naujo. Keturių eilučių runbookas sutaupo kitam žmogui trijų demonų perkrovimą ieškant to, kuris buvo svarbus.