De laptop hat in IPv6-adres, de tunnel is oer IPv4 omheech, en dochs mislearret elke IPv6-test. Of slimmer: de test slagget en it ferkear gie fia it paad fan de provider nei bûten sûnder ea yn de tunnel te kommen. Beide útkomsten geane werom op ien ûntbrekkend beslút: nimmen joech de router in foarheaksel dat er nei de klanten routearje koe. Wa't it paad fan de klient nei bûten rint, fynt hokker stik ûntbrekt.

Begjin dêr't de klient sit

Sjoch nei de klient foardatst de tsjinner oanrekest. ip -6 addr heart in tunneladres út de pool te toanen, en ip -6 route heart it trochstjoerde foarheaksel te toanen dat nei it tunnelapparaat wiist. As it adres der is mar de rûte net, ûntbrekt de push of hat de klient dy negearre. As gjin fan beide der is, hat de tsjinner hielendal neat tawiisd.

Kontrolearje dan wat de klient oer de bûtenwrâld tinkt. In standertrûte oer de tunnel easket al it IPv6-ferkear, wylst in rûte foar 2000::/3 allinnich globale unicast easket. Beide kinne goed wêze, en se beantwurdzje ferskillende fragen oer lekken.

In klient sûnder hokker IPv6-standertrûte dan ek mislearret elke iepenbiere test wylst de tunnel sels folslein sûn is. Dat is in gat yn it belied, net in stikken tunnel.

Kontrolearje de pool dy't de tsjinner wier routearje kin

In tsjinner kin allinnich tawize út in foarheaksel dat er wier kontrolearret. As de provider in /56 delegearret, reservearje dan ien /64 foar de tunnel en lit de rest foar it LAN. Wêr't de provider op de WAN mar ien /64 oerdraacht en fierder neat routearret, lit dan it LAN-foarheaksel gewurde en jou de tunnel in unyk lokaal berik, en akseptearje dat de klanten gjin globale útgong hawwe.

De pool en de push hearre byinoar. server-ipv6 2001:db8:80:10::/64 wiist adressen ta, en push "route-ipv6 2000::/3" fertelt de klanten wat se de tunnel yn stjoere moatte. 2000::/3 trochstjoere dekt globale unicast en lit link-local- en multicast-berikken bûten de tunnel.

Skriuw it keazen foarheaksel yn it ynstallaasjeprotokol. Wa't de folgjende kear de provider-oerdracht feroaret, moat witte hokker /64 de tunnel al beset.

Sette trochstjoering oan foar de twadde famylje

IPv4-trochstjoering betsjut net IPv6-trochstjoering. Stel net.ipv6.conf.all.forwarding=1 yn en spegelje alles wat it IPv4-FORWARD-belied al tastiet. Op in router waans FORWARD-ketting standert fuortsmyt, sjocht in ûntbrekkende regelset der krekt út as in deade tunnel.

De hânskud slagget, de klient krijt in adres, en der komt neat werom. Foegje regels ta foar beide rjochtingen en foar it WAN-skonk, want in tunnel dy't it LAN berikt mar net it ynternet, mislearret de tredde test. Sjoch nei in mislearre poging nei de tellers fan de ketting, want in regel dy't nea oerienkaam is in oar probleem as ien dy't oerienkaam en fuortsmiten hat.

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

Ien bywurking fangt de minsken dy't úteinlik de tunnel de skuld jouwe. Trochstjoering oansette lit de kernel de adreskonfiguraasje fia Router Advertisement oerslaan, útsein as jo oars sizze, en in standertrûte dy't sa leard is ferdwynt dêrmei. Of pin in eksplisite standertrûte op 'e WAN-interface fêst, of set accept_ra dêr mei opsetsin op 2. Befêstigje nei beide feroarings dat de router noch in brûkber IPv6-paad nei bûten hat foardatst de klanten wer testest.

Antwurdzje op buorman-ûntdekking as de boppestream net routearret

Boppestreamapparatuer behannelet it delegearre /64 soms as hearrend by syn eigen keppeling en wegeret in subfoarheaksel nei de VPN-doaze te routearjen. As dat bart, moat eat de buorman-fersiken foar elk klientadres apart beantwurdzje.

OpenVPN stelt it tawiisde adres bleat oan in client-connect-heak, sadat ynskriuwings de echte pool folgje kinne ynstee fan in list dy't mei de hân byholden wurdt. De heak foeget ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 ta, en in oerienkommende client-disconnect-heak hellet it wer fuort. Sûnder dat fuortheljen wurdt de proxy-tabel ferâldere en in lettere klient kin in ynskriuwing erve foar in adres dat er nea krigen hat. Befêstigje de tastân mei ip -6 neigh show proxy.

Besjoch it proxying as in needoplossing. In statyske rûte foar de tunnel-/64 rjochte op 'e router oerlibbet klintferoarings en hat hielendal gjin privilezjeare shell-heak nedich.

Folgje it paad nei bûten, hop foar hop

Test nei bûten yn trije stappen: earst it tunneladres fan de router, dan in LAN-host, en tredde in iepenbier bestimming fia traceroute6. De pool wurdt bewiisd troch de earste, trochstjoering en de LAN-firewall troch de twadde, en it werompaad fia de boppestream troch de tredde. Eltse mislearring ferkringt it sykjen ta ien apparaat ynstee fan it hiele ûntwerp wer iepen te meitsjen.

Let op de tunnel-MTU, want de IPv6-routers op it paad sille net foar dy fragmintearje. In te grutte MTU docht bliken as in packet-too-big-flater en stilstienende TLS ynstee fan in skjinne mislearring. Set it eksplisyt en test mei in lading tichtby de limyt.

Relatearre artikelen