Usar internet sin conexión IPv4

• Incluso en una situación donde la conectividad IPv4 estaba caída, fue posible seguir usando todo internet mediante IPv6, WireGuard y un VPS de Hetzner
• Debido a Carrier Grade NAT (NAT a gran escala), la falla afectó solo a IPv4, mientras que IPv6 no se vio afectado
• Al configurar un túnel de WireGuard y enrutar el tráfico IPv4 a través del VPS, se restauró un entorno normal de navegación web
• También se explican formas de usar network namespaces y Docker, además de cómo resolver problemas de MTU
• Se destaca la experiencia de resolver por cuenta propia un problema de red complejo gracias al entorno Linux y herramientas de código abierto

---

Resumen general

Hace unos días, el autor tuvo un problema en el que la conexión IPv4 dejó de funcionar en el router de su casa después de un corte de energía. Por suerte, la conexión IPv6 seguía funcionando, así que podía acceder a algunos sitios web (como Google o Meta), pero la mayoría de los sitios (como GitHub) no estaban disponibles. Aquí resume el proceso con el que logró restaurar un entorno de internet completo usando solo IPv6 mediante Linux, WireGuard y un VPS de Hetzner.

Causa de la falla y contexto

Detección de una anomalía en el entorno de red

• Durante la recuperación tras el apagón, se confirmó que los servidores con IPv6 eran accesibles, mientras que los servidores con IPv4 no lo eran
• Los resultados de comandos de diagnóstico como ping -6 y traceroute también solo mostraban diferencias según la versión de IP
• Tras consultar al proveedor, se determinó que había un problema en la capa de CG-NAT (Carrier Grade NAT) del operador, específicamente en la conversión de IPv4
• Como se esperaba que el mantenimiento del ISP tardara varios días, fue necesario buscar una solución por cuenta propia

Explicación de NAT y CG-NAT

• NAT (Network Address Translation): método que permite que varios dispositivos compartan una sola dirección IPv4 pública
  • El router traduce la IP interna a una IP pública con un puerto único para gestionar el tráfico, y al devolverlo restaura el destino interno usando la información de mapeo
  • Por esta estructura surgen tanto el papel de firewall implícito como la necesidad de hacer port forwarding
• CG-NAT (Carrier Grade NAT): estructura por capas en la que el ISP aplica NAT una vez más sobre los routers domésticos
  • El ISP aplica NAT de forma encadenada internamente debido a la escasez de direcciones IPv4
  • En entornos con CG-NAT, ofrecer servicios como port forwarding es todavía más limitado
  • La razón por la que la falla afectó solo al tráfico IPv4 fue precisamente un problema de procesamiento de paquetes IPv4 en esta capa

Ventajas de IPv6

• El espacio de direcciones de IPv6 es tan amplio que permite asignar direcciones directas a cada dispositivo sin necesidad de NAT
  • A la mayoría de los routers residenciales se les asigna una subred /64, con la que se pueden usar billones de direcciones
• Como no hace falta NAT, la comunicación directa es posible, aunque la configuración del firewall se vuelve más importante
• Como el CG-NAT solo se aplica a IPv4, en este incidente solo IPv6 siguió funcionando normalmente
• Aun así, muchos servidores (por ejemplo, GitHub) todavía no pueden usarse únicamente con IPv6

Recuperar IPv4 con un túnel de WireGuard

Resumen de la implementación

• Usando un VPS de Hetzner (compatible con pila IPv4/IPv6) y WireGuard, se construyó un entorno con acceso completo a internet aun cuando la conexión disponible era solo por IPv6
  • En el VPS se ejecuta el servidor WireGuard y se establece un túnel con el equipo cliente
  • El tráfico se desvía al VPS a través de IPv6, y desde ahí se puede acceder a todos los sitios, incluidos los que dependen de IPv4
  • El principio es similar a Dual-Stack Lite

Ejemplos de configuración de servidor y cliente

• En la configuración del servidor WireGuard se manejan tanto el tráfico IPv4 como IPv6
  • Se incluyen ejemplos de reglas MASQUERADE (traducción dinámica de IP) y SNAT (traducción de IP fija)
  • Al usar IPv6 global asignada directamente, es posible conectar peers de WireGuard sin NAT
  • Se puede escribir varias veces PostUp/PostDown para ejecutar comandos en secuencia
• Ejemplo de configuración del cliente
  • Se explica una combinación posible con direcciones IPv6 asignadas directamente o con ULA detrás de NAT
  • Con AllowedIPs configurado como 0.0.0.0/0, ::/0, es posible tunelizar todo el tráfico
  • También se muestra cómo configurar DNS de Google (IPv4 e IPv6) y el MTU

Funcionamiento correcto del túnel

• Una vez completada la configuración de WireGuard en ambos extremos, tanto IPv4 como IPv6 se tunelizaron correctamente
• El mismo método se aplicó también a la PC de su esposa, instalando de forma sencilla un cliente WireGuard para Linux
• Sin embargo, normalmente no es posible conectarse al mismo tiempo a la VPN corporativa, por lo que hace falta usar un network namespace adicional

Network namespaces y Docker

Funciones y formas de uso

• Con herramientas como vopono, se pueden crear network namespaces por aplicación y asignar directamente la interfaz VPN o WireGuard dentro de ese namespace
  • Hace falta definir reglas MASQUERADE adicionales para forzar que el tráfico interno pase por el túnel de WireGuard
  • También se incluyen consejos para configurar DNS aislado del exterior y gai.conf (prioridad DNS con preferencia por IPv4)
• Se muestra un ejemplo de implementación en el que la conexión VPN y la ejecución de aplicaciones se realizan dentro del namespace
  • Ejecutar varios servicios dentro del mismo namespace ayuda a prevenir conflictos de red de antemano

Combinación con contenedores Docker

• Como el demonio de Docker usa por defecto el socket de red del host, no se puede acceder a él simplemente ejecutándolo dentro de un namespace normal
  • Se propone un workaround usando técnicas de virtualización Unix como mount namespace y bind mount de /sys
  • Al ejecutar dockerd dentro del namespace y definir un socket y un data root separados, se recupera la conectividad a internet dentro de los contenedores
  • También se menciona que en entornos con bridges de red más complejos pueden hacer falta configuraciones adicionales

Problemas de MTU en WireGuard (MTU: unidad máxima de transmisión)

• Después de establecer la conexión con WireGuard, algunos sitios web no cargaban (por ejemplo, con SSL), aunque ping respondía normalmente
• Mediante pruebas de ping con distintos tamaños, se identificó que el MTU era demasiado alto y los paquetes grandes se estaban descartando en el camino
  • Al bajar el MTU a 1280, el problema se resolvió de inmediato
• MTU es el tamaño máximo de paquete que puede transmitirse de una sola vez
  • En túneles y encapsulación hay que ajustar el MTU considerando el overhead; de lo contrario, pueden aparecer fallas al transferir paquetes grandes
  • En IPv6, el MTU mínimo definido por el estándar es 1280

Conclusión y recomendaciones de uso

• Se destaca la experiencia de diagnosticar y resolver problemas de red por cuenta propia con Linux y herramientas de código abierto, incluyendo la creación de un servidor VPN con WireGuard, la gestión de network namespaces, configuraciones especiales para Docker y troubleshooting de MTU
• Servicios como los VPS de Hetzner ofrecen buena estabilidad por su precio y facilitan operar servicios de red legítimos como WireGuard
• También se revalora el uso de firmware de router de código abierto (OpenWRT) y las técnicas de networking en Linux
  • La flexibilidad de poder administrar y modificar directamente la red representa una gran ventaja en entornos de trabajo remoto
  • Con suficiente comprensión y práctica, incluso fallas complejas de red pueden resolverse sin ayuda externa

Material de referencia

• Tailscale – How NAT Traversal Works
• ArchWiki – ejemplos de casos de uso de WireGuard
• Unix StackExchange – trucos de Docker dentro de namespaces
• AskUbuntu – configuración de prioridad de DNS

(Para scripts relacionados, configuración, consejos y enlaces de referencia, consultar el texto original)

[GN⁺]

Comentarios en Hacker News

• El título puede prestarse un poco a confusión, pero en realidad este artículo se parece más a “conectarse a un VPS por medio de un túnel IPv6 para acceder al internet IPv4”, lo que comúnmente se conoce como 4in6.
  Aun así, es un método interesante.
  En nuestro ISP, cuando falla IPv4, se cae todo de inmediato y los problemas de soporte son relativamente simples; pero cuando falla IPv6, el comportamiento es parcial y extraño, como conexiones lentas o cortes intermitentes.
  Sobre todo, si el gateway cree por error que sí tiene IPv6, desde la perspectiva del usuario el problema se vuelve más fastidioso, porque solo dejan de funcionar algunas cosas.

  • Hace poco, cuando IPv4 dejó de funcionar por un rato, me di cuenta porque GitHub no cargaba.
    Hoy en día, la mayoría de los sitios web para consumidores funcionan bien sobre IPv6.
    Pero quienes tienen routers que solo ofrecen DNS por IPv4 sí se quedaron completamente sin internet.
    Ojalá Microsoft le pusiera un poco más de atención a eso.
    Para comprobar si IPv4 había vuelto, incluso tuve que acordarme del hostname mDNS que le había asignado al router.

  • Sinceramente, una vez se cayó IPv4 en mi casa y mi esposa ni se dio cuenta.
    Google, Facebook, Apple/iCloud y casi todos los servicios basados en CloudFlare funcionan bien por IPv6.

  • Mi experiencia es parecida.
    Los problemas de IPv6 de verdad son difíciles de diagnosticar y reproducir, y todo se resume en “¿pues en mi computadora sí funciona?”

  • La mayoría de los ISP todavía bloquean IPv6, y muchas pequeñas empresas intentan usarlo pero se olvidan de cosas como los registros AAAA.
    Entonces a los usuarios les pasa que algo funciona en la casa de un amigo o en una cafetería con un ISP barato, pero en su propia casa no.
    Puede sonar raro, pero no parece haber una buena solución; en la práctica solo queda esperar a que IPv4 desaparezca.
    Existen técnicas como Happy Eyeballs, que intenta conectarse al mismo tiempo por IPv4 e IPv6 y elige la más rápida, pero en la realidad muchos más problemas aparecen en la capa de la aplicación y faltan formas generales de resolverlos.
    En mi caso, uso una solución de compromiso: dejo IPv6 habilitado en la red, pero desactivo el DNS sobre IPv6 en el navegador, aunque no me deja satisfecho.

• Si quieres usar IPv6 pero tu ISP no lo ofrece, Hurricane Electric (HE) lleva muchísimo tiempo ofreciendo un servicio de túnel gratuito.
  Hay varios recursos al respecto, como tunnelbroker.net, ipv6.he.net, configuración en Fedora, blog de Brandon Rozek, configuración en DD-WRT, script de actualización automática en el foro de Mikrotik, y guía para RockyLinux con distintas formas de configurarlo.

  • Un detalle a tener en cuenta es que muchos servicios de streaming bloquean este tipo de túneles, como si detectaran una evasión por VPN, por temas de contenido con restricciones regionales.
    Aun así, gracias a la función RA (router advertisement), cualquier dispositivo de red puede anunciar una red IPv6 en bloques /64, así que varios equipos dentro de la red pueden usar direcciones IPv6 aunque el router no soporte directamente el túnel de HE (siempre que el router no filtre RA por razones de seguridad).
    Cuando quieres alojar algo por tu cuenta en casa, es muy cómodo poder hacerlo solo con IPv6 y sin port forwarding.

  • El servicio de Hurricane Electric es bueno, pero ahora que cada vez más ISP ofrecen IPv6 por defecto, los usuarios comunes se están alejando de los servicios de túnel.
    Además, cada vez más servicios de red bloquean los túneles de he.net por considerarlos abuso o uso malicioso, así que al final tuve que dejar de usar IPv6 en la mayor parte de mi red.

  • Como referencia, los túneles de Hurricane Electric requieren sí o sí que el ISP te asigne una dirección IPv4 pública.
    Si estás detrás de NAT, por ejemplo con carrier-grade NAT, tendrás que buscar otra solución para llevar IPv6 a tu casa.

  • Llevo 5 años como “cliente” del túnel gratuito 6in4 de HE en OpenBSD.
    Me ha funcionado de forma estable solo con configuración de red, usando cosas como el archivo /etc/hostname.gif0.
    También lo uso para comunicarme con un clúster de VPS en AWS configurado deliberadamente sin IPv4.
    Como AWS cobra agresivamente por las direcciones IPv4, me parece que este método ayuda muchísimo a reducir costos.

• Si realmente estás en un entorno solo v6 y necesitas conectividad v4, una forma sencilla es usar un gateway público DNS64+NAT64.
  Consulta la lista de proveedores públicos de nat64.net.
  Normalmente basta con cambiar el servidor DNS.
  DNS64 genera registros AAAA sintéticos para sitios que no tienen AAAA, de modo que puedan conectarse a una caja NAT64.
  Luego NAT64 recibe el tráfico y hace la conversión de protocolo más NAT.
  Incluso puedes probarlo enseguida con comandos como dig o curl para entrar a sitios como GitHub.

  • En Europa, incluso usando directamente nat64.net, funciona bastante bien.
    La verdad, solo he tenido buenas experiencias.

  • Si usas Cloudflare WARP, puedes sentir velocidades mucho mejores.
    A través de WARP también puedes acceder directamente a direcciones IPv4.

• A veces me sorprende que haya usuarios que usen IPv6-only.
  Antes, en la situación opuesta —un entorno solo IPv4 donde se necesitaba acceso IPv6—, si tenías control total del servidor, la mejor solución rápida era usar un proxy SOCKS5 con ssh -D.
  Solo hacía falta configurar el navegador para usar el proxy socks y listo.
  Si lo aplicabas a todo el sistema, hasta existía el riesgo de cortar la propia conexión SSH, así que eso sí daba algo de preocupación.

• Estoy en una situación parecida.
  Llevo unas dos semanas con un ticket abierto por una falla de IPv4, y solo me responden que “pronto lo verá un técnico”.
  Como IPv6 funciona bien, parece que no lo consideran una caída total.
  En Alemania existen normas sobre compensación al consumidor en estos casos, y voy a revisar si esta situación entra ahí.
  El problema del método que propone el post es que muchos servicios bloquean rangos de IP de datacenters, o te obligan a pasar captchas, o los tratan como IP de proveedor VPN, así que no hay muchas formas de evitarlo.
  En mi caso tenía que resolverlo para toda la casa, así que configuré en el router el enrutamiento por Wireguard y las reglas de NAT; tuve suerte de contar con un equipo abierto como Ubiquiti EdgeRouter.
  Si hubiera sido un FritzBox, creo que habría sido mucho más difícil.
  Eso sí, como el rendimiento del router es limitado, cuando hay muchas conexiones se vuelve lento, así que estoy pensando en cambiarlo por IPSec con soporte de offloading por hardware.

  • FritzBox también ofrece un proceso de configuración por GUI muy bueno para conexiones VPN.
    La idea base es FritzBox a FritzBox, pero cualquier VPN compatible funciona.
    También permite configurar rutas IPv4/IPv6 fijas.
    El mayor problema es averiguar qué parámetros de cifrado IPSec exige el otro extremo; Wireguard es más fácil, pero a cambio está el tema de la aceleración por hardware.
    Si hace falta, incluso existe la técnica de respaldar toda la configuración del FritzBox, editarla manualmente y volver a cargarla recalculando solo el checksum.
    AVM ha escondido una enorme cantidad de parámetros avanzados que no muestra al usuario, y eso es intencional.
    En parte lo hacen para que no sea tan fácil romper el router por accidente.

  • No sé bien cómo sea en Alemania, pero en Países Bajos, si usas el mismo ISP para internet fijo y móvil, puedes pedir datos móviles gratuitos cuando hay una falla en la red fija.
    Si puedes, te recomendaría preguntarle al ISP si tiene una opción parecida.

• Aunque pase el tiempo, no encuentro una razón clara para pasar todos mis equipos y mi home lab a IPv6.
  Port forwarding y la configuración del firewall me parecen relativamente intuitivos, mientras que con IPv6 me imagino semanas enteras resolviendo problemas, ajustando el firewall y reconfigurando direcciones.
  Me pregunto si se me está escapando algo.

  • Siendo realistas, por ahora casi no te estás perdiendo de nada.
    Más adelante, cuando empresas grandes como Google o Cloudflare ya no puedan absorber el costo creciente de las direcciones IPv4, puede que empiecen a ofrecer incentivos para IPv6, por ejemplo limitando la velocidad de conexiones IPv4.
    AWS antes solo cobraba por direcciones IPv4 Elastic IP sin usar, pero ahora cobra incluso si están en uso.
    Cuando te toque actualizar gateways o routers en el futuro, probablemente convenga simplemente dejar IPv6 activado; hoy en día, usando dual stack, tus equipos y servicios existentes seguirán funcionando sin problema.
    En cuanto a la autoconfiguración de direcciones en IPv6, históricamente todo fue bastante caótico, pero parece que SLAAC se está consolidando, mientras que desde la perspectiva de los ISP es probable que DHCPv6 siga usándose durante bastante tiempo.

  • En realidad no es tan difícil.
    Si tu red doméstica no es especialmente compleja, puedes dejar IPv6 funcionando con solo dedicarle un rato en la tarde.
    En Comcast, por ejemplo, basta con activar la opción IPv6 en el router para que el ISP te entregue un prefijo, eso se anuncie automáticamente en la red y solo tengas que abrir en el firewall los puertos que quieras.

  • No te estás perdiendo de nada.
    En entornos empresariales, adoptar IPv6 trae más desventajas o complejidad que beneficios.
    Yo administro unas 3500 máquinas, 7 edificios, 2 enlaces WAN de 10 Gbps, 1 de 4 Gbps y 26 direcciones IPv4 públicas.
    Hasta ahora no he tenido ni una sola razón que me obligue a usar IPv6.
    Operar en dual stack genera carga innecesaria y complejidad en la red.
    De hecho, recientemente solicité dos veces un bloque IPv6 fijo y me lo rechazaron ambas veces.
    En la práctica no hay beneficios reales, e incluso conseguir la asignación es difícil.
    Si ves la guía para la primera solicitud IPv6 de ARIN,
    → tener una asignación IPv4
    → planear multihoming IPv6 de inmediato
    → tener 13 sitios finales (oficinas, etc.) en un año
    → usar 2000 direcciones IPv6 en un año
    → usar 200 subredes /64 en un año
    debes cumplir al menos una de esas condiciones para poder solicitarlo.

• De verdad aprecio mucho la política de Apple App Store que exige que todas las apps funcionen en redes IPv6-only.
  Desde la perspectiva del desarrollador, puede sorprender la primera vez, pero como consumidor es muy bueno que exista ese requisito.

  • Pero esa política no exige que el lado del servidor tenga direcciones IPv6.

  • Entonces me pregunto si GitHub es accesible por v6 desde la app.

• En el trabajo operamos varias VPN IPv6-only para acceder a infraestructura interna.
  El mayor problema es que los clientes Windows y macOS necesitan sí o sí un servidor DNS por v6.
  Como el cliente puede estar en una red con soporte v6 o no, corremos nuestro propio servidor DNS dentro de la VPN y se lo entregamos automáticamente al cliente,
  pero cuando la conexión VPN se cae, la app de Wireguard no logra restaurar el DNS original y eso genera varios problemas.

  • Yo he usado IPv6-only sin DNS adicional incluso en una red IPv4-only de ISP y con macOS.
    No recuerdo exactamente cómo lo hice, pero macOS funcionaba sin problemas con solo asignarle una dirección v6.
    Basta con asignar una dirección ULA al host, y eso es fácil si sabes cómo hacerlo.
    Una app de VPN podría usar un script que agregue esa ULA directamente a la red IPv6-only.
    Eso sí, si dejas esa ULA configurada sin control, puede causar problemas cuando el usuario se mueva a otra red v6.

• Si alguien está pasando por lo mismo, con un proxy SSH (ssh -D 8080 user@hostname) se puede montar fácilmente un entorno de proxy socks.
  Después solo hay que poner localhost:8080 como dirección de proxy en el navegador.

  • Justo iba a dar ese mismo consejo.
    Es muy simple como solución temporal y, cuando hace falta, también funciona excelente como herramienta permanente.
    Eso sí, AllowTcpForwarding debe estar habilitado en sshd_config.

  • Yo siempre uso este método cuando estoy en wifi público.
    Así no tengo que pagar un servicio VPN ni confiar en uno; simplemente envío todo por un proxy socks en mi servidor de infomaniak.

• Personalmente tengo muchas quejas sobre IPv4, y más todavía porque mi ISP me obliga a usar solo IPv4.
  Considero que la lentitud en la adopción de IPv6 es un gran fracaso de la industria tecnológica.
  Me pregunto quién debería rendir cuentas.
  Creo que hace falta una discusión más de fondo sobre las causas: si es por el firmware mediocre de los fabricantes de routers, por la falta de liderazgo de los ISP a favor de IPv4, por los especuladores de direcciones IPv4, o por la falta de capacitación de ingenieros y personal de soporte de red.
  Si internet pudo migrar relativamente bien desde TLS 1.0, parecería que también debería poder dejar atrás IPv4.
  Tal vez más adelante algo como un proxy con IA para código legacy podría convertirse en una solución.

  • La transición desde TLS 1.0 fue más fácil gracias al principio end-to-end.
    Bastaba con que servidor y cliente soportaran el nuevo protocolo; los equipos intermedios, como routers y switches, solo tenían que ver la capa de red (IP) y no les importaba la nueva versión de TLS.
    Pero si cambias el protocolo de la capa de red (IP), todos los equipos intermedios se ven afectados.
    De hecho, incluso con la llegada de TLS 1.3, los middleboxes rompieron el principio end-to-end inspeccionando y alterando tráfico, y por compatibilidad TLS 1.3 tuvo que disfrazarse de reanudación de TLS 1.2, lo cual fue bastante absurdo.

  • La diferencia es que TLS solo requiere soporte en servidor y cliente, mientras que el equipo de red intermedio únicamente necesita ver paquetes TCP.
    IPv6, en cambio, requiere soporte de todos los equipos intermedios entre servidor y cliente, así que es una tecnología dependiente del “mínimo común denominador”.
    La actualización de TLS no cambió tantas cosas, mientras que IPv6 cambió demasiadas al mismo tiempo.
    Viéndolo en retrospectiva, da la impresión de que, si IPv6 simplemente hubiera ampliado las direcciones a 64 bits, tal vez habría sido más fácil de adoptar.

  • En la práctica, mucha gente simplemente no ve ventajas reales, o ve muy pocas, así que no se anima a adoptarlo.
    No hace falta ninguna gran conspiración pro-IPv4; simplemente el beneficio no compensa el trabajo ni el riesgo.

  • En el mundo de redes hay un chiste: “IPv6 es una solución académica aplicada a la fuerza a un problema de ingeniería”.
    Cuando piensas en compatibilidad a gran escala con IPv4 y además en despliegue, operación y mantenimiento reales, IPv6 resulta demasiado complejo.
    Como IPv4 en realidad no tiene más problema práctico que la escasez de direcciones, tampoco parece que vaya a desaparecer.
    Por eso, sobre el terreno, IPv6 no está logrando convertirse en una solución realmente práctica.