¿VPN no deja pasar el tráfico? Desglosamos la enrutación, métricas y conflictos al detalle

¿Alguna vez te conectaste a una VPN y sentiste que tu internet se fue de vacaciones sin avisar? O que algunos recursos internos funcionan, pero otros se quedan mudos como si fueras un fantasma para ellos. Hemos estado ahí. Conocemos ese dolor. La enrutación a través de VPN es un asunto delicado. Solo un pequeño error en la métrica de ruta o en el gateway predeterminado, y el tráfico toma un camino equivocado. A veces falta la ruta inversa. O el DNS apunta al lugar incorrecto. Y a veces el MTU juega una mala pasada y corta paquetes como un chef en una clase de cocina. Pero no hay que alarmarse. Con calma, paso a paso, y con una guía en mano, analizaremos todo detenidamente.

En 2026, una VPN no es simplemente “levantar el túnel y olvidar”. Vivimos en la era Zero Trust, SASE, ZTNA y montones de escenarios híbridos: nube, sucursales, trabajo remoto, redes móviles, y todo junto. En la mesa conviven WireGuard, IKEv2/IPsec, SSL-VPN sobre QUIC e incluso túneles sobre proxies y HTTP/3. Y sí, con frecuencia tienes activados a la vez DoH, DNS corporativos con split-horizon, segmentos IPv6-only con NAT64/DNS64 y un par más de políticas que compiten por tu tráfico. ¿Molesto? Sí, pero muy interesante.

Este artículo es una guía práctica. Nada de teoría seca por teoría misma. Veremos conflictos concretos de rutas, entenderemos cómo funcionan métricas y prioridades en Windows, Linux y macOS, identificaremos dónde fallan los gateways y por qué el tráfico se vuelve «unidireccional», configuraremos el split tunneling para que no te duela la cabeza y aprenderemos a diagnosticar con estabilidad. Habrá casos reales, comandos útiles, listas de verificación y consejos para automatización. Al final, un FAQ que vale la pena guardar en favoritos. ¿Vamos?

Cómo funciona la enrutación en VPN y dónde suele fallar la lógica

Tabla de rutas: el guionista principal de tu tráfico

Cuando nos conectamos a una VPN, el sistema recibe nuevas rutas. Cada ruta tiene una red de destino, máscara (o prefijo), siguiente salto (gateway), interfaz y métrica. La regla de prioridad es sencilla: primero se busca la coincidencia con el prefijo más largo, luego se comparan las métricas. Cuanto más corta la ruta y menor la métrica, más probable que el sistema elija esa ruta. A veces el cliente VPN añade rutas “amplias” (como 0.0.0.0/0) y así absorbe todo el tráfico. Si no hay excepciones configuradas, el internet desaparece como por arte de magia. Suena básico, pero es por donde debes comenzar a analizar.

Otro detalle es el orden de las interfaces y las métricas automáticas. En Windows y macOS el sistema suele “pensar por ti”, asignando auto-metric según la velocidad de la interfaz. ¿Conectaste VPN por Wi-Fi y tienes Ethernet cerca? Puede que te lleves alguna sorpresa. En Linux la historia es diferente: con policy-based routing (PBR) y múltiples tablas de rutas puedes ver una ruta en la tabla principal y otra distinta en la política que captura el tráfico deseado. Resultado: diferentes rutas para distintos paquetes, aunque aparentemente “todo está correcto”.

Conflictos típicos: superposición de subredes, duplicados y agujeros negros

El clásico: redes RFC1918 que se superponen. Por ejemplo, en la empresa usan 10.0.0.0/8 y el empleado en casa tiene un router que asignó 10.0.0.0/24. O más interesante aún, dentro de la VPN hay varias subredes que se solapan por agregación BGP. En ese caso, una ruta más general puede eclipsar a la específica y el tráfico irá por donde no toca. ¿Ves 10.20.0.0/16 y 10.20.5.0/24 pero la métrica para /16 es menor? Entonces el tráfico se irá por el lado incorrecto y empezarán los famosos “agujeros negros”.

Otra frecuente es la duplicación de rutas por el mismo cliente VPN: OpenVPN puede añadir tanto 0.0.0.0/1 como 128.0.0.0/1 (para full tunnel), mientras que otro ya tiene definido el default. El sistema elegirá una, pero el control del tráfico inverso puede perderse. El tercer escenario: añaden rutas hacia recursos internos, pero el servidor carece de ruta inversa. El paquete entra, pero la respuesta regresa “por otro lado” al proveedor y se descarta. Así surge la asimetría: el cliente puede hacer ping, el servidor ni responde.

Cliente y servidor VPN: quién y cuándo manda en las rutas

Los clientes se comportan distinto. WireGuard emplea AllowedIPs: es filtro y ruta a la vez. Añades 0.0.0.0/0 y tienes full tunnel; prefijos específicos, split. OpenVPN suele usar redirect-gateway def1, route-nopull y comandos push desde el servidor para añadir rutas necesarias. En IKEv2/IPsec hay selectores y políticas, y con BGP se pueden anunciar prefijos dinámicamente. El servidor puede imponer rutas al cliente o delegar al equipo local.

En infraestructuras grandes los servidores VPN interactúan con SD-WAN, PBR y políticas de firewall. Las rutas a segmentos llegan por BGP o estáticas; los clientes solo reciben las zonas necesarias. Es vital saber quién “manda” en cada topología: si el cliente decide dónde enviar tráfico o es el servidor/controlador quien dicta las reglas. Esto define dónde buscar la causa. A veces es más fácil cambiar el comportamiento del cliente (por ejemplo, desactivar auto-metric y poner parámetros fijos) que intentar alterar la política del servidor.

Diagnóstico básico: qué revisar primero

Pruebas de red: ping, traceroute, MTR y revisión DNS

Comienza simple. Haz pings al IP interno: si responden, la conectividad básica existe. Un ping por nombre verifica el DNS. Si pasa por IP pero no por nombre, busca el problema en el resolvedor, split-horizon o el orden de servidores DNS. Traceroute o tracepath (Linux) muestran por dónde realmente va el tráfico. MTR es útil para trazas largas y rutas inestables: ves latencias y pérdidas a la vez.

Revisa hacia dónde va el tráfico de internet. Haz traceroute a 8.8.8.8 u otra IP pública. Si al conectar VPN la ruta falla y el primer salto es una IP del túnel, tienes full tunnel. Pero si no hay full tunnel y el internet sigue “desaparecido”, puede ser un problema de DNS o MTU. Prueba sencilla: carga páginas pequeñas y luego más pesadas. Si se cuelga en recursos grandes, apunta a MTU o bloqueo de PMTUD.

Tablas de rutas: Windows, Linux, macOS — identifica desajustes

En Windows usa route print y Get-NetRoute, y si es necesario Get-NetIPInterface para ver métricas de interfaces. Compara quién maneja 0.0.0.0/0, qué rutas específicas hay y métricas del interfaz VPN y LAN. A veces basta desactivar la métrica automática y ajustar prioridades a mano para que el tráfico tome el camino correcto. También revisa tablas IPv6: route print -6 y Get-NetRoute -AddressFamily IPv6.

En Linux ejecuta ip route show, ip -6 route, y si sospechas de PBR, ip rule list y el contenido de varias tablas (ip route show table 100, etc.). Observa prioridades y políticas de mark. Algunas apps ponen fwmark y el tráfico sale por rutas distintas. En macOS usa netstat -rn, route -n get <dirección>, networksetup -listallnetworkservices y scutil --dns para el orden de resolvedores y prioridad de interfaces. Problemas comunes: la interfaz VPN está añadida pero el “orden de servicio” no se actualizó y el sistema insiste con Wi-Fi.

Captura de paquetes: Wireshark, tcpdump y herramientas del sistema

Si las tablas no dan pista clara, activa un sniffer. En Linux: tcpdump -i wg0 host dirección_necesaria o tcpdump -i any port 53 para DNS. Observa hacia dónde va el tráfico, si hay respuestas y cómo cambia el TTL en el camino. En Windows en 2026 usan mucho pktmon y el clásico Visor de Eventos, pero Wireshark sigue siendo el rey: filtra por interfaz VPN y destino. Si ves SYN sin SYN-ACK, revisa la ruta inversa y el firewall.

Otro consejo: revisa PMTUD. Activa el df-bit y envia paquetes grandes. Si se quedan a mitad de camino, quizá bloquean ICMP Fragmentation Needed. Diagnosticar líos DNS es aparte: scutil --dns en macOS muestra qué dominios van a qué resolvedor; en Linux, resolvectl status indica el servidor actual. A veces basta ajustar el orden de resolvedores o añadir forwarding condicional para dominios internos para que ocurra la magia.

Métricas y prioridades: cómo funcionan en Windows, Linux y macOS

Windows: auto-metric, InterfaceMetric y RouteMetric

En Windows la prioridad automática es generosa, pero no siempre inteligente. Interfaces más rápidas pueden obtener métrica menor, y el sistema decide que son más importantes. La métrica del interfaz VPN es virtual y a menudo extraña. Por eso se suele desactivar auto-metric para el interfaz VPN y ajustar InterfaceMetric manualmente (por ejemplo, 5 o 15, según diseño). Luego se controla RouteMetric para rutas específicas: menor número, mayor prioridad.

Revisa con Get-NetIPInterface y ajusta con Set-NetIPInterface -InterfaceMetric. Para rutas, usa New-NetRoute o Set-NetRoute con RouteMetric. Si el cliente VPN fuerza el default y necesitas split, usa políticas del cliente: route-nopull en OpenVPN y agrega rutas específicas manualmente. En Always On VPN y clientes corporativos modernos puedes definir reglas de inclusión/exclusión para no romper el internet y solo enrutar prefijos necesarios por el túnel.

Linux: prioridades, policy-based routing y tablas múltiples

En Linux la métrica en ip route es solo parte del cuento. Con ip rule tienes tablas de rutas múltiples, y la prioridad (priority) decide cuál procesa el paquete. Esto es poderoso y riesgoso: puedes hacer reglas complejas (por fuente, fwmark, TOS) pero fácilmente puedes aislar una app. Si el cliente VPN añade una tabla y regla de alta prioridad, todo el tráfico se irá por el túnel aunque el default principal debería ir por internet.

Tu receta práctica: ip rule list, luego ip route show table main y otras mencionadas. Asegura que no haya conflictos ni que la tabla VPN carezca de rutas inversas. Igual para IPv6: ip -6 rule. En WireGuard, AllowedIPs filtra y fija rutas. Divide AllowedIPs en prefijos exactos para split. En iptables/nftables usa marcas y tablas, pero documenta el orden para no olvidar por qué el navegador va por un camino y curl por otro un mes después.

macOS: orden de servicios, ifscope y prioridades del resolvedor

En macOS la ruta depende del service order: los servicios más altos ganan. Se ajusta con interfaz o networksetup. Además, hay rutas ligadas a ifscope, donde el sistema elige interfaz para un destino. Para diagnóstico, route -n get <dirección> muestra interfaz y gateway. Si la VPN debe ser «principal» en algunas subredes, súbela en el orden y pon rutas específicas.

El DNS en macOS merece atención aparte: scutil --dns muestra escenarios split donde dominios internos se resuelven con DNS corporativo y el resto con públicos. Si el orden falla, tendrás errores misteriosos: acceso por IP pero no por nombre. Se soluciona con búsqueda y orden de dominios, reordenando resolvedores y definiendo qué interfaz usa qué dominio. En 2026 muchos clientes corporativos para macOS configuran reglas por dominio automáticamente, pero siempre es útil verificar manualmente.

Gateways, NAT y enrutamiento asimétrico

Gateway por defecto: captura del default y kill switch

Cuando VPN captura 0.0.0.0/0 es típico full tunnel. Pero hay implementaciones creativas: en vez de una default, añaden 0.0.0.0/1 y 128.0.0.0/1, dividiendo el mundo en dos y enviando ambos por túnel. Astuto y compatible. El riesgo surge si el default local no se desactiva y la ruta escogida cambia según métricas, causando internet caótico. Lo mejor es fijar prioridades claras o usar kill switch que bloquee tráfico fuera del túnel. Pero ojo: kill switch puede causar “problemas de internet” si el túnel falla.

Los gateways dobles y multi-WAN complican las cosas: con dos proveedores y un VPN, la ruta inversa puede salir por un enlace diferente. En routers se resuelve con policy routing y marcas; en hosts, con configuración precisa de métricas y simetría. Lo clave es que el paquete salga por donde entró. Si no, firewalls stateful descartan respuestas “extrañas”. En logs verás mensajes curiosos: “¿Por qué funciona ping pero no la app?”

NAT-T, hairpin y simetría en la devolución

IPsec sobre NAT (NAT-T) es estándar. Pero si el cliente está tras un carrier-grade NAT y el servidor con firewall estricto, a veces se necesita «mantener vivo» el enlace: keepalive, fijar puertos salientes y tiempos suaves. El hairpin NAT (cuando accedes a servicios internos vía IP externa) suele romperse con VPN: cliente entra al túnel, el servidor responde hacia afuera y la ruta inversa se pierde. Solución: DNS locales para dominios internos y evitar hairpin donde no necesario.

ECMP y balanceo en múltiples enlaces pueden causar asimetría: paquetes del mismo flujo van por rutas distintas. Algunos firewalls internos no soportan “vida al límite” y cortan conexión. Si el tráfico VPN pasa por varios proveedores, activa stickiness por origen o 5-tuple, y verifica rutas inversas. La simetría es fundamental para TCP, especialmente con inspección en el camino.

Tráfico unidireccional: rp_filter, rutas inversas y firewalls

En Linux rp_filter puede descartar paquetes si la ruta inversa no coincide con la esperada. En setups complejos de PBR esto duele: la consulta salió por tabla 100 (VPN) y la respuesta por main (internet), y el kernel corta. Solución: poner rp_filter en modo loose o garantizar simetría. Windows y macOS también tienen protección contra spoofing, y firewalls pueden bloquear flujos dudosos con rutas inconsistentes.

Revisa firewalls e inspección de apps: SSL-VPN, proxies sobre 443, DPI pueden interferir inesperadamente y cortar fragmentos no estándar. A veces basta desactivar la inspección “inteligente” temporalmente para ver si desaparece el problema. Si sí, define excepciones para tráfico VPN y reintegra la inspección con reglas más precisas.

Split tunneling vs Full tunnel: cómo elegir y configurar sin dolores

Cuándo split tunneling es tu mejor aliado

El split tunneling ahorra ancho de banda, reduce latencias a servicios públicos y descarga los concentradores VPN. En 2026 es especialmente valioso: videoconferencias, CDN, SaaS requieren salidas locales. Ejemplo sencillo: por VPN van solo 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 y dominios internos; el resto de internet directo. Usuarios felices, admins también si las rutas y DNS están bien configuradas. Riesgo: menor control del tráfico externo, hay que pensar en DLP y filtrado local.

Un split correcto usa prefijos precisos y DNS ajustado. Configura forwarding condicional para que nombres internos no “escapen” a resolvedores públicos. En WireGuard maneja AllowedIPs con cuidado. En OpenVPN desactiva redirect-gateway y empuja rutas específicas. En IKEv2 define bien selectores y listas de inclusión. Ten excepciones para bancos, servicios estatales o apps sensibles que por política corporativa deban ir siempre por túnel o siempre locales.

Cuándo full tunnel es adecuado y seguro

Full tunnel es para cuando cumplimiento y seguridad importan más que velocidad: datos críticos, regulaciones estrictas, perímetros controlados. Capturas todo el tráfico, habilitas filtrado e inspección en perímetro, tienes control centralizado. Es seguro y sin sorpresas, si la capacidad y MTU están bien. Además, no habrá fugas DNS ni conflictos con políticas locales. En 2026 muchos SSL-VPN funcionan sobre QUIC y mantienen buen rendimiento incluso con full tunnel.

Desventajas: mayor carga en concentradores y potencial aumento de latencias. Una opción intermedia es “full inteligente”: todo pasa por túnel pero el gateway autoriza local breakout para categorías como video y CDN. O arquitectura SASE: los clientes se conectan al punto de presencia más cercano donde se aplican políticas y sale a internet. Hay que planificar capacidad y monitorear métricas: si el túnel se satura, los usuarios lo notan rápido.

Patrones de diseño: listas de inclusión y exclusión, DNS split y PAC

Define claramente listas de inclusión y exclusión. Las de inclusión sirven para split, sabes qué redes van por VPN. Las de exclusión para full, se quitan categorías ruidosas. Para DNS usa split-horizon: zonas internas con resolvedores corporativos, resto con públicos, preferiblemente con DoH/DoQ si la política lo permite. Otro truco es usar archivos PAC para proxies, asegurando que apps web vayan por la ruta correcta en escenarios mixtos.

Documenta todo en playbooks: “si añades un SaaS nuevo, sigue estas reglas; si se crea un VPC, añade este prefijo y verifica rutas inversas”. Ahorras horas en el futuro. Y sí, incluye tests: un set pequeño de curl, dig y traceroute que corran automáticamente tras cambios; esa es la garantía que salva en la primera crisis.

Casos prácticos: routers domésticos, nubes y trabajo remoto

Conflictos RFC1918: cuando todos usan 10.0.0.0/8 y nadie tiene culpa

El empleado se conecta desde casa con red local 10.0.0.0/24 y la empresa usa 10.0.0.0/8. En la tabla hay una ruta específica 10.10.20.0/24 por VPN y otra general 10.0.0.0/8 por gateway local. Si la métrica del general es menor, gana la ruta local y los paquetes evitan el túnel. Diagnóstico simple con route print o ip route y pings a IPs internas. Solución: subir la métrica de la ruta local, añadir prefijos más específicos en VPN o, en casos extremos, usar NAT en los extremos para evitar solapamientos.

En el largo plazo es mejor abandonar el “colchón” 10.0.0.0/8 por direccionamiento ordenado y segmentado. En 2026 muchos migran a bloques bien definidos y documentados en un repositorio único. Si la migración es lenta, usa policy routing y SNAT en gateway: el tráfico a subredes conflictivas fuerza VPN, el resto local. No olvides rutas inversas: los servidores deben saber responder a clientes con IPs no estándares.

Nubes: AWS, Azure, GCP — P2S, BGP y rutas entre VPC

El clásico dolor de cabeza: direcciones diferentes en varias nubes. Entre VPC/VNet hay peerings, hubs de tránsito, firewalls, y encima añades VPN P2S para empleados. Si las rutas no se anuncian con cuidado, algunas subredes serán “invisibles” para el cliente. La solución es control centralizado: usa BGP donde puedas o exporta rutas estáticas desde la nube a concentradores VPN con filtros claros. Y controla prioridades en el cliente: si recibe default por VPN, la ruta inversa desde la nube debe volver por el mismo concentrador.

Otro caso es CIDR superpuestos entre nubes. Aquí o reencaminas con el tiempo o usas NAT temporalmente. En escenarios críticos activa trazas en cada salto: del cliente a VPC y vuelta. MTR a IP interna en nube y tcpdump en interfaz de túnel y firewall de nube para detectar pérdidas. Cuando tienes toda la foto, la solución llega sola: ajusta anuncios, cambia métrica o repára ruta inversa.

Redes móviles y “IPv6-only”: NAT64, DNS64 y CGNAT

Los proveedores móviles suelen dar solo IPv6 y usan NAT64/DNS64 para salir a IPv4. Conectar VPN sobre esta pila funciona, pero hay matices. Si tu VPN ignora IPv6, el tráfico puede evadir el túnel por v6 y servicios se comportan raro. La solución es soporte completo IPv6 en VPN: añade prefijos, revisa rutas y activa filtros. Configura DNS para resolver correctamente recursos IPv4 internos incluso con DNS64.

CGNAT tras el cliente rompe túneles con timeouts agresivos y sin keepalive. En WireGuard pon PersistentKeepalive; en IKEv2 checa DPDP/DPD y lifetimes. Si tu VPN usa QUIC sobre 443, pruébalo: suele funcionar mejor. Y si una app funciona por nombre pero no por IP, revisa split DNS: puede estar yendo a un resolvedor incorrecto fuera del túnel, aunque a través del corporativo todo está bien. Es sutil pero común.

Herramientas 2026: observabilidad, telemetría y novedades

eBPF y telemetría en tiempo real: vemos todo el tráfico

En 2026 eBPF es mainstream no solo en clusters sino en estaciones de trabajo. Permite identificar qué proceso creó un socket, qué ruta eligió y dónde se perdió un paquete. Herramientas como Cilium Hubble para servidores y agentes ligeros en hosts ayudan a captar casos complejos de PBR y asimetría. ¿Qué nos aporta? Por fin vemos que el navegador mandó tráfico por VPN y la utilidad de actualización directo por internet porque fwmark y tabla 200 atraparon el flujo.

En Windows avanza pktmon y la integración con logs de red. En macOS hay perfiles por aplicación más cómodos y en Linux scripts bpftrace ayudan a detectar “quién va por dónde”. Súmale dashboards centralizados: latencias en túnel, errores MTU, proporción de tráfico split/full, dominios top. Con visualizaciones, el típico “no me funciona” se vuelve “ayer a las 11:42 el 30% de clientes perdió PMTUD en enlace al Lejano Oriente”.

Tests sintéticos y health checks: no esperamos a que todo falle

Implementa pruebas sintéticas: pings a subredes clave, HTTPS a portales internos, consultas DNS a zonas necesarias, todo desde distintos puntos y políticas. Que se ejecuten cada minuto y alerten ante anomalías. En el cliente, un agente ligero con lista de hosts y destinos. En concentradores, health check API con estado de túneles, tiempos de reconexión y errores de autenticación. Alertas bien configuradas ahorran nervios y tiempo.

Además, usa “rutas canario”: varios clientes test reciben configs antes que el resto. Si falla algo, no afectará a todos. Es práctica común en DevOps y funciona igual en redes. Mantén un registro de cambios, quién actualizó qué y cuándo, y facilita rollback con un clic. Transparencia no es lujo, es la mejor defensa contra errores humanos.

Ayuda inteligente y sugerencias: de LLM a asistentes en clientes VPN

No todos aman la “IA para todo”, pero en la vida real ayuda. Un asistente de consola que analiza salidas de ip route y traceroute para señalar conflictos de métricas puede ser tu salvación a las tres de la madrugada. Funciona localmente, sin llamadas externas. Ejemplo: detecta dos rutas 10.20.0.0/16 y 10.20.5.0/24 con métrica menor en /16; sugiere subir su métrica o añadir ruta más específica. O: DNS resolver para internal.corp apunta a servidor público; recomienda forwarding condicional a corporativo.

Muchos clientes VPN ya cuentan con chequeos integrados en 2026: diagnóstico automático MTU, test de DNS leak y validación de listas split antes de aplicar. Si el cliente se queja, escúchalo. Estas pruebas detectan problemas que solo descubrirías en producción tras quejas. Y sí, activa logs detallados. Un log silencioso nos deja adivinar; un log activo nos da hechos.

Seguridad, rendimiento y ajustes finos

MTU, MSS clamping y agujeros negros PMTUD

Un MTU demasiado grande en el túnel provoca congelamientos extraños. La página carga a medias y se detiene. La solución es elegir bien el MTU y activar MSS clamping para TCP. En Linux se establece en nftables/iptables bajando MSS a valor seguro (1360-1380 para la mayoría de túneles UDP). Revisa PMTUD: si bloquean ICMP en el camino, el mecanismo “inteligente” no funcionará. A veces se arregla fijando MSS rígidamente, a veces activando ICMP en firewalls. Haz tests A/B: antes y después. La diferencia suele ser clara.

En redes con QUIC y HTTP/3 sobre 443 la sensibilidad a MTU es distinta, pero el problema persiste. Cuando el túnel va sobre UDP, pérdida de fragmentos o bloqueo de datagramas grandes degrada calidad. Una heurística: comienza con MTU conservador y súbelo si es necesario, nunca al revés. Documenta estos ajustes en playbooks para no olvidar qué valor funcionó.

DNS: split-horizon, DoH/DoQ y orden de resolvedores

El DNS puede hacer o deshacer tu día. Si dominios internos van a resolvedores públicos tendrás NXDOMAIN o respuestas erróneas. Usa split-horizon: zonas corporativas vía resolvedores internos, resto por públicos, preferiblemente con DoH/DoQ si política lo permite. En Windows revisa orden DNS de interfaces, macOS usa scutil --dns, Linux resolvectl. Si el cliente VPN puede asignar dominios a resolvedores, actívalo.

Combatir DNS leakage es estándar en 2026. Muchos clientes verifican a dónde va realmente la consulta. Ejecuta pruebas periódicas: dominios internos por túnel, públicos según política. No olvides cachés: a veces ocultan problemas. Limpiar caché y repetir consulta es un paso simple y útil.

IPv6-first, ULA y «ojos felices» Happy Eyeballs

IPv6 ya no es “invitado de ocasión”, es el anfitrión. Si tu VPN ignora v6, tendrás bypass de políticas y comportamientos imprevisibles. Añade rutas para prefijos ULA y redes globales IPv6, asegúrate que filtros permiten puertos y protocolos necesarios. Verifica Happy Eyeballs: las apps eligen v4 o v6 según latencia. Si v6 sale fuera del túnel y v4 dentro, habrá inconsistencia. La solución es una estrategia clara: ambos stacks via VPN o un split definido con control sobre rutas y DNS.

En IPv6 no hay NAT tradicional, así que los problemas de asimetría son más visibles. Configura rutas inversas con cuidado. MTU altas en v6 son buenas solo si PMTUD funciona. Si no, vuelves a la página que carga y se congela. No dejes que pase; ten siempre un checklist a mano.

Listas de verificación, playbooks y automatización

Checklist «sin pánico»: pasos rápidos en 10 minutos

Primero: verifica conexión por IP y por nombre. Segundo: traceroute a direcciones internas y externas. Tercero: examina tabla de rutas y métricas de interfaces. Cuarto: revisa DNS y split. Quinto: inspecciona MTU y prueba reducir MSS. Sexto: captura paquetes en interfaces VPN y LAN. Séptimo: chequea ruta inversa en servidor. Octavo: temporalmente desactiva inspección “inteligente” y observa comportamiento. Noveno: compara configuración cliente y servidor VPN. Décimo: documenta hallazgos y guarda evidencias.

Este checklist parece simple, pero ahorra horas. Hazlo en order, sin saltar pasos. A veces el fallo está en el segundo punto, otras en el noveno. Lo importante es no perder el hilo y anotar resultados. Un mes después agradecerás esas notas, créeme.

Playbooks para Windows, Linux y macOS

Windows: desactiva auto-metric en interfaz VPN, configura InterfaceMetric manualmente, revisa RouteMetric para subredes conflictivas. Diagnóstico con route print y PowerShell. DNS con prioridad de interfaz y resolvedores adecuados para dominios internos. Linux: inspecciona ip rule y tablas, organiza prioridades, configura fwmark si hace falta. En WireGuard, maneja AllowedIPs con cuidado. Ajusta MSS clamping y verifica PMTUD. macOS: ordena servicios con networksetup, usa scutil --dns para resolvedor, route -n get para selección de interfaz. En todos lados, revisa logs de clientes VPN y sniffer.

No olvides patrones para cambios: archivos YAML con lista de subredes, métricas, dominios DNS y reglas. Guarda en Git, haz revisiones y prueba en clientes canario. Ante problemas, rollback con un commit. Esto ya es práctica estándar que funciona perfecto en redes. La automatización no reemplaza el cerebro, pero libera tiempo para tareas que sí lo requieren.

GitOps para rutas: verifica y aplica seguro

Infraestructura como código llegó a las rutas. Que la lista de prefijos y exclusiones esté en un repositorio. Abres un Pull Request, pruebas sintéticas se ejecutan en ambiente test y luego en canarios. Si todo va bien, los cambios se despliegan en clientes o servidores VPN. Si no, rollback y análisis. Nada de “olvidamos actualizar en la PC de Pedro y en la de María funciona”. Transparencia y repetibilidad.

Agrega validaciones estáticas: validador CIDR, evita prefijos solapados sin autorización explícita, verifica que las nuevas rutas no corten internet a usuarios. Y claro, registro “quién aprobó qué”. Así el caos se vuelve proceso manejable. Los usuarios dejan de ser beta testers en producción.

FAQ: respuestas breves a preguntas comunes

¿Por qué el internet desaparece tras conectar VPN?

Lo más común es que el cliente VPN capturó la ruta default (full tunnel) y falta o está bloqueada la ruta inversa o kill switch. Revisa tabla: ¿tienes 0.0.0.0/0, 0.0.0.0/1 y 128.0.0.0/1? ¿Qué métricas tienen? Haz traceroute a IP pública: si primer salto es dentro del túnel, el internet debería ir por VPN. Si no, revisa DNS (resolver puede apuntar a servidores internos inaccesibles) o MTU (paquetes grandes quedan atascados). Prueba rápida: baja MSS, usa DNS público temporal, verifica que kill switch no esté activo y restaura simetría de rutas.

¿Cómo resolver conflicto de subredes iguales en cliente y empresa?

Tres caminos: 1) re direccionamiento en empresa (fiable pero lento), 2) NAT temporal para subred en conflicto en borde VPN (rápido pero complejo), 3) policy-based routing con rutas precisas y métrica alta para ruta general en cliente. Empieza diagnosticando con route print o ip route para ver qué ruta gana. Añade prefijos específicos en configuración VPN para sobrepasar la general. Verifica ruta inversa en servidores y filtros firewall. Y registra el conflicto en el inventario para resolverlo definitivamente, no solo parchear mes a mes.

¿Qué elegir: split tunneling o full tunnel?

Si prioridad es seguridad y control, opta por full tunnel. Si es rendimiento y ahorro de tráfico, especialmente a servicios públicos, elige split. Alternativa es full con local breakout en gateway o enfoque SASE donde el punto más cercano aplica políticas y expide tráfico a internet. No olvides el DNS y MTU: en split mal configurados causan invisibilidad de servicios internos o fugas. Idealmente, haz pilotos canario, mide métricas y solo luego despliegue masivo. Elegir a ciegas suele terminar en rehacer.

¿Por qué los pings funcionan, pero las webs no cargan?

Ping usa ICMP, webs TCP/UDP sobre HTTP(S). Si ICMP pasa y TCP se traba, revisa MTU y MSS: probablemente los paquetes grandes se cortan y PMTUD no funciona por bloqueo de ICMP Fragmentation Needed. Otra opción: DNS; si funciona por IP pero no por nombre, mira qué resolvedor se usa y si la consulta sale fuera del túnel. Tercero: firewall o inspección SSL que bloquea tráfico inesperado (ejemplo, QUIC). Activa sniffer: si ves SYN sin SYN-ACK, examina ruta inversa y filtros en el servidor.

¿Cómo definir prioridad de interfaz y rutas de red?

En Windows desactiva auto-metric y asigna InterfaceMetric para interfaz VPN, luego pon RouteMetric para rutas clave. Revisa con Get-NetRoute y route print. En Linux, no solo ip route; ip rule puede mandar tráfico a otra tabla. En macOS configura orden de servicios con networksetup y verifica ruta con route -n get. En todos, regla: menor métrica y prefijo más largo ganan. Documenta para evitar “magia” y saber qué hay configurado.

¿Cómo diagnosticar problemas solo en IPv6?

Primero confirma que VPN soporte IPv6 y tenga rutas (como ULA y prefijos globales). Haz ping6/tracepath6 a IP interna v6, revisa ip -6 route o route print -6. Examina DNS: registros AAAA de dominios internos deben resolverse por DNS corporativo. Controla MTU: PMTUD es crucial y bloquear ICMPv6 rompe conexiones. Si app v6 va fuera del túnel por Happy Eyeballs, ajusta política para que ambos stacks coincidan: o ambos por túnel o IPv6 deshabilitado en rutas específicas. Logs del cliente VPN y sniffer definirán la causa final.