Dividir el vostre /64 no encamina IPv6 cap als clients VPN

El client mostra una adreça IPv6 global, l'apretada de mans s'ha completat i no torna res d'Internet. La configuració de l'agrupació sembla correcta perquè ho és; l'adreça és vàlida i el túnel la transporta. El que falla és el lliurament, i el lliurament depèn d'una decisió presa més amunt del servidor VPN que cap configuració del costat del client pot influir.

El mite: una part del vostre /64 ja és abastable

La història és atractiva: el servidor té un /64 públic, partiu-lo per la meitat, doneu l'altra meitat a l'agrupació VPN i aquests clients ja són a Internet. Dividir el prefix sí que assigna adreces sense col·lisions. No canvia com la xarxa upstream decideix on ha d'anar un paquet destinat a una d'aquestes adreces.

IPv6 no té cap capa de traducció per defecte on recolzar-se, així que el camí de tornada ha d'existir com a encaminament o com a lliurament a nivell d'enllaç. Un paquet adreçat a l'adreça de túnel d'un client arriba al router upstream, i aquest router pren una decisió de reenviament a partir de la seva pròpia taula. Si la taula apunta a l'enllaç físic, el paquet hi va, independentment del que cregui el vostre servidor VPN.

Aquesta és tota la fallada: la direcció d'anada funciona perquè el vostre servidor l'envia, i la direcció de tornada mor a un salt de distància perquè l'upstream mai no va saber que el client existeix.

Què requereix realment el lliurament a l'enllaç

Quan l'upstream considera que tot el /64 és a l'enllaç físic, resol cada adreça de destinació amb descobriment de veïns. Envia una sol·licitud en aquell enllaç i espera que el propietari de l'adreça respongui. Un client VPN darrere d'un túnel no és en aquell enllaç i no pot respondre, així que la sol·licitud queda sense resposta i el paquet es descarta.

Retallar un /65 no canvia aquesta expectativa. L'upstream continua tractant el rang com a enllaç, perquè l'única cosa que li faria canviar d'opinió és una ruta o un proxy que respongui en nom del client. Cap de les dues apareix perquè hàgiu editat una configuració VPN. Aquest buit és la raó per la qual una agrupació pot funcionar perfectament entre els seus propis clients i tot i així ser inabastable des de qualsevol altre lloc.

El descobriment de veïns per proxy és el mecanisme que pot connectar els dos móns. La passarel·la respon les sol·licituds de les adreces de client concretes que posseeix i reenvia el trànsit al túnel. Funciona, i s'ha d'abastar exactament a aquestes adreces amb un cicle de vida que segueixi l'agrupació, perquè respondre per una adreça que ja no serveix converteix el trànsit d'algú altre en un forat negre. Alguns upstreams no acceptaran respostes de proxy que no esperaven, així que aquest disseny també necessita l'acord del proveïdor.

Què requereix el lliurament encaminat

El disseny més net és una assignació que l'upstream encamini realment cap a la vostra passarel·la. Pot ser un prefix delegat o una ruta estàtica per a un bloc més petit, i el requisit és el mateix en tots dos casos: la taula de l'upstream ha d'apuntar al vostre servidor per al rang de clients. Aleshores el trànsit de tornada arriba a la passarel·la i la passarel·la el reenvia al túnel.

El lliurament encaminat elimina del tot la qüestió del descobriment de veïns, i per això val la pena demanar-lo al proveïdor abans de construir res enginyós. Demaneu la ruta per escrit i confirmeu que el salt següent és l'adreça que l'upstream pot assolir realment.

Tots dos dissenys encara necessiten l'encaminament IPv6 habilitat a la passarel·la i regles de tallafoc que permetin el flux reenviat en totes dues direccions. El lliurament és un requisit previ, no un substitut, de la resta del camí. Una ruta que funciona amb l'encaminament desactivat produeix exactament el mateix silenci que una ruta absent, així que comproveu totes dues coses abans de redissenyar res.

Dues rutes independents a encertar

El prefix de l'agrupació i la ruta per defecte del propi client són configuracions separades, i confondre-les produeix connectivitat parcial que sembla un túnel trencat. L'agrupació diu al servidor quines adreces ha de repartir. Les rutes del client decideixen a quines destinacions el client envia trànsit al túnel, si és que n'hi envia.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

El prefix anterior és espai de documentació, i la redirecció només s'aplica a IPv6, que és exactament el que sovint vol un desplegament de doble pila mentre el lliurament IPv6 encara s'està arreglant. Una redirecció IPv4 no estableix cobertura IPv6, i cap de les dues configuracions implica l'altra.

Manteniu en funcionament el trànsit de control del qual depèn IPv6 sota qualsevol política que apliqueu. Els missatges Packet Too Big són la víctima clàssica d'un tallafoc que només permet TCP i UDP, i descartar-los produeix connexions que s'estableixen i després s'encallen en transferències grans.

Els anuncis de router són la tercera peça mòbil. Si la passarel·la comença a anunciar a l'enllaç ascendent, pot canviar el que els clients i els veïns creuen sobre els prefixos a l'enllaç, cosa que pot desfer silenciosament el disseny que acabeu de documentar.

Documenteu el disseny perquè una reconstrucció el reprodueixi

Anoteu tres objectes per separat: l'assignació del client, la ruta de destinació del client i el mètode de lliurament de l'upstream per a l'assignació. Un lector que tingui els tres pot reconstruir el desplegament; un lector que només tingui la configuració de l'agrupació reproduirà l'error original.

Després proveu explícitament la direcció de tornada, amb un paquet que hagi de tornar de fora. El manual d'openvpn(8) cobreix les opcions server-ipv6 i redirect, i la confirmació d'encaminament del vostre proveïdor cobreix la meitat que el manual no pot.