El mes passat dues persones em van demanar resultats oposats: una volia que la VPN cobrís IPv6 i l'altra volia que la impressora de l'oficina continués funcionant. Una sola ruta ::/0 no pot lliurar les dues coses per si sola. Si aquesta ruta pertany dins del túnel depèn de tres condicions, i la primera l'exclou per a la majoria de sortides comercials. Si la sortida no transporta IPv6, encaminar-hi la ruta per defecte amaga el vostre trànsit en un túnel que no té on enviar-lo.

Tres condicions decideixen la resposta

La ruta per defecte és una línia, ::/0, i encaixa amb qualsevol destinació IPv6 sense una ruta més específica (RFC 4291). Instal·lar-la és fàcil. Decidir si ho hauríeu de fer es redueix a tres condicions.

Condició u: la sortida a la qual us connecteu té IPv6 operatiu i està disposada a reenviar-lo. Condició dos: el vostre client pot mantenir un camí cap a l'extrem del túnel, que normalment és dins del rang que esteu a punt d'encaminar. Condició tres: podeu anomenar les destinacions IPv6 locals que han de quedar fora del túnel.

Cada condició falla a la seva manera, i per això endevinar costa una tarda sencera. Una condició u fallida us dona silenci i una taula d'encaminament que sembla correcta. Una condició dos fallida mata l'apretada de mans pocs segons després de començar. Una condició tres fallida deixa un túnel funcionant i un company descontent a la impressora.

What you seeDecision
Exit answers IPv6 probes, no local IPv6 devices to protectRoute ::/0 into the tunnel
Exit answers IPv6 probes, printer or NAS reachable by a global addressRoute ::/0, then give those prefixes a route of their own
Exit is IPv4-only inside the tunnelDo not route ::/0; block IPv6 on the client
Endpoint is reached over IPv6 and sits inside ::/0Install a host route for the endpoint first

La sortida transporta realment IPv6?

Una interfície de túnel amb una adreça IPv6 no demostra res sobre l'altre costat. Molts perfils comercials són només IPv4 a dins: el servidor us dona una adreça v4 i descarta tota la resta. Instal·leu-hi a sobre una ruta per defecte des de AllowedIPs i el nucli enviarà encantat IPv6 cap a una interfície que el seu parell no veu mai.

Proveu-ho des del client mentre el túnel és actiu. ping -6 -c 3 2001:4860:4860::8888 i ip -6 route get 2001:4860:4860::8888 responen preguntes diferents: si torna una resposta i quin dispositiu ha triat el nucli. Quan la segona anomena el vostre túnel i la primera no retorna res, el problema és la sortida, no la ruta.

Si gestioneu la sortida vosaltres mateixos, la prova del client pot passar i el camí encara pot acabar en un cul-de-sac. Confirmeu net.ipv6.conf.all.forwarding=1 a la passarel·la i que el seu tallafoc accepta paquets reenviats des del túnel. Un paquet correctament encaminat cap a una sortida que es nega a retransmetre sembla exactament un error d'encaminament des del costat del client.

Pot el client mantenir el camí cap a l'extrem?

Aquest és el cas que em va atrapar en un portàtil amb un extrem de WireGuard només IPv6. L'adreça de l'extrem és una adreça global corrent, així que cau dins de ::/0. Encamineu tot el prefix cap a la interfície i els paquets de l'apretada de mans es perseguiran ells mateixos dins del túnel que encara intenten construir. El túnel no s'aixeca mai, i res a la sortida del client no diu per què.

wg-quick ho resol a Linux. Deriva les rutes de AllowedIPs, les instal·la a la seva pròpia taula i afegeix una regla de política perquè el trànsit cap a l'extrem es resolgui primer per la taula principal: la regla suppress_prefixlength 0 que trobeu a ip -6 rule. Per això wg-quick up funciona allà on una ip -6 route add default dev wg0 escrita a mà us deixa fora de joc.

Comproveu tots dos estats amb ip -6 route get <endpoint-v6>, abans i després d'aixecar el túnel. Si la resposta passa al vostre dispositiu de túnel, heu eliminat el camí que el túnel necessita. Quan escriviu les rutes vosaltres mateixos, afegiu una ruta d'amfitrió per a l'extrem a través de la passarel·la original, o connecteu a l'extrem per IPv4 i deixeu IPv6 per a la càrrega útil.

Què ha de quedar fora del túnel?

Les rutes més específiques guanyen la ruta per defecte, així que un prefix enllaçat o un rang ULA amb ruta pròpia continua funcionant sense esforç extra. Aquesta és la raó silenciosa per la qual tantes instal·lacions IPv4 de túnel complet sobreviuen: els prefixos de la LAN són més específics que el defecte i no entren mai al túnel.

Es trenca quan un dispositiu local és abastable per una adreça global, cosa normal en una impressora a la qual el mateix encaminador ha donat un prefix públic, un NAS o un televisor. Aquestes adreces encaixen amb ::/0 i amb res més, així que es traslladen al túnel amb tota la resta i desapareixen.

Decidiu per destinació, no per protocol. Si dos o tres equips locals importen, doneu als seus prefixos una ruta per la interfície física o traieu-los del conjunt negociat. Si la llista no para de créixer, la resposta honesta és túnel dividit per a IPv6 amb una llista d'excepcions escrita, no una ruta per defecte que aneu pedaçant.

Si la resposta és no, bloquegeu-ho

Deixar IPv6 sense encaminar no és el mateix que deixar-lo tranquil. Un equip amb una ruta per defecte IPv6 operativa continua usant-la mentre el túnel transporta IPv4, així que el trànsit surt al costat de la VPN i tots els serveis que prefereixen IPv6 veuen la vostra adreça real. Això és una fuita, no un túnel dividit.

Trieu-ne una i anoteu quina heu triat. Encamineu la ruta per defecte i accepteu els compromisos anteriors, o desactiveu IPv6 mentre duri el túnel. Ometre el prefix de AllowedIPs no n'hi ha prou, perquè el sistema operatiu manté la seva pròpia ruta per defecte. A Linux la versió contundent és sysctl -w net.ipv6.conf.all.disable_ipv6=1; la versió fina deixa caure IPv6 fora del túnel amb una regla de tallafoc. Els clients de telèfon inclouen un commutador explícit de bloqueig d'IPv6 que fa la mateixa feina.

Verifiqueu-ho com una fuita

Aixequem el túnel i llegiu l'estat en lloc de confiar en el commutador. ip -6 route show default hauria de mostrar una sola ruta per defecte, i ip -6 route get per a una destinació fora de la vostra LAN hauria de nomenar el dispositiu de túnel. Repetiu-ho tot després d'una desconnexió: una ruta per defecte que sobreviu al túnel és l'error que buscàveu.

Després proveu l'altre sentit. Des d'un equip de la xarxa local, arribeu al client per la seva adreça IPv6 local. Si això deixa de funcionar, la condició tres no es va complir mai, digués el que digués la taula d'encaminament en aquell moment.

Escriviu el resultat on el trobarà la propera persona: quins prefixos queden locals, per què i què fa el client després d'una desconnexió. Dues línies en un runbook estalvien al proper enginyer de retrobar el bucle de l'extrem a mitjanit.

Articles relacionats