IPv6 izlaz umire nakon ponovnog pokretanja OpenVPN-a: provjerite ko posjeduje prefiks
IPv6 umire nakon što se tunel ponovo kreira. Odlučite ko posjeduje delegirani prefiks, adrese klijenata i povratnu rutu prije nego što bilo šta ponovo pokrenete.
IPv6 prestaje propuštati saobraćaj u trenutku kada se OpenVPN ponovo pokrene, a IPv4 nastavlja raditi. Sučelje tunela je ponovo kreirano, a nešto drugo što je upravljalo njegovim IPv6 stanjem ili je izgubilo adresu ili je izgubilo rutu koja prefiks čini dostupnim. Uključena su tri odvojena dijela stanja i svaki ima drugog vlasnika: delegirani prefiks provajdera i njegov životni vijek, adrese dodijeljene VPN klijentima i uzlazna ruta koja taj klijentski prefiks šalje natrag serveru. Identificirajte vlasnika svakog dijela prije nego što dirnete bilo koji demon, jer ponovno pokretanje pogrešnog skriva problem na dan i vraća ga pri sljedećem povezivanju.
Tri dijela IPv6 stanja, tri vlasnika
| 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 |
Adresa globalnog opsega unutar tunela nije dovoljna sama po sebi. Uzlazni ruteri i dalje moraju slati taj prefiks natrag prema VPN serveru, a neće to učiniti zato što server slučajno ima adresu iz njega.
Zato je i kopiranje javnog /64 u bazen tunela rizično. Prefiks usmjeren na server nije isto što i prefiks koji uzlazna strana tretira kao on-link, a otkrivanje susjeda neće popuniti tu prazninu.
Pročitajte stanje servera prije nego što bilo šta promijenite
Snimite stanje dva puta, jednom dok IPv6 radi i jednom nakon ponovnog pokretanja, pa uporedite. Prikazi samo za čitanje su dovoljni i ništa ne koštaju tokom prozora za održavanje:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingTražite tri konkretne razlike: rutu koja je nestala, adresu koja je prešla na zastarjeli ili nevažeći životni vijek i prefiks koji se promijenio nakon ponovnog delegiranja dok VPN konfiguracija još oglašava stari.
Ako je adresa nestala, ali prefiks nije promijenjen, demon koji je dodjeljuje prestao je upravljati sučeljem. Ako se prefiks promijenio, ali adrese nisu, konfiguracija klijenta je zastarjela. Dva kvara izgledaju identično iz preglednika i nemaju ništa zajedničko.
Odlučite treba li dhcpcd upravljati tunelom
dhcpcd može otkriti sučelja i delegirati dijelove DHCPv6 prefiksa nizvodnim sučeljima, a njegova konfiguracija može izričito navesti ciljeve delegiranja. Bez izričitog cilja, njegovo dokumentirano ponašanje može uključiti druga sučelja, i tako tunel dobije adresu koju niko nije planirao.
Dva uslova treba da vas navedu da pustite OpenVPN da posjeduje statičko adresiranje tunela: server gura fiksne adrese u svojoj konfiguraciji i ime tunela se mijenja pri ponovnom povezivanju. Ako oba vrijede, namjerno isključite tunel iz demona za delegiranje, uz komentar koji kaže zašto.
Ako je delegiranje tunelu ipak namjerno, implementirajte obradu promjene prefiksa. To znači reagirati kada se delegirani prefiks ili njegov životni vijek promijeni, ažurirati oglašeni klijentski prefiks servera i ponovo dodati rutu. Isključivanje sučelja u tom dizajnu uklanja jedinu komponentu koja zna za novi prefiks.
Ponovno pokretanje dhcpcd-a može izgledati kao da popravlja stvari jer ponovo kreira stanje, ali ono takođe obnavlja ili povlači konfiguraciju za sučelja o kojima niste razmišljali. Takav oporavak ga ne čini obaveznim nakon svakog ponovnog pokretanja VPN-a. Ono takođe resetuje brojače koje ste koristili kao dokaz. Preferirajte ciljano ponovno učitavanje sučelja koje ste zaista promijenili.
Provjerite IPv6 odvojeno od IPv4 NAT-a
Potvrdite da je prosljeđivanje omogućeno i da uzlazna ruta pokazuje na stvarni klijentski prefiks, zatim uspostavite novu dozvoljenu IPv6 vezu. Provjerite i klijentovu vlastitu IPv6 tablicu ruta, jer klijent koji prikazuje javnu adresu ne dokazuje da je njegov zahtjev išao kroz tunel.
IPv4 maskiranje rješava drugi problem: povratnu putanju za privatne izvore. Ono ne čini ništa za povučeni IPv6 prefiks, a dodavanje ga neće vratiti IPv6.
Završite zapisom o vlasništvu: koja komponenta delegira prefiks, koja dodjeljuje adrese klijenata, koja drži povratnu rutu i šta se sa svakom dešava pri ponovnom povezivanju. Četiri reda u runbook-u spašavaju sljedeću osobu od ponovnog pokretanja tri demona da bi našla onaj koji je bio važan.