IPv6 tra OpenVPN-tunelo: trairo de hejma enkursigilo

La tekkomputilo havas IPv6-adreson, la tunelo funkcias super IPv4, kaj tamen ĉiu IPv6-testo malsukcesas. Aŭ pli malbone: la testo sukcesas kaj la trafiko eliris laŭ la ISP-vojo sen iam eniri la tunelon. Ambaŭ rezultoj devenas de unu mankanta decido: neniu donis al la enkursigilo prefikson, kiun ĝi povus enkursigi al la klientoj. Paŝi la vojon de la kliento eksteren trovas, kiu peco mankas.

Komencu tie, kie sidas la kliento

Rigardu la klienton antaŭ ol tuŝi la servilon. ip -6 addr devus montri tunelan adreson el la naĝejo, kaj ip -6 route devus montri la puŝitan prefikson direktitan al la tunela aparato. Kiam la adreso estas sed la vojo ne, la puŝo mankas aŭ la kliento ignoris ĝin. Kiam mankas ambaŭ, la servilo tute nenion atribuis.

Poste kontrolu, kion la kliento kredas pri la ekstera mondo. Defaŭlta vojo tra la tunelo postulas la tutan IPv6-trafikon, dum vojo por 2000::/3 postulas nur tutmondan unicast. Ambaŭ povas esti ĝustaj, kaj ili respondas malsamajn demandojn pri likado.

Kliento sen iu ajn defaŭlta IPv6-vojo malsukcesas ĉiun publikan teston, kvankam la tunelo mem estas tute sana. Tio estas manko en la politiko, ne rompita tunelo.

Kontrolu la naĝejon, kiun la servilo vere povas enkursigi

Servilo povas atribui nur el prefikso, kiun ĝi vere kontrolas. Se la ISP delegas /56, rezervu unu /64 por la tunelo kaj lasu la reston por la LAN. Kie la ISP transdonas nur unu /64 sur la WAN kaj plu nenion enkursigas, lasu la LAN-prefikson trankvila kaj donu al la tunelo unikan lokan intervalon, akceptante ke la klientoj ne havos tutmondan eliron.

La naĝejo kaj la puŝo apartenas kune. server-ipv6 2001:db8:80:10::/64 atribuas adresojn, kaj push "route-ipv6 2000::/3" diras al la klientoj, kion sendi en la tunelon. Puŝi 2000::/3 kovras tutmondan unicast kaj lasas link-local kaj multicast intervalojn ekster la tunelo.

Skribu la elektitan prefikson en la surlokigan protokolon. Kiu sekve ŝanĝos la ISP-transdonon, devas scii, kiun /64 la tunelo jam okupas.

Ŝaltu plusendadon por la dua familio

IPv4-plusendado ne implicas IPv6-plusendadon. Agordu net.ipv6.conf.all.forwarding=1 kaj spegulu ĉion, kion la IPv4-FORWARD-politiko jam permesas. Sur enkursigilo, kies FORWARD-ĉeno defaŭlte forĵetas, mankanta regularo aspektas ĝuste kiel morta tunelo.

La manpremo sukcesas, la kliento ricevas adreson, kaj nenio revenas. Aldonu regulojn por ambaŭ direktoj kaj por la WAN-kruro, ĉar tunelo, kiu atingas la LAN sed ne la interreton, malsukcesas la trian teston. Post malsukcesa provo rigardu la kalkulilojn de la ĉeno, ĉar regulo, kiu neniam kongruis, estas alia problemo ol unu, kiu kongruis kaj forĵetis.

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

Unu kromefiko kaptas la homojn, kiuj finfine kulpas la tunelon. Ŝalti plusendadon igas la kernon preterlasi adresan agordon per Router Advertisement, se vi ne diras alie, kaj defaŭlta vojo lernita tiel malaperas kun ĝi. Aŭ fiksu eksplicitan defaŭltan vojon sur la WAN-interfaco, aŭ intence agordu accept_ra al 2 tie. Post ambaŭ ŝanĝoj konfirmu, ke la enkursigilo ankoraŭ havas uzeblan IPv6-vojon eksteren antaŭ ol retesti la klientojn.

Respondu al najbara malkovro, kiam la supraĵo ne enkursigas

Supra aparataro foje traktas la delegitan /64 kiel apartenantan al sia propra ligilo kaj rifuzas enkursigi iun subprefikson al la VPN-skatolo. Kiam tio okazas, io devas respondi al najbaraj petoj por ĉiu klienta adreso aparte.

OpenVPN elmontras la atribuitan adreson al client-connect-hoko, do enskriboj povas sekvi la veran naĝejon anstataŭ permane prizorgatan liston. La hoko aldonas ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, kaj kongrua client-disconnect-hoko forigas ĝin. Sen la forigo la prokura tabelo malaktualiĝas kaj posta kliento povas heredi enskribon por adreso, kiun ĝi neniam ricevis. Konfirmu la staton per ip -6 neigh show proxy.

Traktu la prokuraĵon kiel provizoran solvon. Statika vojo por la tunela /64 direktita al la enkursigilo postvivas klientajn ŝanĝojn kaj tute ne bezonas privilegian ŝel-hokon.

Sekvu la vojon eksteren, salto post salto

Testu eksteren en tri paŝoj: unue la tunelan adreson de la enkursigilo, due LAN-gastiganton, kaj trie publikan celon per traceroute6. La naĝejon pruvas la unua, plusendadon kaj la LAN-fajroŝirmilon la dua, kaj la revenan vojon tra la supraĵo la tria. Ĉiu malsukceso mallarĝigas la serĉon al unu aparato anstataŭ remalfermi la tutan dezajnon.

Atentu la tunelan MTU, ĉar la IPv6-enkursigiloj sur la vojo ne fragmentos por vi. Tro granda MTU montriĝas kiel packet-too-big-eraro kaj haltinta TLS anstataŭ pura malsukceso. Agordu ĝin eksplice kaj testu per utilŝarĝo proksima al la limo.