Cómo probar IPv6 a través de una VPN con tu propio recurso

Una página pública de comprobación de IP responde a una pregunta, y normalmente no a la que planteaste. Te dice la dirección de salida que observó la página; no te dice si la ruta IPv6 por el túnel funciona, si el host prefirió IPv6 o retrocedió, ni si una aplicación excluida tomó otro camino. Un recurso autorizado que controlas responde correctamente a la pregunta más estrecha, porque ves ambos extremos. El procedimiento de abajo trata de llegar a una conclusión que puedas defender, no de obtener un resultado verde.

Paso 1: di qué ruta IPv6 estás probando

Dilo en una frase. Una petición a la dirección IPv6 propia del servidor del túnel prueba el túnel; una petición a un host más allá de la salida prueba la salida IPv6 de la salida; una petición a una dirección IPv6 privada prueba una ruta interna.

Son tres afirmaciones distintas y una sola petición correcta no puede sostenerlas todas. Elige la que importa para la decisión que tienes delante y anótala antes de ejecutar nada. Si la preocupación es si IPv6 se escapa alrededor del túnel, la pregunta es sobre la selección de ruta del host, no sobre el alcance de la salida. Si la preocupación es si el lado remoto puede llegar a un servicio interno, la salida es irrelevante.

Paso 2: confirma que el host selecciona esa ruta

ip -6 route get 2001:db8:1::10 imprime la ruta, la dirección de origen y la interfaz que usaría el núcleo, y ese es el hecho del que depende el resto de la prueba.

Que exista una interfaz no es lo mismo que esté seleccionada. Los hosts de pila doble tienen una tabla de precedencia, y /etc/gai.conf en Linux puede cambiar qué familia gana para un nombre que resuelve a ambas.

Paso 3: usa un destino y un nombre legítimos

Si pruebas HTTPS, usa el nombre de host para el que se emitió el certificado y mantén la verificación activada; pasar a una dirección literal para que la prueba pase desactiva justo la comprobación que demuestra que llegaste al host previsto. Un servicio de diagnóstico que controlas, que responde en un nombre conocido con un certificado válido, es el objetivo más limpio. También te da una línea de registro del lado del servidor con la que correlacionar, algo que un comprobador de terceros nunca hará.

Ejecuta la petición en una forma que muestre la dirección que usó: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. El -6 fuerza la familia, y así separas IPv6 no funciona de IPv6 no se prefirió.

Para una comprobación pura de alcance donde se permite ICMPv6, ping -6 -c 3 2001:db8:1::10 es suficiente. Demuestra el camino y nada por encima.

Paso 4: correlaciona ambos extremos

Cuando tengas acceso a ambos extremos, ejecuta tcpdump -ni any ip6 and host 2001:db8:1::10 en el cliente y el equivalente en el recurso, con marcas de tiempo, y confirma que el mismo flujo aparece en los dos. Eso es lo que convierte un resultado plausible en evidencia: la vista del cliente por sí sola no puede distinguir una respuesta del recurso de una respuesta de algo intermedio. Mantén la captura ceñida a un solo destino para que la salida siga siendo legible y la sesión no relacionada de nadie acabe en el archivo.

Repite la prueba tras una reconexión si la preocupación es si la política sobrevive a un reinicio. El estado de ruta y de cortafuegos aplicado una vez al conectar puede diferir del estado que se vuelve a aplicar, y la diferencia solo aparece en la segunda conexión.

Prueba el caso de fallo por separado si lo necesitas. Un túnel que bloquea IPv6 cuando cae y uno que lo deja escapar son diseños distintos, y solo uno de ellos puede verificarse con una petición correcta.

Paso 5: escribe qué no demostró la prueba

El paso cinco es escribir qué no demostró la prueba, y es la parte que se suele omitir. Una prueba correcta contra un extremo privado no demuestra la salida IPv6 pública, no demuestra el comportamiento de DNS y no cubre las aplicaciones que excluiste del túnel. Cada una de esas necesita su propio destino y su propia observación. Una nota que dice que IPv6 funciona tras una petición a un host no es un hallazgo; es una conjetura con marca de tiempo.

El registro que merece la pena guardar es corto: el destino, el nombre, la dirección de origen que eligió el host, la dirección remota observada y la hora. RFC 7359 trata de cómo probar que una ruta IPv6 relevante es realmente utilizable, y ese es el estándar al que este procedimiento se aproxima con herramientas más simples. Si la conclusión necesita un comprobador público para ser cierta, la prueba no fue lo bastante específica.