IPv6 per OpenVPN tunelį: namų maršrutizatoriaus apžvalga

Nešiojamasis kompiuteris turi IPv6 adresą, tunelis pakeltas per IPv4, bet kiekvienas IPv6 testas nepavyksta. Arba dar blogiau: testas pavyksta ir srautas išėjo tiekėjo keliu taip ir nepatekęs į tunelį. Abi baigtys veda prie vieno trūkstamo sprendimo: niekas nedavė maršrutizatoriui priešdėlio, kurį jis galėtų maršrutizuoti klientų link. Einant keliu nuo kliento į išorę paaiškėja, kurios dalies trūksta.

Pradėkite nuo tos vietos, kur yra klientas

Pažiūrėkite į klientą prieš liesdami serverį. ip -6 addr turėtų rodyti tunelio adresą iš baseino, o ip -6 route – į tunelio įrenginį nukreiptą stumiamą priešdėlį. Kai adresas yra, o maršruto nėra, stūmimo trūksta arba klientas jį ignoravo. Kai nėra nė vieno, serveris nieko visiškai nepaskyrė.

Tada patikrinkite, ką klientas mano apie išorinį pasaulį. Numatytasis maršrutas per tunelį reikalauja viso IPv6 srauto, o maršrutas 2000::/3 – tik globalaus unicast. Abu gali būti teisingi, ir jie atsako į skirtingus nutekėjimo klausimus.

Klientas, neturintis jokio numatytojo IPv6 maršruto, nepavyksta kiekviename viešame teste, nors pats tunelis visiškai sveikas. Tai politikos spraga, o ne sugadintas tunelis.

Patikrinkite baseiną, kurį serveris iš tikrųjų gali maršrutizuoti

Serveris gali skirti tik iš priešdėlio, kurį iš tikrųjų kontroliuoja. Jei tiekėjas deleguoja /56, rezervuokite vieną /64 tuneliui, o likusį palikite LAN. Kai tiekėjas WAN sąsajoje perduoda tik vieną /64 ir daugiau nieko nemaršrutizuoja, palikite LAN priešdėlį ramybėje ir duokite tuneliui unikų vietinį diapazoną, priimdami, kad klientai neturės globalios išėjimo.

Baseinas ir stūmimas eina kartu. server-ipv6 2001:db8:80:10::/64 skiria adresus, o push "route-ipv6 2000::/3" pasako klientams, ką siųsti į tunelį. Stumiant 2000::/3 padengiamas globalus unicast, o link-local ir multicast diapazonai lieka už tunelio.

Įrašykite pasirinktą priešdėlį į diegimo įrašą. Kas kitą kartą keis tiekėjo perdavimą, turi žinoti, kurį /64 tunelis jau užima.

Įjunkite persiuntimą antrajai šeimai

IPv4 persiuntimas nereiškia IPv6 persiuntimo. Nustatykite net.ipv6.conf.all.forwarding=1 ir atspindėkite viską, ką IPv4 FORWARD politika jau leidžia. Maršrutizatoriuje, kurio FORWARD grandinė pagal nutylėjimą išmeta, trūkstamas taisyklių rinkinys atrodo lygiai kaip negyvas tunelis.

Rankos paspaudimas pavyksta, klientas gauna adresą, o atgal nieko negrįžta. Pridėkite taisykles abiem kryptims ir WAN atkarpai, nes tunelis, kuris pasiekia LAN, bet ne internetą, nepavyksta trečiame teste. Po nepavykusio bandymo pažiūrėkite į grandinės skaitiklius, nes taisyklė, kuri niekada nesutapo, yra kita problema nei ta, kuri sutapo ir išmetė.

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

Vienas šalutinis poveikis pagauna tuos, kurie galiausiai kaltina tunelį. Įjungus persiuntimą, branduolys praleidžia adreso konfigūravimą per Router Advertisement, jei nepasakysite kitaip, ir taip išmoktas numatytasis maršrutas dingsta kartu su juo. Arba prisekite aiškų numatytąjį maršrutą WAN sąsajoje, arba ten sąmoningai nustatykite accept_ra į 2. Po bet kurio pakeitimo patvirtinkite, kad maršrutizatorius vis dar turi tinkamą IPv6 kelią į išorę, prieš vėl testuodami klientus.

Atsakykite į kaimynų aptikimą, kai viršutinė dalis nemaršrutizuoja

Viršutinė įranga kartais laiko deleguotą /64 priklausančiu jos pačios jungčiai ir atsisako maršrutizuoti bet kokį popriešdėlį į VPN dėžę. Kai taip nutinka, kažkas turi atsakyti į kaimynų užklausas kiekvienam kliento adresui atskirai.

OpenVPN atskleidžia paskirtą adresą client-connect kabliui, todėl įrašai gali sekti tikrą baseiną, o ne rankiniu būdu prižiūrimą sąrašą. Kablys prideda ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, o atitinkamas client-disconnect kablys jį pašalina. Nepašalinus proxy lentelė sensta ir vėlesnis klientas gali paveldėti įrašą adresui, kurio niekada negavo. Patvirtinkite būseną naudodami ip -6 neigh show proxy.

Traktuokite proxy kaip apėjimo sprendimą. Statinis maršrutas tunelio /64, nukreiptas į maršrutizatorių, atlaiko klientų kaitą ir visiškai nereikalauja privilegijuoto shell kablio.

Sekite kelią į išorę, šuolis po šuolio

Testuokite į išorę trimis žingsniais: pirmiausia maršrutizatoriaus tunelio adresas, po to LAN mazgas ir trečia – viešas tikslas per traceroute6. Baseiną įrodo pirmasis, persiuntimą ir LAN užkardą antrasis, o grįžtamąjį kelią per viršutinę dalį trečiasis. Kiekviena nesėkmė susiaurina paiešką iki vieno įrenginio, o ne atveria visą dizainą iš naujo.

Stebėkite tunelio MTU, nes IPv6 maršrutizatoriai kelyje už jus neskaidys. Per didelis MTU pasirodo kaip packet-too-big klaida ir sustojęs TLS, o ne kaip švarus nepavykimas. Nustatykite jį aiškiai ir testuokite su apkrova arti ribos.