Ieșirea IPv6 moare după o repornire a OpenVPN: verificați proprietatea prefixului
IPv6 moare după ce tunelul este recreat. Decideți cine deține prefixul delegat, adresele clienților și ruta de întoarcere înainte de a reporni ceva.
IPv6 încetează să mai treacă trafic în momentul în care OpenVPN repornește, iar IPv4 continuă să funcționeze. Interfața tunelului a fost recreată, iar altceva care îi gestiona starea IPv6 a pierdut fie adresa, fie ruta care face prefixul accesibil. Sunt implicate trei părți separate de stare, iar fiecare are alt proprietar: prefixul delegat al furnizorului și durata lui de viață, adresele date clienților VPN și ruta superioară care trimite acel prefix de client înapoi la server. Identificați proprietarul fiecărei părți înainte de a atinge vreun demon, pentru că repornirea celui greșit ascunde problema pentru o zi și o readuce la următoarea conectare.
Trei părți de stare IPv6, trei proprietari
| 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 |
O adresă cu scop global în interiorul tunelului nu este suficientă de una singură. Routerele de deasupra tot trebuie să trimită acel prefix înapoi spre serverul VPN, și nu o vor face doar pentru că serverul are din întâmplare o adresă din el.
De aceea este riscant și să copiați un /64 public într-un pool de tunel. Un prefix rutat către server nu este același lucru cu un prefix pe care partea de deasupra îl tratează ca on-link, iar descoperirea vecinilor nu va umple acest gol.
Citiți starea serverului înainte de a schimba ceva
Capturați starea de două ori, o dată cât timp IPv6 funcționează și o dată după repornire, apoi comparați. Vizualizările doar pentru citire sunt suficiente și nu costă nimic într-o fereastră de mentenanță:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingCăutați trei diferențe concrete: o rută care a dispărut, o adresă care a trecut la o durată de viață învechită sau invalidă, și un prefix care s-a schimbat după o redelegare în timp ce configurația VPN încă anunță vechiul.
Dacă adresa a dispărut dar prefixul este neschimbat, demonul care o alocă a încetat să mai gestioneze interfața. Dacă prefixul s-a schimbat dar adresele nu, configurația clientului este învechită. Cele două defecțiuni arată identic din browser și nu au nimic în comun.
Decideți dacă dhcpcd trebuie să gestioneze tunelul
dhcpcd poate descoperi interfețe și delega părți dintr-un prefix DHCPv6 interfețelor din aval, iar configurația lui poate numi explicit țintele delegării. Fără o țintă explicită, comportamentul documentat poate implica alte interfețe, și așa ajunge un tunel cu o adresă pe care nimeni nu a planificat-o.
Două condiții ar trebui să vă împingă să lăsați OpenVPN să dețină adresarea statică a tunelului: serverul împinge adrese fixe în configurația lui, iar numele tunelului se schimbă la reconectare. Dacă amândouă sunt valabile, excludeți tunelul din demonul de delegare în mod deliberat, cu un comentariu care spune de ce.
Dacă, în schimb, delegarea către tunel este deliberată, implementați tratarea schimbării prefixului. Asta înseamnă să reacționați când prefixul delegat sau durata lui de viață se schimbă, să actualizați prefixul de client anunțat de server și să adăugați din nou ruta. Excluderea interfeței în acel design elimină singura componentă care știe de noul prefix.
Repornirea dhcpcd poate părea că repară lucrurile pentru că recreează starea, dar reînnoiește sau retrage și configurația unor interfețe la care nu vă gândeați. Acea recuperare nu îl face obligatoriu după fiecare repornire VPN. Resetează și contoarele pe care le foloseați ca dovadă. Preferați o reîncărcare țintită a interfeței pe care ați modificat-o efectiv.
Validați IPv6 separat de NAT-ul IPv4
Confirmați că redirecționarea este activă și că ruta de deasupra indică prefixul real al clientului, apoi faceți o conexiune IPv6 nouă și permisă. Verificați și tabela de rutare IPv6 a clientului, pentru că un client care arată o adresă publică nu dovedește că cererea lui a folosit tunelul.
Mascarea IPv4 rezolvă altă problemă: calea de întoarcere pentru surse private. Nu face nimic pentru un prefix IPv6 retras, iar adăugarea ei nu va aduce IPv6 înapoi.
Încheiați cu registrul de proprietate: ce componentă delegă prefixul, care alocă adresele clienților, care ține ruta de întoarcere și ce se întâmplă cu fiecare la reconectare. Patru rânduri într-un runbook cruță următoarea persoană de a reporni trei demoni ca să îl găsească pe cel care conta.