IPv6 deur 'n OpenVPN-tonnel: 'n stap-vir-stap vir die tuisroeteerder

Die skootrekenaar het 'n IPv6-adres, die tonnel is oor IPv4 op, en tog misluk elke IPv6-toets. Erger nog: die toets slaag en die verkeer het via die ISP-pad uitgegaan sonder om ooit die tonnel binne te gaan. Albei uitkomste kom terug op een ontbrekende beslissing: niemand het die roeteerder 'n voorvoegsel gegee wat hy na die kliënte kon roeteer nie. Wie die pad van die kliënt af na buite volg, vind watter stuk ontbreek.

Begin waar die kliënt sit

Kyk na die kliënt voordat jy aan die bediener raak. ip -6 addr behoort 'n tonneladres uit die poel te wys, en ip -6 route behoort die gestuurde voorvoegsel te wys wat na die tonneltoestel wys. Wanneer die adres daar is maar geen roete nie, ontbreek die push of die kliënt het dit geïgnoreer. Wanneer nie een van die twee daar is nie, het die bediener glad niks toegewys nie.

Kyk dan wat die kliënt oor die buitewêreld glo. 'n Standaardroete oor die tonnel eis alle IPv6-verkeer, terwyl 'n roete vir 2000::/3 net globale unicast eis. Albei kan korrek wees, en hulle beantwoord verskillende vrae oor lekkasie.

'n Kliënt sonder enige IPv6-standaard misluk elke openbare toets terwyl die tonnel self heeltemal gesond is. Dit is 'n leemte in die beleid en nie 'n stukkende tonnel nie.

Kontroleer die poel wat die bediener werklik kan roeteer

'n Bediener kan net uit 'n voorvoegsel toewys wat hy werklik beheer. As die ISP 'n /56 delegeer, reserveer een /64 vir die tonnel en laat die res vir die LAN. Waar die ISP net een /64 op die WAN oorhandig en niks verder roeteer nie, laat die LAN-voorvoegsel alleen en gee die tonnel 'n unieke plaaslike reeks, met die aanvaarding dat die kliënte geen globale uitgang sal hê nie.

Die poel en die push hoort bymekaar. server-ipv6 2001:db8:80:10::/64 wys adresse toe, en push "route-ipv6 2000::/3" sê vir die kliënte wat hulle in die tonnel moet stuur. As jy 2000::/3 stuur, dek dit globale unicast en laat link-local- en multicast-reekse buite die tonnel.

Skryf die gekose voorvoegsel in die ontplooiingsrekord. Wie volgende die ISP-oordrag verander, moet weet watter /64 die tonnel reeds beset.

Skakel deurstuur vir die tweede familie aan

IPv4-deurstuur beteken nie IPv6-deurstuur nie. Stel net.ipv6.conf.all.forwarding=1 en spieël alles wat die IPv4-FORWARD-beleid reeds toelaat. Op 'n roeteerder wie se FORWARD-ketting by verstek laat val, lyk 'n ontbrekende reëlstel presies soos 'n dooie tonnel.

Die handdruk slaag, die kliënt kry 'n adres, en niks kom terug nie. Voeg reëls by vir albei rigtings en vir die WAN-been, want 'n tonnel wat die LAN bereik maar nie die internet nie, druip die derde toets. Kyk ná 'n mislukte poging na die kettingtellers, want 'n reël wat nooit gepas het nie, is 'n ander probleem as een wat gepas en laat val het.

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

Een newe-effek vang mense wat uiteindelik die tonnel blameer. As jy deurstuur aanskakel, slaan die kernel die adreskonfigurasie per routeradvertensie oor tensy jy anders sê, en 'n standaardroete wat so geleer is, verdwyn saam daarmee. Óf pen 'n eksplisiete standaardroete op die WAN-koppelvlak vas, óf stel accept_ra doelbewus op 2 daar. Bevestig ná albei veranderinge dat die roeteerder nog 'n bruikbare IPv6-pad na buite het voordat jy die kliënte weer toets.

Antwoord buurontdekking wanneer die opstroom nie wil roeteer nie

Opstroomtoerusting beskou die gedelegeerde /64 soms as deel van sy eie skakel en weier om enige subvoorvoegsel na die VPN-boks te roeteer. Wanneer dit gebeur, moet iets die buurman-navrae vir elke kliëntadres afsonderlik beantwoord.

OpenVPN stel die toegewysde adres aan 'n client-connect-haak bloot, sodat inskrywings die werklike poel kan volg in plaas van 'n lys wat met die hand bygehou word. Die haak voeg ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 by, en 'n bypassende client-disconnect-haak verwyder dit weer. Sonder die verwydering word die proxy-tabel verouderd, en 'n latere kliënt kan 'n inskrywing erf vir 'n adres wat hy nooit gekry het nie. Bevestig die toestand met ip -6 neigh show proxy.

Beskou die proxy-werk as 'n noodoplossing. 'n Statiese roete vir die tonnel-/64 wat na die roeteerder wys, oorleef kliëntwisseling en het glad geen bevoorregte shell-haak nodig nie.

Volg die pad na buite, een hop op 'n slag

Toets na buite in drie stappe: eerste die roeteerder se tonneladres, tweede 'n LAN-gasheer, en derde 'n openbare bestemming deur traceroute6. Die poel word deur die eerste bewys, deurstuur en die LAN-brandmuur deur die tweede, en die opstroom-terugpad deur die derde. Elke mislukking vernou die soektog na een toestel in plaas daarvan om die hele ontwerp oop te maak.

Let op die tonnel-MTU, want die IPv6-roeteerders op die pad sal nie vir jou fragmenteer nie. 'n Te groot MTU wys as 'n packet-too-big-fout en stilstaande TLS eerder as 'n skoon mislukking. Stel dit eksplisiet en toets met 'n nutslading naby die limiet.