IPv6 per un túnel OpenVPN: recorregut pel router de casa

L'ordinador portàtil té una adreça IPv6, el túnel funciona sobre IPv4 i, tot i així, totes les proves IPv6 fallen. Pitjor encara: la prova passa i el trànsit ha sortit pel camí del proveïdor sense entrar mai al túnel. Tots dos resultats remeten a una decisió que falta: ningú no ha donat al router un prefix que pugui encaminar cap als clients. Recórrer el camí des del client cap enfora descobreix quina peça falta.

Comença on és el client

Mira el client abans de tocar el servidor. ip -6 addr hauria de mostrar una adreça de túnel provinent del pool, i ip -6 route hauria de mostrar el prefix empès que apunta al dispositiu de túnel. Quan l'adreça hi és però no hi ha ruta, falta el push o el client l'ha ignorat. Quan no hi és cap de les dues, el servidor no ha assignat absolutament res.

Després comprova què creu el client sobre el món exterior. Una ruta per defecte pel túnel reclama tot el trànsit IPv6, mentre que una ruta per a 2000::/3 només reclama unicast global. Totes dues poden ser correctes i responen preguntes diferents sobre les fuites.

Un client sense cap ruta per defecte IPv6 falla totes les proves públiques mentre el túnel mateix és perfectament sa. Això és una mancança de política, no un túnel espatllat.

Comprova el pool que el servidor pot encaminar de debò

Un servidor només pot assignar adreces d'un prefix que controla de debò. Si el proveïdor delega un /56, reserva un /64 per al túnel i deixa la resta per a la LAN. Quan el proveïdor lliura un sol /64 a la WAN i no encamina res més, deixa el prefix de la LAN tranquil i dona al túnel un rang local únic, acceptant que els clients no tindran sortida global.

El pool i el push van junts. server-ipv6 2001:db8:80:10::/64 assigna adreces i push "route-ipv6 2000::/3" diu als clients què han d'enviar al túnel. Enviar 2000::/3 cobreix l'unicast global i deixa els rangs link-local i multicast fora del túnel.

Escriu el prefix triat al registre de desplegament. Qui canviï la cessió del proveïdor la propera vegada ha de saber quin /64 ja ocupa el túnel.

Activa el forwarding per a la segona família

El forwarding IPv4 no implica el forwarding IPv6. Defineix net.ipv6.conf.all.forwarding=1 i replica tot el que la política FORWARD d'IPv4 ja permet. En un router la cadena FORWARD del qual descarta per defecte, un conjunt de regles absent sembla exactament un túnel mort.

L'apretada de mans té èxit, el client rep una adreça i no torna res. Afegeix regles per a totes dues direccions i per al tram WAN, perquè un túnel que arriba a la LAN però no a internet falla la tercera prova. Revisa els comptadors de la cadena després d'un intent fallit, perquè una regla que mai no ha coincidit és un problema diferent d'una que ha coincidit i ha descartat.

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

Un efecte secundari enxampa qui acaba culpant el túnel. En activar el forwarding, el nucli s'estalvia la configuració d'adreça per Router Advertisement si no li dius el contrari, i una ruta per defecte apresa així desapareix amb ella. O fixa una ruta per defecte explícita a la interfície WAN, o posa-hi accept_ra a 2 expressament. Després de qualsevol dels dos canvis, confirma que el router encara té un camí IPv6 vàlid cap enfora abans de tornar a provar els clients.

Respon al descobriment de veïns quan l'extrem superior no encamina

L'equipament d'extrem superior de vegades tracta el /64 delegat com a propi del seu enllaç i es nega a encaminar cap subprefix cap a la caixa VPN. Quan passa això, alguna cosa ha de respondre les sol·licituds de veïnatge per a cada adreça de client individualment.

OpenVPN exposa l'adreça assignada a un hook client-connect, així les entrades poden seguir el pool real en lloc d'una llista mantinguda a mà. El hook afegeix ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, i un hook client-disconnect corresponent el treu. Sense aquesta retirada, la taula de proxy es queda desfasada i un client posterior pot heretar una entrada per a una adreça que mai no ha rebut. Confirma l'estat amb ip -6 neigh show proxy.

Tracta el proxying com un pedaç. Una ruta estàtica per al /64 del túnel apuntada al router sobreviu els canvis de clients i no necessita cap hook d'intèrpret amb privilegis.

Segueix el camí cap enfora, salt a salt

Prova cap enfora en tres passos: primer l'adreça de túnel del router, després un amfitrió de la LAN i tercer una destinació pública amb traceroute6. El pool el demostra el primer pas, el forwarding i el tallafoc de la LAN el segon, i el camí de tornada per l'extrem superior el tercer. Cada fallada estreny la cerca a un sol dispositiu en lloc de reobrir tot el disseny.

Vigila l'MTU del túnel, perquè els routers IPv6 del camí no fragmentaran per tu. Un MTU massa gran es manifesta com una error packet-too-big i un TLS encallat en lloc d'una fallada neta. Fixa'l explícitament i prova amb una càrrega prop del límit.