IPv6 printr-un tunel OpenVPN: o trecere prin routerul de acasă

Laptopul are o adresă IPv6, tunelul este ridicat peste IPv4 și totuși fiecare test IPv6 eșuează. Sau mai rău: testul reușește și traficul a ieșit pe calea furnizorului fără să intre vreodată în tunel. Ambele rezultate duc la o singură decizie lipsă: nimeni nu i-a dat routerului un prefix pe care să îl poată ruta către clienți. Parcurgerea căii de la client spre exterior descoperă ce piesă lipsește.

Începe acolo unde stă clientul

Uită-te la client înainte de a atinge serverul. ip -6 addr ar trebui să arate o adresă de tunel din pool, iar ip -6 route ar trebui să arate prefixul împins care indică dispozitivul de tunel. Când adresa există dar ruta nu, împingerea lipsește sau clientul a ignorat-o. Când nu există niciuna, serverul nu a alocat absolut nimic.

Apoi verifică ce crede clientul despre lumea exterioară. O rută implicită prin tunel revendică tot traficul IPv6, în timp ce o rută pentru 2000::/3 revendică doar unicast global. Ambele pot fi corecte și răspund la întrebări diferite despre scurgeri.

Un client fără nicio rută implicită IPv6 eșuează la fiecare test public, deși tunelul în sine este perfect sănătos. Este o lacună de politică, nu un tunel stricat.

Verifică poolul pe care serverul chiar îl poate ruta

Un server poate aloca doar dintr-un prefix pe care îl controlează cu adevărat. Dacă furnizorul deleagă un /56, rezervă un /64 pentru tunel și lasă restul pentru LAN. Acolo unde furnizorul predă pe WAN doar un /64 și nu rutează nimic mai departe, lasă prefixul LAN în pace și dă tunelului un interval local unic, acceptând că clienții nu vor avea ieșire globală.

Poolul și împingerea merg împreună. server-ipv6 2001:db8:80:10::/64 alocă adrese, iar push "route-ipv6 2000::/3" le spune clienților ce să trimită în tunel. Împingerea 2000::/3 acoperă unicastul global și lasă intervalele link-local și multicast în afara tunelului.

Scrie prefixul ales în registrul de implementare. Cine va schimba data viitoare predarea furnizorului trebuie să știe ce /64 ocupă deja tunelul.

Activează forwardingul pentru a doua familie

Forwardingul IPv4 nu implică forwarding IPv6. Setează net.ipv6.conf.all.forwarding=1 și oglindește tot ce permite deja politica FORWARD pentru IPv4. Pe un router a cărui lanț FORWARD aruncă implicit, un set de reguli lipsă arată exact ca un tunel mort.

Strângerea de mână reușește, clientul primește o adresă și nimic nu se întoarce. Adaugă reguli pentru ambele direcții și pentru segmentul WAN, pentru că un tunel care ajunge la LAN dar nu la internet eșuează al treilea test. După o încercare eșuată, uită-te la contoarele lanțului, pentru că o regulă care nu s-a potrivit niciodată este o problemă diferită de una care s-a potrivit și a aruncat.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Un efect secundar îi prinde pe cei care ajung să dea vina pe tunel. Activarea forwardingului face kernelul să sară peste configurarea adresei prin Router Advertisement dacă nu i se spune altfel, iar o rută implicită învățată astfel dispare odată cu ea. Fie fixezi o rută implicită explicită pe interfața WAN, fie setezi acolo accept_ra la 2 intenționat. După oricare schimbare, confirmă că routerul mai are o cale IPv6 utilizabilă spre exterior înainte de a testa din nou clienții.

Răspunde descoperirii vecinilor când partea de sus nu rutează

Echipamentul din amonte tratează uneori /64 delegat ca aparținând propriei legături și refuză să ruteze orice subprefix către cutia VPN. Când se întâmplă asta, ceva trebuie să răspundă solicitărilor vecinilor pentru fiecare adresă de client în parte.

OpenVPN expune adresa alocată unui hook client-connect, astfel încât intrările pot urma poolul real în locul unei liste întreținute manual. Hookul adaugă ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, iar un hook client-disconnect corespunzător îl elimină. Fără eliminare, tabelul proxy se învechește și un client ulterior poate moșteni o intrare pentru o adresă pe care nu a primit-o niciodată. Confirmă starea cu ip -6 neigh show proxy.

Tratează proxy-ul ca pe o soluție de ocolire. O rută statică pentru /64 tunelului îndreptată spre router supraviețuiește schimbărilor de clienți și nu are nevoie de niciun hook de shell privilegiat.

Urmează calea spre exterior, salt cu salt

Testează spre exterior în trei pași: mai întâi adresa de tunel a routerului, apoi un host din LAN și al treilea o destinație publică prin traceroute6. Poolul este dovedit de primul, forwardingul și firewallul LAN de al doilea, iar calea de întoarcere prin partea de sus de al treilea. Fiecare eșec îngustează căutarea la un singur dispozitiv în loc să redeschidă tot designul.

Urmărește MTU-ul tunelului, pentru că routerele IPv6 de pe cale nu fragmentează pentru tine. Un MTU prea mare apare ca eroare packet-too-big și TLS blocat în loc de un eșec curat. Setează-l explicit și testează cu o încărcătură aproape de limită.