IPv6 skozi tunel OpenVPN: sprehod po domačem usmerjevalniku

Prenosnik ima naslov IPv6, tunel deluje prek IPv4, pa vendar vsak preizkus IPv6 spodleti. Ali še huje: preizkus uspe in promet je odšel po poti ponudnika, ne da bi kdaj vstopil v tunel. Oba izida se vrneta k eni manjkajoči odločitvi: nihče ni dal usmerjevalniku predpone, ki bi jo lahko usmerjal proti odjemalcem. Če prehodimo pot od odjemalca navzven, najdemo, kateri del manjka.

Začnite tam, kjer je odjemalec

Poglejte odjemalca, preden se dotaknete strežnika. ip -6 addr bi moral pokazati naslov tunela iz bazena, ip -6 route pa potisnjeno predpono, ki kaže na tunelsko napravo. Ko naslov je, poti pa ni, potiskanje manjka ali pa ga je odjemalec prezrl. Ko ni nobenega, strežnik ni dodelil prav ničesar.

Nato preverite, kaj odjemalec misli o zunanjem svetu. Privzeta pot skozi tunel zahteva ves promet IPv6, medtem ko pot za 2000::/3 zahteva samo globalni unicast. Obe sta lahko pravilni in odgovarjata na različna vprašanja o uhajanju.

Odjemalec brez kakršne koli privzete poti IPv6 spodleti na vsakem javnem preizkusu, čeprav je tunel sam popolnoma zdrav. To je vrzel v politiki, ne pokvarjen tunel.

Preverite bazen, ki ga strežnik resnično lahko usmerja

Strežnik lahko dodeljuje le iz predpone, ki jo resnično nadzoruje. Če ponudnik delegira /56, rezervirajte eno /64 za tunel, ostalo pa pustite za LAN. Kjer ponudnik na WAN preda samo eno /64 in ničesar več ne usmerja, pustite predpono LAN pri miru in dajte tunelu edinstven lokalni obseg, ob tem pa sprejmite, da odjemalci ne bodo imeli globalnega izhoda.

Bazen in potiskanje gresta skupaj. server-ipv6 2001:db8:80:10::/64 dodeljuje naslove, push "route-ipv6 2000::/3" pa odjemalcem pove, kaj naj pošiljajo v tunel. Potiskanje 2000::/3 pokrije globalni unicast in pusti obsege link-local ter multicast zunaj tunela.

Izbrano predpono zapišite v zapis o uvajanju. Kdor bo naslednjič spremenil predajo ponudnika, mora vedeti, katero /64 tunel že zaseda.

Vklopite posredovanje za drugo družino

Posredovanje IPv4 ne pomeni posredovanja IPv6. Nastavite net.ipv6.conf.all.forwarding=1 in preslikajte vse, kar politika FORWARD za IPv4 že dovoljuje. Na usmerjevalniku, katerega veriga FORWARD privzeto zavrže, je manjkajoč nabor pravil videti natanko kot mrtev tunel.

Rokovanje uspe, odjemalec dobi naslov in nazaj ne pride nič. Dodajte pravila za obe smeri in za krak WAN, ker tunel, ki doseže LAN, ne pa interneta, spodleti na tretjem preizkusu. Po neuspelem poskusu poglejte števce verige, ker je pravilo, ki se ni nikoli ujemalo, drugačen problem od tistega, ki se je ujemalo in zavrglo.

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

En stranski učinek ujame ljudi, ki na koncu krivijo tunel. Vklop posredovanja povzroči, da jedro preskoči konfiguracijo naslova prek Router Advertisement, razen če mu rečete drugače, in privzeta pot, naučena tako, izgine z njo. Bodisi pripnite izrecno privzeto pot na vmesniku WAN bodisi tam zavestno nastavite accept_ra na 2. Po vsaki spremembi potrdite, da ima usmerjevalnik še vedno uporabno pot IPv6 navzven, preden znova preizkusite odjemalce.

Odgovorite na odkrivanje sosedov, ko zgornja stran ne usmerja

Oprema višje v omrežju včasih obravnava delegirano /64 kot del svojega lastnega voda in noče usmerjati nobene podpredpone v škatlo VPN. Ko se to zgodi, mora nekaj odgovoriti na zahteve sosedov za vsak naslov odjemalca posebej.

OpenVPN izpostavi dodeljeni naslov kljuki client-connect, zato lahko vnosi sledijo pravemu bazenu namesto ročno vzdrževanega seznama. Kljuka doda ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, ustrezna kljuka client-disconnect pa ga odstrani. Brez odstranitve tabela proxy zastara in poznejši odjemalec lahko podeduje vnos za naslov, ki ga ni nikoli prejel. Stanje potrdite s ip -6 neigh show proxy.

Proxying obravnavajte kot obhod. Statična pot za /64 tunela, usmerjena na usmerjevalnik, preživi menjave odjemalcev in ne potrebuje nobene privilegirane kljuke lupine.

Sledite poti navzven, skok za skokom

Preizkusite navzven v treh korakih: najprej naslov tunela usmerjevalnika, nato gostitelj v LAN in tretje javni cilj prek traceroute6. Bazen dokaže prvi, posredovanje in požarni zid LAN drugi, povratno pot prek zgornje strani pa tretji. Vsaka napaka zoži iskanje na eno napravo, namesto da bi znova odprla celotno zasnovo.

Pazite na MTU tunela, ker usmerjevalniki IPv6 na poti ne bodo drobili namesto vas. Prevelik MTU se pokaže kot napaka packet-too-big in zataknjen TLS, ne kot čista napaka. Nastavite ga izrecno in preizkusite z obremenitvijo blizu meje.