Debian/Ubuntu «Conectado, pero sin internet»: soluciones de enrutamiento, puerta de enlace y enrutamiento por políticas

El modelo mental: los paquetes no creen en tu interfaz

«Conectado» normalmente significa: el enlace está arriba, obtuviste una dirección IP y algo respondió al tráfico local básico. No significa que tus paquetes salientes tengan una ruta por defecto funcional, que las respuestas volverán por la misma ruta o que el DNS resuelve como lo necesitan tus aplicaciones.

En Debian/Ubuntu, «sin internet» suele reducirse a una de estas:

• Sin ruta por defecto utilizable (falta, apunta a la puerta de enlace equivocada o tiene la métrica incorrecta).
• Enrutamiento asimétrico (los paquetes salen por una interfaz, las respuestas vuelven por otra y se descartan por rp_filter, firewall o seguimiento de estado).
• Enrutamiento por políticas (las ip rules y tablas eligen una ruta distinta a la que crees).
• DNS engañoso (resolviendo a direcciones no enrutable, portales cautivos, zonas split-horizon obsoletas).
• Problemas de MTU/PMTUD (empeoran handshakes TLS, los pings funcionan, TCP se detiene).
• Efectos secundarios de VPN/túneles (un split tunnel mal configurado es simplemente un corte total con pasos extra).

Sé implacable al separar capas: enlace, IP, enrutamiento, DNS y aplicación. La mayor parte del tiempo se desperdicia cuando la gente trata estas capas como una sola vibra.

Una cita para mantenerte honesto: “La esperanza no es una estrategia.” — Gen. Gordon R. Sullivan

Broma #1: Si tu ruta por defecto falta, tus paquetes básicamente se escriben «Return to sender» a sí mismos y caminan hacia el vacío.

Guía rápida de diagnóstico (primero/segundo/tercero)

Primero: confirma qué significa “sin internet” a nivel de paquetes

1. ¿Puedes alcanzar la puerta de enlace local? Si no, para. No estás depurando “internet”. Estás depurando adyacencia L2/L3.
2. ¿Puedes alcanzar una IP pública por número? Si sí pero falla DNS, es DNS. Si no, es enrutamiento/firewall/MTU.
3. ¿Qué ruta elige realmente el kernel? No adivines. Pregunta con ip route get.

Segundo: aisla enrutamiento vs enrutamiento por políticas vs NAT

1. Revisa la ruta por defecto y las métricas (ip route).
2. Revisa las reglas de política (ip rule) y las tablas referenciadas (ip route show table X).
3. Revisa el filtrado de ruta inversa si tienes múltiples interfaces (sysctl net.ipv4.conf.*.rp_filter).

Tercero: prueba los casos “difíciles” que te engañan

1. MTU / PMTUD: si ICMP funciona pero HTTPS se queda colgado, prueba con pings “no fragmentar” y cargas más pequeñas.
2. Configuraciones proxy por aplicación: curl funciona, el navegador no—o al revés.
3. Rutas de VPN/WireGuard: AllowedIPs o rutas empujadas pueden reemplazar tu ruta por defecto.

Hechos interesantes y contexto histórico (edición enrutamiento)

• El enrutamiento por políticas en Linux no es nuevo. El diseño de tablas de enrutamiento múltiples (iproute2) existe desde finales de los 90 y aún se malinterpreta a diario.
• La “ruta por defecto” es solo una ruta. En el kernel suele ser 0.0.0.0/0 o default: no hay magia, solo la coincidencia menos específica.
• Linux elige rutas por prefijo más largo y luego por métrica. Por eso una ruta más específica puede anular tu por defecto, incluso si nunca tuviste la intención.
• El filtrado de ruta inversa (rp_filter) fue diseñado para anti‑spoofing. Rompe hosts multi‑homed si no lo ajustas. Las características de seguridad suelen hacer esto: útiles hasta que la realidad escala.
• systemd-resolved popularizó los resolutores stub en 127.0.0.53. Cuando el DNS falla, la gente culpa a “127.0.0.53” como si los hubiera insultado personalmente. Normalmente está bien; tu upstream no lo está.
• Netplan es un generador, no un demonio. Escribe configuración para NetworkManager o systemd-networkd. Depura el renderer, no la estética YAML.
• IPv6 puede “ganar” inesperadamente. Muchos clientes prefieren IPv6; si tienes enrutamiento IPv6 roto, obtendrás fallos lentos que parecen pérdida de paquetes.
• Guerras de ruta por defecto ocurren en portátiles. Conecta Ethernet, deja Wi‑Fi, añade una VPN—ahora tienes tres candidatos para “por defecto”. El kernel elegirá uno. Tu cerebro elegirá el equivocado.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente ejecuto cuando una máquina afirma estar conectada pero se comporta como si estuviera en una isla desierta. Cada tarea incluye: un comando, qué significa la salida y la decisión que tomas a partir de ella.

Tarea 1: Verificar estado del enlace y nombres de interfaz

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
ens18            UP             52:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>
wlp2s0           DOWN           10:fe:ed:aa:bb:cc <NO-CARRIER,BROADCAST,MULTICAST,UP>

Significado: ens18 está arriba y tiene carrier. wlp2s0 está administrativamente arriba pero sin carrier (no asociada).

Decisión: Centrarte en ens18. No investigues DNS de Wi‑Fi cuando el Wi‑Fi ni siquiera está conectado.

Tarea 2: Confirmar direccionamiento IP y alcance

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens18            UP             10.20.30.41/24 fe80::5054:ff:fe12:3456/64

Significado: Tienes IPv4 10.20.30.41/24. No hay IPv6 global, solo link‑local.

Decisión: Para pruebas de internet, usa IPv4 primero para mantener variables bajas. Si se espera IPv6, tienes un problema separado (RA/DHCPv6).

Tarea 3: Comprobar la ruta por defecto (el villano habitual)

cr0x@server:~$ ip route show
10.20.30.0/24 dev ens18 proto kernel scope link src 10.20.30.41

Significado: No hay default via .... Puedes hablar con la subred local y nada más.

Decisión: Arreglar la provisión de gateway (DHCP, configuración estática, netplan, NM). No toques el DNS aún.

Tarea 4: Preguntar al DHCP qué cree que te dio

cr0x@server:~$ sudo journalctl -u systemd-networkd --since "10 min ago" | tail -n 20
...ens18: DHCPv4 address 10.20.30.41/24 via 10.20.30.1
...ens18: Configured gateway: 10.20.30.1
...ens18: Setting route: dst: 0.0.0.0/0, gw: 10.20.30.1

Significado: networkd afirma que creó una ruta por defecto via 10.20.30.1, pero ip route no la mostró.

Decisión: Sospecha que otro gestor la sobreescribió, o que el enrutamiento por políticas la movió a una tabla que no es main.

Tarea 5: Mostrar rutas en todas las tablas (no solo main)

cr0x@server:~$ ip route show table all | sed -n '1,120p'
default via 10.20.30.1 dev ens18 table 100
10.20.30.0/24 dev ens18 proto kernel scope link src 10.20.30.41
local 10.20.30.41 dev ens18 table local proto kernel scope host src 10.20.30.41
broadcast 10.20.30.255 dev ens18 table local proto kernel scope link src 10.20.30.41

Significado: La ruta por defecto existe, pero está en la tabla 100, no en la tabla main.

Decisión: Revisa ip rule para ver cuándo se usa la tabla 100. Si ninguna regla coincide con tu tráfico, tienes «conectado pero sin internet».

Tarea 6: Inspeccionar reglas de política y prioridades

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.20.30.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Significado: Solo el tráfico con origen en 10.20.30.0/24 debe usar la tabla 100. Eso parece correcto—salvo que tu dirección de origen sea diferente (contenedores, policy marks, IP secundarias).

Decisión: Prueba la selección de ruta real con ip route get para una IP externa y con from explícito.

Tarea 7: Pregunta al kernel qué ruta tomará

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 dev ens18 src 10.20.30.41 uid 1000
    cache

Significado: El kernel eligió ens18 y origen 10.20.30.41. Si ves “unreachable” aquí, ya estás: el enrutamiento está roto.

Decisión: Si ip route get es sensato pero el ping falla, mira el firewall/NAT upstream. Si es insensato, arregla el enrutamiento local.

Tarea 8: Probar la accesibilidad a la puerta de enlace (adyacencia L3)

cr0x@server:~$ ping -c 2 10.20.30.1
PING 10.20.30.1 (10.20.30.1) 56(84) bytes of data.
64 bytes from 10.20.30.1: icmp_seq=1 ttl=64 time=0.341 ms
64 bytes from 10.20.30.1: icmp_seq=2 ttl=64 time=0.305 ms

--- 10.20.30.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1013ms
rtt min/avg/max/mdev = 0.305/0.323/0.341/0.018 ms

Significado: Puedes alcanzar la puerta de enlace. L2/L3 al primer salto está bien.

Decisión: Si el internet sigue muerto, tu ruta por defecto, NAT o enrutamiento upstream es el problema—no el cableado.

Tarea 9: Probar internet por IP (quita el DNS de la historia)

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=12.2 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 12.2/12.3/12.4/0.1 ms

Significado: La conectividad bruta hacia internet funciona.

Decisión: Si navegadores/apt siguen fallando, es DNS, proxy, MTU o restricciones a nivel de aplicación.

Tarea 10: Comprobar la ruta de resolución DNS (con conocimiento de systemd-resolved)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.20.30.53
       DNS Servers: 10.20.30.53 10.20.30.54

Significado: Estás usando systemd-resolved en modo stub, con servidores DNS upstream en tu LAN.

Decisión: Si la resolución falla, prueba esos servidores DNS directamente y confirma que existen rutas hacia ellos. También revisa dominios de split DNS si hay una VPN activa.

Tarea 11: Verificar resolución de nombres y distinguir SERVFAIL vs timeout

cr0x@server:~$ resolvectl query deb.debian.org
deb.debian.org: 2a04:4e42:83::644
               2a04:4e42:400::644
               151.101.130.132
               151.101.194.132
               151.101.66.132
               151.101.2.132

-- Information acquired via protocol DNS in 27.1ms.
-- Data is authenticated: no

Significado: DNS funciona y devuelve registros AAAA y A. Si esto se hubiera colgado, sospecharías alcance DNS. Si devolviera IPs equivocadas, sospecharías split‑horizon o interceptación de portal cautivo.

Decisión: Si DNS funciona pero HTTP falla, pasa a revisar MTU, proxy o firewall.

Tarea 12: Trazar la ruta real (rápido y sucio)

cr0x@server:~$ traceroute -n 1.1.1.1 | sed -n '1,8p'
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  10.20.30.1  0.410 ms  0.361 ms  0.342 ms
 2  198.51.100.1  2.103 ms  2.034 ms  2.012 ms
 3  203.0.113.9  6.821 ms  6.774 ms  6.736 ms
 4  1.1.1.1  12.504 ms  12.412 ms  12.380 ms

Significado: Tienes un camino más allá de la puerta de enlace. Si muere en el salto 1, tu gateway carece de upstream/NAT o bloquea ICMP TTL exceeded. Si muere más tarde, es enrutamiento/firewall upstream.

Decisión: Si el salto 1 está bien pero el 2+ cae, escala al equipo de red o arregla tu NAT/router upstream.

Tarea 13: Detectar agujeros negros MTU (el clásico “TLS cuelga”)

cr0x@server:~$ ping -c 2 -M do -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1400

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1007ms

Significado: Tu MTU de interfaz es 1400 (o el camino fuerza 1400). Enviar tramas de 1500 bytes con DF falla localmente.

Decisión: Ajusta la MTU apropiadamente en la interfaz o túnel. Si hay una VPN implicada, la MTU del túnel suele ser la restricción real.

Tarea 14: Revisar el filtrado de ruta inversa cuando hay multi‑homing

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.ens18.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.ens18.rp_filter = 1

Significado: rp_filter estricto está habilitado. En hosts multi‑homed con enrutamiento asimétrico, esto puede descartar respuestas válidas.

Decisión: Si necesitas multi‑homing/enrutamiento por políticas, establece rp_filter a 2 (loose) en las interfaces relevantes, o diseña rutas para evitar asimetría.

Tarea 15: Confirmar qué gestor controla la interfaz

cr0x@server:~$ networkctl status ens18 | sed -n '1,30p'
● 2: ens18
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /run/systemd/network/10-netplan-ens18.network
                          Type: ether
                         State: routable (configured)
                  Online state: online
                       Address: 10.20.30.41
                       Gateway: 10.20.30.1
                           DNS: 10.20.30.53

Significado: systemd-networkd posee esta interfaz, y netplan generó su configuración en /run/systemd/network.

Decisión: No «arregles» esto usando NetworkManager a menos que quieras configuraciones en conflicto. Haz la corrección en netplan o networkd y luego aplícala.

Fallas de enrutamiento que parecen “sin internet”

1) Puerta de enlace por defecto ausente (más común, menos dramática)

Si ip route carece de un default via, no tienes acceso a internet. Punto. Aún puedes alcanzar hosts locales on‑link, lo que alimenta la ilusión de que “la red funciona”. No funciona; está incompleta.

Vías de solución:

• Se espera DHCP: asegúrate de que el cliente DHCP corra en la interfaz correcta y no esté bloqueado. Revisa logs por “no DHCPOFFERS received”.
• Se espera estática: configura la puerta de enlace explícitamente en netplan, ifupdown o NetworkManager, pero solo en uno de ellos.

2) Dos puertas de enlace por defecto, una con métrica equivocada

A los portátiles les encanta esto. Los servidores también pueden cuando alguien añade una interfaz “temporal” y se olvida. Si tienes dos defaults, Linux elegirá según métrica (la menor tiene preferencia) y preferencias de protocolo. Tu tráfico puede salir por una interfaz que no puede hacer NAT, no llega al upstream o está puesta en cuarentena.

Las métricas no son consultivas. Son el desempate que decide si tus paquetes salen por internet funcional o por una VLAN de gestión sin ruta al mundo.

3) Existe una ruta por defecto, pero en la tabla equivocada

Esta es la trampa del enrutamiento por políticas: ip route se ve bien en la tabla 100, pero tu tráfico usa main. O viceversa. La máquina está “conectada” en el sentido de que tiene rutas en algún lugar. Pero no se usan para el tráfico que te importa.

4) Enrutamiento asimétrico + rp_filter = “a veces hace ping”

El enrutamiento asimétrico no es automáticamente incorrecto. Es incorrecto cuando tu host, o algo upstream, exige simetría. Linux con rp_filter=1 estricto descartará paquetes si la verificación de ruta inversa falla. Firewalls stateful y dispositivos NAT upstream también pueden castigar la asimetría.

Los síntomas son divertidos: SYNs salientes se envían, SYN‑ACKs regresan por una interfaz diferente y desaparecen. Algunos destinos funcionan, otros no. La gente culpa a “internet”. Internet es inocente.

5) MTU y problemas PMTUD: el corte sigiloso

Ping ICMP de 56 bytes funciona. DNS funciona. Pero HTTPS se queda colgado. SSH a veces conecta pero las transferencias de archivos se estancan. Esto suele ser fallo de Path MTU Discovery—especialmente a través de túneles o tramas jumbo mal configuradas.

Las redes modernas a menudo filtran ICMP con demasiada agresividad. Eso rompe PMTUD. Entonces los paquetes grandes se pierden y TCP pasa su día aprendiendo la impotencia.

Enrutamiento por políticas: el portero silencioso en la puerta

Si solo tuviste una interfaz y una puerta de enlace, podrías ignorar el enrutamiento por políticas para siempre. El momento en que añades una VPN, una segunda NIC, un bridge de contenedores con reglas especiales o “solo una subred más”, aparece el enrutamiento por políticas—silencioso—y empieza a decidir qué tabla se consulta para cada paquete.

Las tres piezas que debes mantener claras

• Reglas (ip rule): coinciden tráfico por origen, destino, fwmark, iif, uidrange, etc., y eligen una tabla de enrutamiento.
• Tablas (ip route show table X): contienen rutas, incluidos defaults. La tabla main es solo una de ellas.
• Selección de ruta (ip route get): lo que el kernel hace realmente para un paquete dado.

Qué sale mal en el mundo real

La regla coincide con el origen equivocado. Añades una regla “from 10.0.0.0/24 lookup 100” asumiendo que el servidor siempre usa 10.0.0.10. Entonces Docker o una IP secundaria se convierten en el origen de parte del tráfico. Ahora la mitad de tu tráfico consulta la tabla main (sin default), la otra mitad consulta la tabla 100 (tiene default). Es un corte parcial que parece aleatorio.

Las reglas se reordenan. Las prioridades importan. Una regla amplia en prioridad 100 puede sombrear una regla específica en 1000. Siempre lee prioridades como “el número más pequeño gana primero”. No es una sugerencia; es el flujo de control.

Marcas sin documentación. Alguien usó iptables -t mangle para marcar paquetes para enrutamiento especial. Luego se fue de la empresa. Ahora tu host tiene un segundo universo de enrutamiento claveado por un número hexadecimal que nadie recuerda.

Un enfoque sensato para multi‑homing

Si realmente necesitas dos uplinks (por ejemplo, una red de gestión y un uplink de producción), haz enrutamiento basado en origen intencionalmente:

• Una tabla por cada uplink con una ruta por defecto y rutas on‑link.
• Una regla por cada prefijo de origen que seleccione su tabla.
• Métricas explícitas en la tabla main para evitar defaults accidentales.
• rp_filter ajustado apropiadamente (2 es común para multi‑homed, pero entiende el trade‑off de seguridad).

Broma #2: El enrutamiento por políticas es como la política de oficina—si no sabes que existe, ya está decidiendo tu futuro.

Netplan, systemd-networkd, NetworkManager: ¿quién tiene la verdad?

Ubuntu (y a veces derivadas de Debian) puede involucrar tres capas de “configuración de red” que la gente confunde:

• Netplan: YAML que genera config para un renderer. No gestiona interfaces en tiempo de ejecución.
• systemd-networkd: un gestor de red para servidores; configurado vía archivos .network y a menudo alimentado por netplan.
• NetworkManager: común en escritorios, portátiles y algunos servidores; puede gestionar Wi‑Fi, VPN y roaming.

Elige un renderer por interfaz. No hagas split‑brain. Si NetworkManager gestiona ens18 mientras systemd-networkd también cree gestionarla, tendrás flapping de rutas que parece “internet intermitente”. No es intermitente; está siendo reescrito.

Cómo saber cuál está activo

• systemd-networkd: networkctl status muestra “configured” y apunta a un Network File.
• NetworkManager: nmcli dev status muestra el estado; las rutas suelen aparecer con proto dhcp pero eso no es exclusivo.

Netplan: las dos líneas que la gente olvida

Para IPv4 estático, necesitas una dirección y una ruta. Los nombres varían por versión; la forma moderna más portátil es definir rutas por defecto vía explícita. Los patrones de ejemplo están bien, pero en producción debes verificar qué generó netplan en /run/systemd/network y qué instaló el kernel en ip route.

Cuando cambies netplan, aplícalo de forma que no te dejes aislado en un sistema remoto. netplan try existe por una razón: te da un temporizador de rollback si pierdes conectividad.

Tres micro-historias corporativas (anonimizadas, plausibles y molestas)

Micro-historia 1: El incidente causado por una suposición equivocada

El incidente empezó como una migración rutinaria: una flota de VMs Ubuntu se movió de un clúster de hipervisores a otro. Mismas VLANs, mismos rangos IP, mismos security groups. Todo el mundo estaba tranquilo. Ese fue el primer error.

En minutos, nodos de aplicación comenzaron a fallar en los health checks. El monitoreo local podía alcanzarlos. SSH funcionaba desde el bastión en la misma subred. Pero las apps no podían llegar a endpoints de pago externos. “Conectado, pero sin internet” a escala es un tipo especial de humillación.

El equipo asumió que la puerta de enlace por defecto la entregaba DHCP, porque así se hacía en el clúster antiguo. En el nuevo clúster, el equipo de red había movido esa subred a direccionamiento estático con DHCP solo entregando IPs (sí, hay gente que hace eso), y la opción de gateway faltaba. Las VMs arrancaron con una dirección pero sin ruta por defecto.

El diagnóstico fue rápido una vez que alguien dejó de mirar dashboards y ejecutó ip route en un nodo roto. No había ruta por defecto. La solución fue igualmente aburrida: actualizar el aprovisionamiento para fijar la puerta de enlace explícitamente (netplan en este caso) y redeploy. La solución real fue cultural: dejar de asumir que “DHCP siempre te da gateway”. Normalmente lo hace—hasta que no.

Micro-historia 2: La optimización que salió mal

Un ingeniero enfocado en rendimiento decidió “limpiar el enrutamiento” en un host Debian multi‑homed. La máquina tenía dos NICs: una para gestión, otra para tráfico de producción, más una interfaz VPN usada para APIs de socios. Había acumulado años de suciedad de enrutamiento.

La optimización: poner filtrado de ruta inversa estricto globalmente (net.ipv4.conf.all.rp_filter=1) y eliminar lo que parecían “rutas duplicadas”. El objetivo era reducir riesgo de spoofing y hacer el enrutamiento determinista.

Funcionó en laboratorio. Luego llegó a producción. De repente, solo algunas llamadas externas fallaban, y solo desde algunas IPs de origen. Los fallos parecían timeouts aleatorios. Los SYNs salían por producción, pero las respuestas a veces volvían por la VPN debido a enrutamiento por políticas más rutas específicas para socios. Con rp_filter estricto, esas respuestas se descartaron como “martians”. El sistema no estaba bajo ataque; estaba mal especificado.

El postmortem fue corto y poco romántico: rp_filter estricto está bien en sistemas con una sola interfaz. En sistemas multi‑homed con caminos asimétricos, es una trampa a menos que diseñes alrededor de ello. Revirtieron a rp_filter=2 en las interfaces relevantes y documentaron la política de enrutamiento en vez de “optimizarla” hasta convertirla en misterio.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de plataforma de almacenamiento corrió un entorno mixto: Ubuntu para nodos de cómputo, Debian para algunos servicios de infraestructura, todo con un script estandarizado de “salud de red” integrado en su respuesta a incidentes.

Era aburrido. Imprimía estado de interfaces, rutas por defecto, reglas de política, estado DNS y un ip route get para una IP externa conocida. También capturaba fragmentos de journalctl para el renderer de red activo. Nadie lo celebró. Ahí sabes que era bueno.

Una tarde, un subconjunto de hosts perdió acceso a internet tras una actualización del cliente VPN. La interfaz mostraba “conectado”. El script resaltó inmediatamente el cambio real: una nueva ip rule con prioridad más alta de lo esperado, forzando la mayoría del tráfico a una tabla con una ruta por defecto vía la interfaz VPN. La VPN no se pretendía como túnel completo y no permitía egress general a internet.

Como tenían la salida del script antes y después, el equipo pudo señalar un delta concreto en la política de enrutamiento en lugar de discutir sobre “el DNS parece lento”. La reversión fue limpia. La solución a largo plazo fue fijar las reglas de la VPN solo a los prefijos de los socios. La práctica aburrida ahorró horas porque redujo el problema a hechos que el kernel no podía negar.

Errores comunes: síntoma → causa raíz → solución

• Síntoma: Se puede hacer ping a la puerta de enlace, no se puede hacer ping a 1.1.1.1
  Causa raíz: Ruta por defecto ausente o IP de gateway incorrecta
  Solución: Añadir/reparar default via <gateway> en el gestor correcto (netplan/NM/networkd). Verificar con ip route get 1.1.1.1.
• Síntoma: Ping a 1.1.1.1 funciona, pero los nombres no resuelven
  Causa raíz: Alcance de servidor DNS roto, servidor DNS equivocado o split DNS de VPN mal configurado
  Solución: Revisar resolvectl status, consultar con resolvectl query, asegurar rutas hacia los servidores DNS, arreglar opción 6 de DHCP o nameservers en netplan.
• Síntoma: DNS funciona, ping funciona, HTTPS cuelga o expira
  Causa raíz: Agujero negro MTU/PMTUD (a menudo túnel/VPN), o ICMP bloqueado upstream
  Solución: Identificar MTU de camino con pings DF; ajustar MTU de interfaz/túnel; evitar bloquear ICMP “fragmentation needed”.
• Síntoma: Funciona en Wi‑Fi, falla en Ethernet (o viceversa)
  Causa raíz: Dos rutas por defecto; métrica equivocada; enrutamiento por políticas que selecciona uplink no deseado
  Solución: Eliminar el default no intencionado, ajustar métricas o añadir reglas de política explícitas. Validar con ip route y ip route get.
• Síntoma: Solo algunos destinos fallan; otros bien; fallos “aleatorios”
  Causa raíz: Enrutamiento asimétrico + rp_filter, o filtrado selectivo upstream en un egress path
  Solución: Afinar rp_filter para multi‑homing; asegurar simetría de retorno o reglas de política correctas; confirmar con tcpdump en ambas interfaces.
• Síntoma: LAN local alcanzable; internet muerto después de conectar VPN
  Causa raíz: VPN instaló una ruta por defecto (túnel completo) o una regla de política de mayor prioridad
  Solución: Ajustar la configuración de split tunnel de la VPN para que solo los prefijos requeridos vayan por la VPN; verificar tablas de enrutamiento y prioridades de ip rule.
• Síntoma: “Funciona como root pero no como servicio” (o viceversa)
  Causa raíz: Enrutamiento por UID, fwmarks de iptables/nft o namespaces de red por servicio
  Solución: Inspeccionar ip rule por uidrange/fwmark; revisar sandboxing del servicio; confirmar con ip route get ... uid o nsenter en el namespace.
• Síntoma: La ruta existe pero el tráfico aún no sale
  Causa raíz: IP de origen equivocada elegida; selección src faltante; ARP flux; direcciones múltiples
  Solución: Fijar origen en rutas o reglas; verificar con ip route get; revisar ip addr por IPs secundarias.

Listas de verificación / plan paso a paso

Lista A: Host single‑homed (una NIC, una gateway)

1. Confirmar que la interfaz está arriba y tiene carrier: ip -br link.
2. Confirmar dirección IP y máscara: ip -br addr.
3. Confirmar que la ruta por defecto existe en main: ip route.
4. Confirmar que puedes alcanzar la puerta de enlace: ping -c 2 <gw>.
5. Confirmar que puedes alcanzar una IP pública: ping -c 2 1.1.1.1.
6. Confirmar servidores DNS y resolución: resolvectl status y resolvectl query.
7. Si HTTPS falla, probar MTU: ping -M do -s 1472 1.1.1.1 y ajustar.

Lista B: Host multi‑homed (dos NICs, quizá VPN)

1. Listar todos los defaults y métricas: ip route show | grep -E '^default'.
2. Mostrar reglas de política: ip rule. Si no esperabas reglas, felicidades: tienes reglas.
3. Mostrar todas las tablas: ip route show table all. Busca defaults en tablas que no sean main.
4. Preguntar al kernel por la ruta elegida: ip route get 1.1.1.1 y ip route get 1.1.1.1 from <source-ip>.
5. Revisar rp_filter: sysctl net.ipv4.conf.all.rp_filter. Si es estricto y hay multi‑homing, considera aflojar por interfaz.
6. Si hay VPN, verificar qué rutas empujó/instaló: ip route show antes/después de subir la VPN.
7. Validar tráfico de retorno con tcpdump en ambas interfaces si sospechas asimetría.

Lista C: Hacer la corrección sin dejar el acceso remoto inservible

1. Al usar netplan en Ubuntu, prefiere sudo netplan try primero (consola local recomendada).
2. Al cambiar rutas en una máquina remota, añade nuevas rutas antes de quitar las antiguas.
3. Mantén un camino persistente fuera de banda (consola, iLO/IPMI, consola serial cloud). “Simplemente volveré por SSH” no es un plan.
4. Después de los cambios, valida con ip route, ip rule, ip route get y una prueba real de aplicación (curl a un endpoint externo).

FAQ

1) ¿Por qué el escritorio dice “Conectado” cuando no tengo internet?

Porque “conectado” normalmente significa enlace + IP. No valida una ruta por defecto, DNS o NAT upstream. Al kernel no le importan los iconos.

2) ¿Cuál es el comando más rápido para probar que es un problema de enrutamiento?

ip route get 1.1.1.1. Si devuelve “unreachable” o elige una interfaz/origen extraño, has encontrado la categoría del problema.

3) Tengo una ruta por defecto, pero aún no hay internet. ¿Ahora qué?

Comprueba si las respuestas vuelven por el mismo camino (asimetría) y si el enrutamiento por políticas fuerza el tráfico a otra tabla. También prueba MTU si HTTPS se queda colgado.

4) ¿Por qué /etc/resolv.conf muestra 127.0.0.53? ¿Está roto?

No inherentemente. Ese es el stub de systemd-resolved. Los servidores upstream reales están en resolvectl status. Arregla el upstream o el enrutamiento hacia él.

5) ¿Cómo ocurren múltiples rutas por defecto?

DHCP en dos interfaces, Wi‑Fi más Ethernet, clientes VPN que instalan una ruta por defecto, o configuración estática encima de DHCP. Linux elegirá una según métricas y lógica de reglas/tablas.

6) ¿Cuál es la diferencia entre la tabla “main” y el enrutamiento por políticas?

El enrutamiento de la tabla main es la búsqueda por defecto. El enrutamiento por políticas añade reglas que eligen tablas distintas basadas en atributos del paquete (origen, marca, interfaz entrante, UID). Si tienes reglas, la tabla “main” puede no importar para el tráfico que te interesa.

7) ¿Debo deshabilitar rp_filter para arreglar esto?

No lo deshabilites a ciegas. En hosts single‑homed, rp_filter estricto está bien. En hosts multi‑homed, ponlo en loose (2) por interfaz si la asimetría es legítima. Mejor: diseña el enrutamiento para que sea simétrico cuando sea posible.

8) ¿Por qué el ping funciona pero apt/curl falla?

Ping es pequeño y simple. apt/curl toca DNS, TCP, TLS, proxies y a menudo paquetes más grandes. Problemas de MTU/PMTUD y DNS son las razones más comunes de esta discrepancia.

9) ¿Puede IPv6 causar “sin internet” incluso si IPv4 está bien?

Sí. Muchos clientes prefieren IPv6; un enrutamiento IPv6 roto puede producir fallos lentos. Prueba con curl -4 vs curl -6 y confirma rutas por defecto IPv6 y estado RA/DHCPv6.

10) Lo arreglé con un ip route add default manual. ¿Cómo lo hago persistente?

Pon la configuración en el gestor de red del sistema (netplan, NetworkManager, ifupdown o networkd). Los cambios manuales con ip route desaparecen al reiniciar o al flap del enlace—y volverán para perseguirte.

Siguientes pasos que realmente puedes hacer

Si no te llevas otra cosa de esto: deja de confiar en “conectado” y empieza a interrogar al kernel. Ejecuta ip route, ip rule y ip route get. Esos tres te dirán qué cree el host del mundo.

Luego haz las correcciones aburridas, en orden:

1. Asegura exactamente una ruta por defecto prevista para la clase de tráfico que te importa (o varias, pero con métricas y reglas explícitas).
2. Haz el enrutamiento por políticas explícito, documentado y mínimo. Si no puedes explicar cada ip rule, no posees tu enrutamiento.
3. Valida DNS con resolvectl y prueba por IP para separar responsabilidades.
4. Si las aplicaciones cuelgan, considera MTU culpable hasta que se demuestre lo contrario.
5. Persiste cambios en el gestor correcto (netplan/NM/networkd) y evita configuraciones en conflicto.

El networking en producción no es difícil porque los comandos lo sean. Es difícil porque los humanos siguen añadiendo “solo una cosa más” hasta que el host se convierte en una novela de elige-tu-propia-aventura. Tu trabajo es convertirlo otra vez en una lista de la compra.