IPv6 caur OpenVPN tuneli: mājas maršrutētāja apskats

Klēpjdatoram ir IPv6 adrese, tunelis ir pacelts virs IPv4, un tomēr katrs IPv6 tests neizdodas. Vai vēl ļaunāk: tests izdodas un satiksme izgāja pa pakalpojumu sniedzēja ceļu, tā arī nekad neiekļūstot tunelī. Abi iznākumi ved pie viena trūkstoša lēmuma: neviens nedevēja maršrutētājam prefiksu, ko tas varētu maršrutēt uz klientiem. Ejot pa ceļu no klienta uz āru, atklājas, kura daļa trūkst.

Sāciet tur, kur atrodas klients

Apskatiet klientu, pirms aiztiekat serveri. ip -6 addr jārāda tuneļa adrese no baseina, un ip -6 route jārāda uz tunela ierīci vērstais aizstumtais prefikss. Kad adrese ir, bet ceļa nav, aizstūmšana trūkst vai klients to ignorēja. Kad nav neviena, serveris vispār neko nepiešķīra.

Pēc tam pārbaudiet, ko klients domā par ārējo pasauli. Noklusējuma maršruts caur tuneli pieprasa visu IPv6 satiksmi, savukārt maršruts uz 2000::/3 pieprasa tikai globālo unicast. Abi var būt pareizi, un tie atbild uz dažādiem jautājumiem par noplūdi.

Klientam bez jebkāda IPv6 noklusējuma maršruta neizdodas katrs publiskais tests, lai gan pats tunelis ir pilnīgi vesels. Tā ir politikas nepilnība, nevis salauzts tunelis.

Pārbaudiet baseinu, ko serveris patiešām var maršrutēt

Serveris var piešķirt tikai no prefiksa, ko tas patiešām kontrolē. Ja pakalpojumu sniedzējs deleģē /56, atstājiet vienu /64 tunelim un pārējo LAN. Kur sniedzējs WAN pārraida tikai vienu /64 un vairāk neko nemaršrutē, atstājiet LAN prefiksu mierā un piešķiriet tunelim unikālu lokālu diapazonu, pieņemot, ka klientiem nebūs globālas izejas.

Baseins un aizstūmšana iet kopā. server-ipv6 2001:db8:80:10::/64 piešķir adreses, un push "route-ipv6 2000::/3" pasaka klientiem, ko sūtīt tunelī. 2000::/3 aizstūmšana aptver globālo unicast un atstāj link-local un multicast diapazonus ārpus tuneļa.

Ierakstiet izvēlēto prefiksu izvietošanas ierakstā. Nākamajam, kas mainīs sniedzēja nodošanu, jāzina, kuru /64 tunelis jau aizņem.

Ieslēdziet pāradresāciju otrajai saimei

IPv4 pāradresācija nenozīmē IPv6 pāradresāciju. Iestatiet net.ipv6.conf.all.forwarding=1 un atspoguļojiet visu, ko IPv4 FORWARD politika jau atļauj. Maršrutētājā, kura FORWARD ķēde pēc noklusējuma atmet, trūkstošs noteikumu kopums izskatās tieši kā miris tunelis.

Rokasspiediens izdodas, klients saņem adresi, un atpakaļ nekas nenāk. Pievienojiet noteikumus abiem virzieniem un WAN posmam, jo tunelis, kas sasniedz LAN, bet ne internetu, neiztur trešo testu. Pēc neveiksmīga mēģinājuma apskatiet ķēdes skaitītājus, jo noteikums, kas nekad nav sakritis, ir cita problēma nekā tas, kas sakrita un atmeta.

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

Viens blakusefekts noķer tos, kas galu galā vaino tuneli. Ieslēdzot pāradresāciju, kodols izlaiž adreses konfigurāciju ar Router Advertisement, ja vien netiek teikts citādi, un tā apgūtais noklusējuma maršruts pazūd kopā ar to. Vai nu piespraudiet skaidru noklusējuma maršrutu WAN saskarnē, vai tur apzināti iestatiet accept_ra uz 2. Pēc jebkuras izmaiņas pārliecinieties, ka maršrutētājam joprojām ir lietojams IPv6 ceļš uz āru, pirms atkal testējat klientus.

Atbildiet uz kaimiņu atklāšanu, kad augšpuse nemaršrutē

Augšpuses aprīkojums dažkārt uzskata deleģēto /64 par savas saites daļu un atsakās maršrutēt jebkuru apakšprefiksu uz VPN kasti. Kad tas notiek, kaut kam ir jāatbild uz kaimiņu pieprasījumiem par katru klienta adresi atsevišķi.

OpenVPN atklāj piešķirto adresi client-connect āķim, tāpēc ieraksti var sekot īstajam baseinam, nevis ar roku uzturētam sarakstam. Āķis pievieno ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, un atbilstošs client-disconnect āķis to noņem. Bez noņemšanas proxy tabula novecojas un vēlāks klients var mantot ierakstu adresei, ko tas nekad nesaņēma. Apstipriniet stāvokli ar ip -6 neigh show proxy.

Uzskatiet proxy par apietu risinājumu. Statisks maršruts tuneļa /64, kas vērsts uz maršrutētāju, pārdzīvo klientu maiņu un vispār neprasa priviliģētu čaulas āķi.

Sekojiet ceļam uz āru, lēciens pa lēcienam

Pārbaudiet uz āru trīs soļos: vispirms maršrutētāja tuneļa adresi, pēc tam LAN resursdatoru un trešo publisku galamērķi ar traceroute6. Baseinu pierāda pirmais, pāradresāciju un LAN ugunsmūri otrais, un atgriešanās ceļu pa augšpusi trešais. Katra neveiksme sašaurina meklēšanu līdz vienai ierīcei, nevis atver visu dizainu no jauna.

Sekojiet tuneļa MTU, jo IPv6 maršrutētāji ceļā nesadrumstalos jūsu vietā. Pārāk liels MTU izpaužas kā packet-too-big kļūda un iesprūdis TLS, nevis tīra neveiksme. Iestatiet to skaidri un pārbaudiet ar slodzi tuvu robežai.