Ubuntu 24.04 “Network is unreachable”: suero de la verdad de la tabla de enrutamiento (y soluciones)

Qué significa realmente “Network is unreachable” (perspectiva del kernel)

Cuando ves:

cr0x@server:~$ ping -c 1 1.1.1.1
ping: connect: Network is unreachable

Ese error suele ser ENETUNREACH que asciende desde el kernel. Traducción: el kernel intentó encontrar una ruta al destino y falló en el paso de enrutamiento—antes de intentar ARP/NDP, antes de tocar el cable.

La distinción importa. Si ARP falla, a menudo obtienes “Destination Host Unreachable” (desde el host local) o timeouts. Si DNS falla, obtienes “Name or service not known.” Si la búsqueda de ruta falla, obtienes “Network is unreachable.” Linux no está siendo poético; te está dando un modo de fallo específico.

Hay algunas variantes que vale la pena conocer:

• No existe una ruta coincidente en ninguna tabla de enrutamiento consultada para ese destino.
• Existe una ruta pero está marcada como unreachable, prohibit o blackhole (sí, esos son tipos de ruta reales).
• El enrutamiento por políticas (ip rules) envió la búsqueda a una tabla que no tiene ruta.
• Se seleccionó IPv6 pero falta el enrutamiento IPv6 (o RA está desactivado), por lo que v6 parece inalcanzable aunque v4 funcione.

Un cambio mental operativo: no “verifiques la red”. Verifica la decisión de enrutamiento. Linux te dirá exactamente lo que piensa. Solo tienes que preguntar de la manera correcta.

Broma #1: La tabla de enrutamiento es como los organigramas corporativos: todos aseguran que son precisos, y todos están equivocados hasta que algo se rompe.

Suero de la verdad de la tabla de enrutamiento: cómo decide Linux

Si recuerdas un comando de todo este artículo, que sea este:

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

ip route get es tu suero de la verdad. Fuerza al kernel a hacer la misma búsqueda de ruta que hará para tráfico real, e imprime el siguiente salto elegido, la interfaz de salida y la selección de dirección de origen.

Tres puntos clave que rutinariamente sorprenden a gente inteligente:

1. El kernel elige una IP de origen. Si esa IP de origen es incorrecta (subred equivocada, obsoleta o de un VRF/tabla diferente), las respuestas no regresarán. A veces el síntoma es “unreachable”, otras veces es un timeout. En cualquier caso, lee el src.
2. Las reglas pueden anular rutas. La ruta que ves en main no es necesariamente la ruta usada. ip rule puede enviar tráfico a una tabla distinta según origen, fwmark, UID u otros selectores.
3. Las métricas deciden los empates. Rutas por defecto múltiples son comunes en portátiles (Wi-Fi + VPN + Docker + herramientas “útiles”). El kernel elegirá la métrica más baja que coincida, no la que tú querías.

La pila de decisión de enrutamiento (aproximadamente)

Para la mayoría de hosts Ubuntu 24.04, el camino es así:

• La aplicación pide conectar; el kernel construye una tupla de flujo (dst, src si está ligado, mark, etc.).
• Se consulta la lista de ip rule de arriba hacia abajo. Cada regla elige una tabla de enrutamiento para la búsqueda (o dice “prohibit”).
• Se encuentra una ruta que coincide: ruta host exacta, luego prefijo más específico, luego la por defecto.
• Se resuelve el siguiente salto: ruta conectada usa ARP/NDP para el vecino L2; vía gateway usa ARP/NDP para el vecino gateway.
• Luego finalmente llegamos a “¿la interfaz está up?”, “¿hay carrier?”, “¿se resolvió el vecino?”.

Así que: si ves “Network is unreachable,” estás fallando antes de la resolución del vecino. Tu misión es encontrar qué búsqueda produjo ninguna ruta utilizable—y por qué.

Hay una idea parafraseada de Werner Vogels que encaja en operaciones: Everything fails, all the time; your job is to design for it (idea parafraseada). El enrutamiento es una de esas capas que “todo falla”—en silencio, hasta que no lo hace.

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

Cuando te despiertan a medianoche, no quieres un seminario de redes. Quieres un camino rápido al cuello de botella. Aquí está el orden que ahorra más tiempo en la práctica.

Primero: pregunta al kernel qué haría

1. ip route get <dst> para la IP de destino exacta. Si da error, falta el enrutamiento. Si elige una interfaz inesperada o IP de origen equivocada, existe la ruta pero es incorrecta.
2. ip rule para ver si el enrutamiento por políticas está desviando tu tráfico a una tabla que olvidaste.

Segundo: verifica lo básico que crea rutas

1. ip addr en la interfaz elegida: ¿dirección correcta? ¿longitud de prefijo correcta? ¿no está tentative?
2. ip route y ip -6 route: ¿tienes una ruta por defecto? ¿está en la tabla que realmente usas?
3. Estado de Netplan/NetworkManager/systemd-networkd: ¿la fuente de configuración se está aplicando realmente como crees?

Tercero: solo entonces persigue problemas L2 y externos

1. ip neigh / ip -6 neigh: ¿puedes resolver la MAC del gateway?
2. ping al gateway y a un host en enlace.
3. tcpdump solo cuando necesites pruebas, no terapia.

La guía prioriza intencionalmente el enrutamiento. “Network is unreachable” suele ser el kernel diciéndote que ni siquiera intentó enviar.

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

Estas son las tareas que ejecuto en producción. Cada una tiene tres partes: el comando, qué significa la salida típica y qué decisión tomas después.

Task 1: Reproduce el error con una IP, no con un nombre

cr0x@server:~$ ping -c 1 1.1.1.1
ping: connect: Network is unreachable

Qué significa: No es DNS. No es firewall. La búsqueda de ruta del kernel falló (o existe una ruta unreachable/prohibit).

Decisión: Ve directamente a ip route get y ip rule. No pierdas tiempo en resolv.conf.

Task 2: Pregunta al kernel por la decisión de ruta

cr0x@server:~$ ip route get 1.1.1.1
RTNETLINK answers: Network is unreachable

Qué significa: Las tablas de enrutamiento consultadas (bajo las reglas de política actuales) no producen una ruta utilizable.

Decisión: Inspecciona primero el enrutamiento por políticas (ip rule), luego inspecciona las tablas de rutas (ip route show table ...).

Task 3: Comprueba las reglas de enrutamiento por políticas (el culpable habitual de “funcionaba ayer”)

cr0x@server:~$ ip rule
0:      from all lookup local
100:    from 10.10.0.0/16 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Qué significa: El tráfico con origen en 10.10.0.0/16 usa la tabla 100. Si tu app liga esa fuente (o el kernel la elige), podrías estar enrutando en un universo distinto.

Decisión: Revisa las rutas de la tabla 100. Si está vacía o falta la ruta por defecto, encontraste tu “unreachable”.

Task 4: Muestra rutas en la tabla main (IPv4)

cr0x@server:~$ ip route
192.0.2.0/24 dev ens18 proto kernel scope link src 192.0.2.10

Qué significa: Solo tienes una ruta conectada. No hay ruta por defecto. El host puede hablar con su propia subred, y eso es todo.

Decisión: Agrega/arregla la puerta de enlace por defecto vía Netplan/NetworkManager, no a mano (a menos que estés triageando).

Task 5: Muestra rutas en una tabla específica (tabla de políticas 100)

cr0x@server:~$ ip route show table 100
10.10.0.0/16 dev wg0 proto kernel scope link src 10.10.0.5

Qué significa: La tabla 100 solo alcanza la subred VPN. Si la tabla 100 se usa para tráfico hacia internet, obtendrás “unreachable”.

Decisión: Añade una ruta por defecto a la tabla 100 (si es intencional) o corrige la regla que envía tráfico allí.

Task 6: Confirma que la ruta por defecto exista (y no compita)

cr0x@server:~$ ip route show default
default via 192.0.2.1 dev ens18 proto dhcp src 192.0.2.10 metric 100
default via 198.51.100.1 dev ens19 proto dhcp src 198.51.100.10 metric 50

Qué significa: Dos rutas por defecto. El kernel preferirá la métrica 50 (ens19). Esa puede ser una red desconectada, una VLAN de gestión o un uplink muerto.

Decisión: Decide qué interfaz debe poseer la ruta por defecto. Arregla las métricas o elimina la ruta por defecto no deseada en la capa de configuración.

Task 7: Ver direcciones y prefijos (netmask incorrecta = caos silencioso)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens18            UP             192.0.2.10/32 fe80::a00:27ff:fe4e:66a1/64

Qué significa: /32 en una interfaz LAN casi nunca es correcto a menos que hagas enrutamiento punto a punto con rutas on-link explícitas. Con /32, el kernel no considerará el gateway como on-link a menos que se le indique explícitamente.

Decisión: Corrige la longitud del prefijo en la configuración de Netplan/DHCP. Como parche temporal, puedes añadir una ruta on-link para el gateway (pero deberías sentirte ligeramente avergonzado).

Task 8: Comprueba si el gateway se considera on-link

cr0x@server:~$ ip route get 192.0.2.1
RTNETLINK answers: Network is unreachable

Qué significa: Ni siquiera se puede alcanzar la dirección del gateway. Esto es clásico de longitud de prefijo equivocada o falta de ruta conectada.

Decisión: Arregla el direccionamiento primero; el enrutamiento depende de ello.

Task 9: Si las rutas parecen correctas, revisa el estado del vecino L2 para el gateway

cr0x@server:~$ ip neigh show dev ens18
192.0.2.1 lladdr 00:11:22:33:44:55 REACHABLE

Qué significa: La resolución ARP funciona. Si aún no puedes alcanzar destinos fuera de la subred, el problema está río arriba (enrutamiento/NAT/firewall del gateway) o en el enrutamiento por políticas.

Decisión: Haz ping al gateway, luego traza decisiones de ruta más allá de él. Si el vecino está FAILED, enfócate en VLANs, configuración de puente, cableado o controles de seguridad.

Task 10: Chequeo rápido del estado del enlace y contadores del driver

cr0x@server:~$ ip -s link show dev ens18
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:4e:66:a1 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1249389   15234      0       0       0     123
    TX:  bytes packets errors dropped carrier collsns
     893221   10112      0       0       0       0       0

Qué significa: LOWER_UP indica carrier. Errores/colisiones/drops te dan una prueba rápida de problemas físicos o del switch virtual.

Decisión: Si el carrier está abajo, abandona el análisis de enrutamiento y arregla el enlace. Si el carrier está arriba y los contadores están limpios, vuelve a enrutamiento/política.

Task 11: Inspecciona la configuración generada por Netplan (captura discrepancias entre intención y realidad)

cr0x@server:~$ sudo netplan get
network:
  version: 2
  ethernets:
    ens18:
      dhcp4: true

Qué significa: Tu sistema espera DHCP para IPv4. Si no hay ruta por defecto, el servidor DHCP puede no estar enviando la opción router, o el cliente no la está aplicando.

Decisión: Confirma el renderer y los logs (NetworkManager vs systemd-networkd), luego revisa los detalles del lease DHCP.

Task 12: Identifica el renderer y la pila de red activa

cr0x@server:~$ networkctl status -n0
WARNING: systemd-networkd is not running, output will be incomplete.

Qué significa: systemd-networkd probablemente no sea el renderer activo. NetworkManager probablemente lo sea (común en escritorios; a veces también en servidores).

Decisión: No edites la herramienta equivocada. Revisa el estado de NetworkManager a continuación.

Task 13: Comprueba el estado del dispositivo y la conexión en NetworkManager

cr0x@server:~$ nmcli -f GENERAL.STATE,GENERAL.CONNECTION,IP4.GATEWAY,IP4.ROUTE dev show ens18
GENERAL.STATE:                         100 (connected)
GENERAL.CONNECTION:                    Wired connection 1
IP4.GATEWAY:                           --
IP4.ROUTE[1]:                          dst = 192.0.2.0/24, nh = 0.0.0.0, mt = 100

Qué significa: Conectado pero sin gateway. Así es exactamente como obtienes “Network is unreachable” para tráfico fuera de la subred.

Decisión: Arregla el perfil de conexión (gateway, opciones DHCP o flags “never-default”). Reiniciar la interfaz no inventará un gateway.

Task 14: Inspecciona la información del lease DHCP para la opción router

cr0x@server:~$ journalctl -u NetworkManager -b | tail -n 8
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1234] dhcp4 (ens18): option routers: (none)
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1236] dhcp4 (ens18): option subnet_mask: 255.255.255.0
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1238] dhcp4 (ens18): state changed bound -> bound

Qué significa: El servidor DHCP no proporcionó un router (gateway por defecto). Tu host se comportó correctamente; la red no lo hizo.

Decisión: Escala al equipo de red/DHCP, o configura una gateway estática si este segmento la requiere.

Task 15: Triage temporal—añade una ruta por defecto (no confundas triage con solución)

cr0x@server:~$ sudo ip route add default via 192.0.2.1 dev ens18 metric 100

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev ens18 src 192.0.2.10 uid 0
    cache

Qué significa: Has restaurado el enrutamiento por ahora.

Decisión: Implementa inmediatamente el cambio permanente en Netplan/NM. Las rutas manuales desaparecen al reiniciar y durante reinicios de red, lo cual es una sorpresa divertida a las 02:00.

Task 16: Demuestra si el enrutamiento por políticas selecciona una tabla diferente por origen

cr0x@server:~$ ip route get 1.1.1.1 from 10.10.0.5
RTNETLINK answers: Network is unreachable

Qué significa: Con origen 10.10.0.5 (probablemente una interfaz VPN), la búsqueda falla. Eso es un problema de enrutamiento por políticas, no “internet caído”.

Decisión: Arregla ip rule y las rutas de la tabla. Muchos clientes VPN instalan reglas que tienen sentido en portátiles y tonterías en servidores.

Task 17: Confirma que el filtrado por ruta inversa no se haga pasar por fallo de enrutamiento

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

Qué significa: Un rp_filter estricto puede descartar respuestas en escenarios de enrutamiento asimétrico. Típicamente causa timeouts, pero en algunos casos verás ICMPs confusos según la ruta.

Decisión: Si tienes multi-homing, enrutamiento por políticas o VRFs, considera 2 (loose) para las interfaces relevantes, pero hazlo intencionadamente y documenta por qué.

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

1) “ping: connect: Network is unreachable” a cualquier IP fuera de la subred

Síntoma: Puedes hacer ping a tu propia IP y quizá al gateway, pero no a IPs públicas.

Causa raíz: Falta de ruta por defecto (DHCP no envía opción router, configuración estática incompleta, o mismatch de renderer).

Solución: Añade la puerta de enlace por defecto correcta en el sistema de configuración real (Netplan/NM/systemd-networkd). Verifica con ip route show default y ip route get.

2) “Network is unreachable” solo para algunas fuentes / solo en contenedores

Síntoma: El host puede alcanzar el destino, pero el tráfico desde una dirección fuente específica (VPN, contenedor, NIC secundaria) resulta inalcanzable.

Causa raíz: Una regla de enrutamiento por políticas envía ese tráfico a una tabla vacía, o la tabla carece de ruta por defecto.

Solución: Audita ip rule, luego ip route show table X. Añade las rutas faltantes a esa tabla o elimina/ajusta la regla.

3) Existe ruta por defecto, pero persiste “unreachable” para un prefijo específico

Síntoma: Internet funciona, pero un rango RFC1918 o una subred corporativa es “inreachable”.

Causa raíz: Existe una ruta unreachable para ese prefijo (a veces instalada por clientes VPN, herramientas kube o agentes de seguridad) o una ruta más específica incorrecta anula la por defecto.

Solución: Busca el prefijo específico: ip route show match 10.0.0.0/8. Borra o corrige la ruta en su origen (perfil de conexión, script VPN, netplan).

4) “Network is unreachable” tras cambiar netmask/prefijo

Síntoma: Cambiaste /24 a /32 (o viceversa) y ahora el gateway es “inreachable”.

Causa raíz: El kernel no considera el gateway como on-link; la ruta conectada no cubre la IP del gateway.

Solución: Corrige la longitud del prefijo. Si realmente necesitas /32, añade una ruta on-link explícita al gateway y una ruta por defecto a través de él (y prepárate para explicarlo después).

5) Dos NICs, dos defaults, alcance intermitente

Síntoma: Funciona, luego deja de funcionar, especialmente tras un reinicio o renovación DHCP.

Causa raíz: Rutas por defecto en competencia con métricas cambiantes; el kernel elige un camino de salida distinto al esperado.

Solución: Establece métricas explícitas y fija la “propiedad” de la ruta por defecto. En servidores, sé aburrido: una ruta por defecto y rutas explícitas para todo lo demás.

6) Destinos IPv6 inalcanzables mientras IPv4 funciona (o viceversa)

Síntoma: Curl a un hostname falla rápidamente con unreachable; forzar IPv4 funciona.

Causa raíz: IPv6 tiene preferencia pero no tiene ruta por defecto (RA faltante, accept_ra desactivado o firewall que bloquea NDP/RA).

Solución: Configura correctamente el enrutamiento IPv6 (RA/DHCPv6/estático) o desactiva IPv6 para la interfaz/carga de trabajo intencionalmente. No lo dejes a medio configurar.

7) “Unreachable” dentro de un namespace / VRF pero no en el host

Síntoma: El host puede alcanzar, pero netns o VRF no pueden.

Causa raíz: Tablas de enrutamiento separadas por namespace/VRF; arreglaste la tabla main del host pero no la del namespace.

Solución: Ejecuta ip route dentro del namespace o contexto VRF y configura rutas allí.

Específicos de Ubuntu 24.04: Netplan, NetworkManager, systemd-networkd

Ubuntu tiene una idea elegante y una realidad desordenada: Netplan es un frontend declarativo, y el renderer backend es o bien NetworkManager o systemd-networkd. En Ubuntu 24.04, ambos son comunes dependiendo de si estás en escritorio, imágenes cloud, o un “servidor” que alguien instaló con GUI porque le gusta hacer clic.

Regla operativa: no arregles el enrutamiento en la capa equivocada. Si NetworkManager posee la interfaz, editar una unidad de networkd no hará nada. Si networkd la posee, los cambios con nmcli no persistirán.

Cómo saber quién posee qué

Empieza por los servicios:

cr0x@server:~$ systemctl is-active NetworkManager
active

cr0x@server:~$ systemctl is-active systemd-networkd
inactive

Decisión: Si NetworkManager está activo y networkd inactivo, trata a NM como la fuente de verdad para la configuración en runtime. Netplan aún puede generar configuración para NM.

Aplica Netplan de forma segura

Cuando cambies Netplan, usa try en máquinas remotas. Revierte automáticamente si pierdes conectividad. Esto es lo más parecido a un cinturón de seguridad en la red de Linux.

cr0x@server:~$ sudo netplan try
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 120 seconds

Decisión: Si estás conectado por SSH sobre la interfaz que cambias, usa try. Si te gusta vivir peligrosamente, usa apply y disfruta tu paseo al centro de datos.

Peligros comunes con rutas en Netplan

• Gateway ausente: DHCP no lo está proveyendo, o usaste direccionamiento estático sin routes o gateway4.
• Renderer equivocado: la configuración parece correcta pero no se aplica.
• Métricas: Netplan soporta métricas de ruta; si no las defines en sistemas con múltiples NICs, dejas las decisiones por defecto al azar.

Broma #2: Cambiar la configuración de red por SSH es una gran forma de practicar mindfulness. Te vuelves muy presente cuando el prompt deja de responder.

Trampas específicas de IPv6 para “unreachable”

Ubuntu 24.04 generalmente tiene IPv6 habilitado por defecto. Eso es bueno. La trampa es IPv6 parcial: existen direcciones, pero no enrutamiento, así que las apps que prefieren IPv6 fallan rápido.

Tarea: Ver rutas IPv6 y si existe una por defecto

cr0x@server:~$ ip -6 route show default
default via fe80::1 dev ens18 proto ra metric 100 pref medium

Qué significa: Tienes una ruta por defecto IPv6 aprendida vía Router Advertisement (RA). Si falta, el tráfico IPv6 puede ser inalcanzable.

Decisión: Si necesitas IPv6, asegúrate de aceptar RA (accept_ra), y de que el firewall no bloquee RA/NDP. Si no necesitas IPv6, desactívalo explícitamente por interfaz o en sysctl—no lo dejes medio activo.

Tarea: Fuerza IPv4 para validar la hipótesis

cr0x@server:~$ curl -4 -sS --connect-timeout 3 https://example.com
<html>...</html>

Qué significa: El camino IPv4 está bien; IPv6 es la pierna rota.

Decisión: Arregla el enrutamiento IPv6 o ajusta la selección de direcciones / desactiva IPv6 para la ruta de servicio. No culpes a “internet”.

Tarea: Comprueba el estado NDP del vecino para el gateway por defecto

cr0x@server:~$ ip -6 neigh show dev ens18
fe80::1 lladdr 00:11:22:33:44:55 router REACHABLE

Qué significa: La adyacencia L2 para IPv6 está sana. Si el unreachable persiste, concéntrate en rutas/reglas o en el upstream.

Decisión: Si el vecino está FAILED o INCOMPLETE, soluciona VLANs, filtrado de RA o características de seguridad del switch.

Enrutamiento por políticas y múltiples tablas (problemas avanzados)

El enrutamiento por políticas es donde las redes simples van a hacerse “interesantes”. También es donde “Network is unreachable” se diagnostica mal como un problema de cableado, porque alguien solo mira ip route (tabla main) y declara que está bien.

Cómo el enrutamiento por políticas crea unreachable

Imagina:

• Tienes una interfaz VPN wg0 con 10.10.0.5/16.
• Una regla dice: “From 10.10.0.0/16, lookup table 100.”
• La tabla 100 tiene solo la subred conectada de la VPN, sin ruta por defecto.

Cualquier flujo que termine con origen 10.10.0.5 ahora no puede alcanzar internet. El kernel consulta la tabla 100, no encuentra nada y dice “Network is unreachable.” Eso es un comportamiento correcto. Tu diseño está incompleto.

Tarea: Vuelca todas las prioridades de reglas (el orden importa)

cr0x@server:~$ ip -details rule
0:      from all lookup local
100:    from 10.10.0.0/16 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Qué significa: El kernel golpeará la prioridad 100 antes que main. Si coincide, main es irrelevante.

Decisión: Arregla la regla o pobla la tabla. No “añadas una default a main” y esperes lo mejor.

Tarea: Muestra tipos de ruta que bloquean el tráfico explícitamente

cr0x@server:~$ ip route show type unreachable
unreachable 10.0.0.0/8 metric 1024

Qué significa: El sistema se niega intencionalmente a enrutar ese prefijo. Esto puede ser un artefacto de hardening, un cliente VPN que “te protege”, o un parche antiguo que nunca se removió.

Decisión: Identifica quién lo instaló (conexión NM, netplan, scripts, agente de seguridad). Elimínalo en su origen, no manualmente, a menos que estés en triage de emergencia.

Tarea: Verifica selección por marcas (si usas marcado con nftables/iptables)

cr0x@server:~$ ip rule | grep -n fwmark
12:200:  from all fwmark 0x1 lookup 200

Qué significa: El tráfico marcado usa la tabla 200. Si la tabla 200 carece de ruta, los flujos marcados resultan unreachable mientras los no marcados funcionan.

Decisión: Confirma tus reglas de marcado en el firewall y asegúrate de que la tabla 200 tenga una ruta por defecto o prefijos adecuados.

Tres micro-historias del mundo corporativo (anónimas)

Incidente causado por una suposición errónea: “DHCP siempre da gateway”

En una empresa mediana, un equipo desplegó una nueva imagen Ubuntu 24.04 para agentes de build. Estas máquinas vivían en una VLAN “tools” que históricamente usaba direccionamiento estático. Alguien migró la VLAN a DHCP para reducir trabajo manual, y todos aplaudieron porque las hojas de cálculo no son infraestructura.

La imagen usó DHCP, obtuvo una dirección y reportó “connected”. Pero los builds empezaron a fallar cuando necesitaban descargar dependencias de internet. El error fue inmediato: “Network is unreachable.” Los ingenieros asumieron que el proxy estaba caído, luego culparon a DNS, luego al equipo de firewall (siempre un público favorito).

La causa real fue mundana: el scope DHCP entregó IP y máscara, pero no entregó la opción router. La mitad del parque no lo notó porque aún estaban en estático o tenían rutas cacheadas; los nuevos agentes eran los únicos lo suficientemente limpios para fallar consistentemente.

Lo que lo arregló no fue heroico. Lo confirmaron en logs (“option routers: (none)”), añadieron la opción router al scope DHCP y el problema desapareció. Tras el incidente, la lección se volvió un ítem de checklist: las nuevas subredes deben validarse para IP, máscara, router, DNS y MTU—no “DHCP funciona”.

Optimización que salió mal: “Dos defaults por redundancia”

Otra organización tenía servidores con doble homing: una interfaz en la red de producción y otra en la de gestión. Alguien decidió ser listo y añadió una ruta por defecto en la interfaz de gestión “por si la producción cae”. Redundancia, ¿no?

Funcionó en horas tranquilas. Luego una ventana de mantenimiento introdujo pérdida de paquetes menor en el uplink de producción. Linux, siendo racional y poco romántico, siguió seleccionando la default de métrica más baja—que tras una renovación DHCP cambió. Algunos servidores empezaron a enviar tráfico de producción por la interfaz de gestión. El tráfico de retorno no coincidía. rp_filter descartó paquetes. Los clientes vieron fallos intermitentes que eran casi imposibles de reproducir en laboratorio.

La “optimización” no creó redundancia. Creó no determinismo. Y el no determinismo es simplemente falta de fiabilidad con traje.

La solución fue aburrida: una ruta por defecto, siempre; rutas explícitas para gestión; y métricas documentadas y fijadas en la configuración. “Redundancia” se convirtió en un diseño de enrutamiento correcto (failover con protocolos de enrutamiento o cambios monitorizados), no en un par de defaults compitiendo a ver cómo se comportan.

Práctica correcta y aburrida que salvó el día: “ip route get como procedimiento estándar”

En una compañía con fuerte uso de Kubernetes, los nodos ocasionalmente reportaban “Network is unreachable” al tirar imágenes. La primera reacción fue culpar al registro o a DNS. Pero el equipo SRE tenía una costumbre: cada queja de red empieza con ip route get.

Ese hábito dio resultado. En un nodo afectado, ip route get mostró salida por una interfaz creada por CNI, con una dirección de origen perteneciente a una subred de pods. Eso nunca debió pasar para el tráfico del host. El equipo inmediatamente pivotó a reglas de enrutamiento por políticas y encontró una regla obsoleta de un agente VPN que coincidía más ampliamente de lo previsto.

Eliminaron el agente, limpiaron la regla y añadieron una comprobación tipo unit test al provisioning de nodos: asegurar que el egress por defecto del host use la NIC primaria y la fuente esperada. Nada glamuroso—solo una barrera que atrapa la deriva antes de que sea un outage.

No fue glamuroso, pero evitó una larga madriguera de capturas de paquetes y culpas. Lo aburrido es una característica en operaciones.

Datos interesantes y puntos históricos rápidos

• Linux “iproute2” reemplazó a “net-tools” (como route, ifconfig) porque el enrutamiento moderno necesita reglas de política, múltiples tablas y mejor visibilidad.
• ip route get refleja la búsqueda FIB del kernel e incluye selección de origen—algo que las herramientas antiguas apenas mostraban.
• Las métricas de ruta no son un desempate; son la decisión cuando varias rutas coinciden. Gana la métrica más baja, aunque haga sufrir a los humanos.
• Linux soporta tipos de ruta como blackhole, unreachable y prohibit para bloquear tráfico deliberadamente en la capa de enrutamiento, no en la de firewall.
• El enrutamiento por políticas via ip rule existe desde hace décadas, ampliamente usado por ISPs y sistemas multi-homed mucho antes de que “cloud networking” lo redescubriera.
• Las rutas por defecto IPv6 a menudo vienen de Router Advertisements, no de DHCP. Bloquear ICMPv6 puede romper enrutamiento silenciosamente, no solo “ping”.
• El filtrado por ruta inversa (rp_filter) fue diseñado para mitigar spoofing pero interactúa mal con enrutamiento asimétrico a menos que se ajuste deliberadamente.
• Los namespaces de red significan que cada namespace tiene sus propias tablas de enrutamiento. Arreglar el host no arregla un namespace de contenedor, y viceversa.

Listas de verificación / plan paso a paso

Checklist A: Cuando ves “Network is unreachable” en Ubuntu 24.04

1. Reproduce con una IP: ping -c 1 1.1.1.1.
2. Ejecuta ip route get 1.1.1.1.
3. Si da error: inspecciona ip rule, luego ip route (y tablas específicas).
4. Si retorna una ruta: confirma que dev y src son lo que esperas.
5. Revisa rutas por defecto: ip route show default. Elimina ambigüedades.
6. Verifica direcciones/longitudes de prefijo: ip -br addr.
7. Comprueba el vecino hacia el gateway: ip neigh show dev <dev>.
8. Confirma qué renderer aplica la configuración: systemctl is-active NetworkManager y systemctl is-active systemd-networkd.
9. Implementa la solución en la capa de configuración propietaria (Netplan/NM/networkd), no con comandos puntuales.
10. Vuelve a probar con ip route get y una conexión real (curl -4/curl -6 según sea necesario).

Checklist B: Soluciones permanentes (elige tu herramienta, comprométete)

• Si usas Netplan + networkd: define rutas estáticas/gateway en YAML de Netplan, luego sudo netplan apply.
• Si usas Netplan + NetworkManager: edita YAML de Netplan o los perfiles de conexión NM, pero no mezcles rutas manuales ad-hoc con perfiles persistentes.
• Si tienes múltiples uplinks: establece métricas de ruta explícitas y añade rutas explícitas para redes no por defecto.
• Si usas VPNs: verifica que las tablas de enrutamiento de políticas contengan una ruta por defecto si esperas full tunnel, o rutas estrechas en caso de split tunnel.
• Si ejecutas contenedores: valida que el enrutamiento del host no se vea afectado accidentalmente por CNI, Docker o agentes de seguridad que añaden reglas/rutas.

Preguntas frecuentes

1) ¿Por qué ocurre “Network is unreachable” aun cuando la interfaz está UP?

Porque el estado del enlace no es el estado de enrutamiento. La interfaz puede estar UP con una IP válida y aun así no tener ruta por defecto, tener máscara incorrecta o reglas de política que envíen tráfico a una tabla vacía.

2) ¿Cuál es el comando más rápido para diagnosticar esto?

ip route get <destination-ip>. Si da error, falló la búsqueda de enrutamiento. Si retorna una ruta, lee dev y src y valida que tengan sentido.

3) Tengo ruta por defecto, entonces ¿por qué sigue siendo inalcanzable?

O bien una ruta más específica la anula (incluyendo unreachable/blackhole), o el enrutamiento por políticas envía la búsqueda a otra tabla. Revisa ip rule y busca rutas para el prefijo de destino.

4) ¿Cómo sé si IPv6 es la razón por la que falla mi hostname?

Forza IPv4: curl -4 o ping -4. Si IPv4 funciona y la llamada normal falla rápido, tu sistema puede estar seleccionando IPv6 sin una ruta por defecto IPv6 válida.

5) ¿Es válido añadir una ruta por defecto con ip route add default?

Es válido como triage. No es una solución duradera. Desaparecerá al reiniciar y puede ser sobrescrita por renovaciones DHCP o reinicios de red. Haz el cambio persistente en Netplan/NetworkManager/networkd.

6) ¿Cuál es la diferencia entre “Network is unreachable” y “Destination Host Unreachable”?

“Network is unreachable” normalmente significa que la búsqueda de ruta falló. “Destination Host Unreachable” suele significar que existe una ruta, pero ARP/NDP o el enrutamiento río abajo fallaron, produciendo un ICMP unreachable.

7) ¿Docker o Kubernetes pueden causar “Network is unreachable” en el host?

Sí. Añaden interfaces, rutas y a veces reglas de política. La mayoría de las veces se comportan. Cuando no lo hacen, verás entradas inesperadas en ip rule, rutas extra o selección de origen que apunta a redes CNI/Docker.

8) ¿Por qué funciona para root pero no para un usuario de servicio (o viceversa)?

El enrutamiento por políticas puede coincidir con UID (vía ip rule uidrange) o fwmarks aplicados por cgroups/iptables/nftables. Revisa ip rule y si existen reglas específicas por UID o marcas.

9) ¿Qué pasa si el gateway mismo es “unreachable”?

Eso normalmente significa que tu ruta conectada no incluye la IP del gateway (prefijo incorrecto), o la interfaz/dirección no está configurada como crees. Arregla IP/prefijo primero; el enrutamiento viene después.

10) ¿Debo desactivar rp_filter para arreglar esto?

Sólo si entiendes la historia de asimetría de enrutamiento. Los problemas de rp_filter típicamente se manifiestan como respuestas descartadas/timeouts más que fallos en la búsqueda de ruta. Ajústalo deliberadamente y documenta la razón.

Conclusión: próximos pasos prácticos

“Network is unreachable” no es un sentimiento. Es un veredicto de enrutamiento. Trátalo como tal.

La próxima vez que lo veas en Ubuntu 24.04, haz esto:

1. Ejecuta ip route get <dst> y cree en la salida.
2. Revisa ip rule antes de mirar ip route y declararte victorioso.
3. Arregla la causa raíz en la capa de configuración propietaria (Netplan/NetworkManager/systemd-networkd), no con un one-liner heroico.
4. En sistemas multi-homed, haz explícitas las métricas y la propiedad de la ruta por defecto. La ambigüedad no es redundancia.
5. Si IPv6 está habilitado, hazlo completamente correcto—o apágalo intencionalmente. IPv6 a medio configurar es una fuente recurrente de fallos rápidos.

Haz eso, y “Network is unreachable” dejará de ser un misterio y se convertirá en un compañero de trabajo útil: franco, preciso y ocasionalmente molesto.