Debian 13: la red no se activa tras reinicio — lista de verificación sin florituras para systemd-networkd

El modelo mental: qué significa realmente “la red está activa”

La gente dice “la red está caída” como si fuera una sola cosa. En una máquina Debian 13 que usa systemd-networkd, “la red está activa” es una cadena de condiciones separadas:

• Enlace físico: la NIC detecta portadora, la autonegociación terminó y el controlador está estable.
• La interfaz existe y está nombrada: tu configuración coincide con el nombre real de la interfaz tras el nombrado predecible de udev.
• Direccionamiento: DHCP tiene éxito (o se aplican direcciones estáticas) y la dirección está realmente ligada a la interfaz.
• Enrutamiento: tienes una ruta por defecto (o rutas de política relevantes) y el kernel selecciona lo esperado.
• DNS: resolv.conf apunta a un servidor real, o systemd-resolved está configurado correctamente, o has proporcionado nameservers explícitos.
• Firewall: el firewall local no está silenciosamente descartando respuestas DHCP, ARP o tu propio SSH.
• Dependencias: servicios que arrancan “después de la red” no están, por error, bloqueando la propia red (sí, esto pasa).

systemd-networkd solo controla partes de esto. Configura enlaces, direcciones y rutas, y puede pasar configuraciones DNS a systemd-resolved. No negocia con tu switch. Tampoco arreglará que un módulo del kernel decida ponerse temperamenta tras una actualización de firmware.

La regla es simple: no “reinicies la red” y esperes lo mejor. Localiza qué eslabón de la cadena está roto. Arregla ese, y luego confirma el siguiente.

Guion de diagnóstico rápido (primero/segundo/tercero)

Primero: ¿es un desajuste de nombres/configuración o un conflicto de servicios?

Las fallas más rápidas son aburridas: el nombre de la interfaz cambió, o dos pilas de red están compitiendo. Confirma el nombre de la interfaz y quién la controla.

• Comprueba los nombres y el estado reales de las NIC (ip link).
• Verifica si systemd-networkd está habilitado y en ejecución.
• Busca NetworkManager, restos de ifupdown o la configuración de un bridge de contenedor que esté pisando cosas.
• Comprueba que /etc/systemd/network/*.network coincida con la interfaz correcta (por nombre o MAC).

Segundo: ¿el enlace está arriba y se aplica DHCP/dirección estática?

Si la NIC no tiene portadora o DHCP nunca termina, perderás horas persiguiendo rutas y DNS.

• Confirma portadora y velocidad/duplex negociados (ethtool).
• Consulta networkctl status para ver “configured” vs “configuring” vs “failed”.
• Lee el journal de systemd-networkd para errores y timeouts explícitos de DHCP.

Tercero: enrutamiento y DNS, en ese orden

El enrutamiento es la diferencia entre “puedo hacer ping a mi gateway” y “puedo alcanzar cualquier cosa”. DNS es la diferencia entre “puedo alcanzar 1.1.1.1” y “puedo alcanzar cualquier cosa por nombre”. No los inviertas.

• Verifica la ruta por defecto y la IP origen seleccionada (ip route, ip route get).
• Verifica la ruta del resolvedor (resolvectl status y el enlace real de /etc/resolv.conf).
• Solo entonces prueba conectividad saliente y resolución de nombres.

Consejo operativo: Cuando estás en la consola a las 3 a. m., quieres una narrativa única: “Enlace bueno → dirección presente → ruta presente → DNS correcto.” Todo lo demás son sensaciones.

Datos interesantes y contexto histórico (dejarás de cometer los mismos errores)

1. Los nombres de interfaz predecibles no siempre fueron por defecto. En sistemas Linux antiguos se usaba eth0/eth1; el nombrado moderno basado en udev intenta ser estable ante reordenos, pero cambios de firmware/topología PCI aún pueden renombrar interfaces.
2. Históricamente Debian usaba ifupdown. Durante años, /etc/network/interfaces gestionó la red. Muchas roturas “misteriosas” son solo supuestos de configuración heredados de esa época.
3. systemd-networkd es intencionadamente minimalista. Está diseñado para servidores y contenedores: menos piezas móviles, configuración más declarativa, menos magia de escritorio.
4. systemd-resolved cambió lo que significa “configuración DNS”. Mucha gente sigue editando /etc/resolv.conf directamente y luego se sorprende de que se sobrescriba o apunte a un resolvedor stub.
5. DHCP no es solo “obtener una IP”. Los leases incluyen rutas, MTU, DNS, NTP, y pueden verse afectados por identificadores de cliente y DUIDs—detalles que aparecen tras reinicios o reinstalaciones.
6. wait-online es una decisión de política, no un requisito. systemd-networkd-wait-online puede impedir que servicios arranquen antes de que la red esté usable, pero también puede bloquear el arranque si se usa mal.
7. Netplan popularizó la configuración declarativa en otros sitios. Debian no la requiere; algunos administradores copian modelos mentales de otras distros y acaban sin configurar nada.
8. La portadora no garantiza conectividad. Un enlace puede estar “up” mientras el etiquetado VLAN es incorrecto, el puerto del switch está en la VLAN equivocada, o tu modo de bonding no coincide con la configuración del switch.

Tareas prácticas: comandos, salidas esperadas y decisiones

Estas son tareas reales que puedes ejecutar en un sistema Debian 13. Para cada una: comando, qué buscas y qué decisión tomar a continuación.

Tarea 1 — Confirma qué servicios están realmente en ejecución

cr0x@server:~$ systemctl status systemd-networkd --no-pager
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-12-28 01:07:14 UTC; 2min 11s ago
       Docs: man:systemd-networkd.service(8)

Significado: Si no muestra “active (running)”, deja de adivinar. Si está deshabilitado, tu arranque no configurará nada.

Decisión: Si está inactive/failed, ve al journal (Tarea 6) y a la validación de configuración (Tarea 8). Si está en ejecución, continúa.

Tarea 2 — Busca gestores de red en conflicto

cr0x@server:~$ systemctl is-enabled NetworkManager 2>/dev/null; systemctl is-active NetworkManager 2>/dev/null
enabled
active

Significado: Si NetworkManager está activo en un servidor que pretendías gestionar con networkd, estás en territorio de “dos capitanes manejando un barco”.

Decisión: Elige uno. Para servidores, suelo deshabilitar NetworkManager a menos que haya una razón específica. Si lo mantienes, deja de configurar networkd para las mismas interfaces.

Tarea 3 — Identifica los nombres de interfaz que existen ahora mismo

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp6s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
enp7s0           UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

Significado: Ahora sabes qué nombres puedes usar en los archivos .network. También observa cuál tiene LOWER_UP (portadora).

Decisión: Si tu configuración referencia eth0 pero tienes enp7s0, ese es tu fallo. Corrige la coincidencia (Tarea 9).

Tarea 4 — Pregunta a networkd qué cree que está pasando

cr0x@server:~$ networkctl status enp7s0 --no-pager
● 2: enp7s0
             Link File: /usr/lib/systemd/network/99-default.link
          Network File: /etc/systemd/network/10-lan.network
                  Type: ether
                 State: routable (configured)
          Online state: online
                Address: 192.0.2.10/24
                         fe80::3efd:feff:fedd:eeff/64
                Gateway: 192.0.2.1
                    DNS: 192.0.2.53

Significado: “routable (configured)” es lo que quieres. “configuring” significa que DHCP o la negociación del enlace no han terminado. “failed” significa que tu configuración no se aplicó o falló una capa inferior.

Decisión: Si no está configurada, ve a los logs de DHCP y al diagnóstico de enlace (Tareas 5–7).

Tarea 5 — Verifica enlace físico y negociación

cr0x@server:~$ ethtool enp7s0 | sed -n '1,25p'
Settings for enp7s0:
	Supported ports: [ TP ]
	Supported link modes:   1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  1000baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Significado: Si Link detected: no, deja de culpar a DHCP. Tienes un problema de cable/switchport/VLAN/controlador. Si la velocidad es 10Mb/s inesperadamente, podrías tener problemas de cableado que causan timeouts intermitentes de DHCP.

Decisión: Arregla L1/L2 primero. Si el enlace está bien, procede a DHCP/direcciones.

Tarea 6 — Lee los logs de networkd de este arranque (la verdad, no sensaciones)

cr0x@server:~$ journalctl -u systemd-networkd -b --no-pager -n 80
Dec 28 01:07:15 server systemd-networkd[412]: enp7s0: DHCPv4 client: started
Dec 28 01:07:18 server systemd-networkd[412]: enp7s0: DHCPv4 address 192.0.2.10/24, gateway 192.0.2.1 acquired
Dec 28 01:07:18 server systemd-networkd[412]: enp7s0: Gained carrier

Significado: Buscas errores claros: “no carrier”, “DHCPv4 lease lost”, “could not set address”, “link is not managed”.

Decisión: Si ves “link is not managed”, tu coincidencia es incorrecta (Tarea 9). Si DHCP hace timeout, continúa con las Tareas 7 y 11.

Tarea 7 — Verifica el estado del cliente DHCP y detalles del lease

cr0x@server:~$ networkctl status enp7s0 --no-pager | sed -n '1,120p'
● 2: enp7s0
                 State: configuring (configuring)
          Online state: unknown
                Address: fe80::3efd:feff:fedd:eeff/64

Significado: Solo una dirección link-local IPv6 normalmente significa que DHCPv4 no tuvo éxito y no existe IPv4 estática.

Decisión: Si está atascado en configuring, captura tráfico DHCP (Tarea 11) y revisa firewall/bridge/VLAN.

Tarea 8 — Valida que tus archivos de networkd existan y sean sensatos

cr0x@server:~$ ls -l /etc/systemd/network
total 8
-rw-r--r-- 1 root root 210 Dec 27 22:10 10-lan.network
-rw-r--r-- 1 root root 120 Dec 27 22:10 10-lan.link

Significado: Si este directorio está vacío, networkd hará muy poco a menos que confíes en el comportamiento DHCP por defecto (lo cual no es un plan; es una sensación).

Decisión: Abre los archivos y confirma criterios de match y ajustes DHCP/estáticos (Tarea 9).

Tarea 9 — Confirma que tus reglas de match coinciden realmente con la NIC que tienes

cr0x@server:~$ sed -n '1,120p' /etc/systemd/network/10-lan.network
[Match]
MACAddress=3c:fd:fe:dd:ee:ff

[Network]
DHCP=yes
IPv6AcceptRA=yes

Significado: Coincidir por MAC es robusto frente a renombres de interfaz. Coincidir por Name=enp7s0 está bien hasta que un cambio de BIOS/PCI lo renombre. Elige tu veneno.

Decisión: Si tu match no coincide, networkd ignora el archivo. Corrige el match y reinicia networkd (Tarea 10).

Tarea 10 — Reinicia networkd y observa cómo aplica la configuración en vivo

cr0x@server:~$ systemctl restart systemd-networkd
cr0x@server:~$ journalctl -u systemd-networkd -n 30 --no-pager
Dec 28 01:10:02 server systemd-networkd[615]: enp7s0: Link UP
Dec 28 01:10:02 server systemd-networkd[615]: enp7s0: DHCPv4 client: started
Dec 28 01:10:05 server systemd-networkd[615]: enp7s0: DHCPv4 address 192.0.2.10/24, gateway 192.0.2.1 acquired

Significado: Si el reinicio lo arregla, probablemente tienes una carrera de arranque (retraso en la inicialización del firmware, disponibilidad del controlador o mal uso de wait-online) más que un error de configuración permanente.

Decisión: Si solo falla en el arranque, corrige el orden con la política wait-online y la estabilidad del driver/firmware (ver sección de listas de verificación).

Tarea 11 — Captura paquetes DHCP para demostrar si existen respuestas

cr0x@server:~$ timeout 15 tcpdump -ni enp7s0 -vvv 'udp port 67 or udp port 68'
tcpdump: listening on enp7s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0x0, ttl 64, id 42121, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:fd:fe:dd:ee:ff, length 300, xid 0x6a2c9f10, Flags [none]
IP (tos 0x0, ttl 64, id 1242, offset 0, flags [none], proto UDP (17), length 342)
    192.0.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, xid 0x6a2c9f10, yiaddr 192.0.2.10, length 314

Significado: Si ves requests pero no replies, el problema está aguas arriba (VLAN del switch, relay DHCP, firewall, seguridad de puerto). Si ves replies pero networkd aún no configura, es local (firewall, gestor en conflicto o parseo del lease).

Decisión: Sin replies: escala al equipo de red con evidencia. Replies presentes: céntrate en la configuración del host y los logs.

Tarea 12 — Comprueba direcciones y rutas como las ve el kernel

cr0x@server:~$ ip -4 addr show dev enp7s0
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.0.2.10/24 brd 192.0.2.255 scope global dynamic enp7s0
       valid_lft 86368sec preferred_lft 86368sec
cr0x@server:~$ ip route
default via 192.0.2.1 dev enp7s0 proto dhcp src 192.0.2.10 metric 1024
192.0.2.0/24 dev enp7s0 proto kernel scope link src 192.0.2.10

Significado: No tener ruta por defecto significa “solo LAN local”. Una ruta por defecto equivocada significa “ruleta de conectividad”. Las métricas importan si tienes múltiples uplinks.

Decisión: Si falta la ruta por defecto, corrige las opciones DHCP o establece un gateway estático en el archivo .network. Si es incorrecta, revisa clientes DHCP múltiples o múltiples configuraciones aplicándose.

Tarea 13 — Confirma la ruta del resolvedor (y deja de editar el archivo equivocado)

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 27 22:10 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53

Significado: Si resolvectl no muestra servidores DNS, tienes enrutamiento pero no resolución de nombres. Si /etc/resolv.conf apunta a un archivo estático antiguo mientras systemd-resolved está habilitado, probablemente estás depurando la ruta equivocada.

Decisión: Decide si quieres usar resolved. Si sí, aliméntalo con DNS vía networkd. Si no, desactívalo y gestiona /etc/resolv.conf explícitamente.

Tarea 14 — Confirma qué significa “online” en tu sistema (wait-online)

cr0x@server:~$ systemctl status systemd-networkd-wait-online --no-pager
● systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: enabled)
     Active: active (exited) since Sun 2025-12-28 01:07:19 UTC; 3min ago

Significado: Si este servicio cuelga o hace timeout durante el arranque, puedes acabar con servicios retrasados o un arranque que “termina” sin red usable según dependencias de las unidades.

Decisión: Si no necesitas sincronización estricta, desactívalo. Si lo necesitas, configúralo con precisión (qué interfaz, qué estado) y evita esperar por enlaces que están ausentes intencionalmente al arrancar.

Tarea 15 — Verifica que no falte el controlador/firmware tras actualizaciones

cr0x@server:~$ dmesg -T | grep -Ei 'firmware|enp7s0|link up|link down|renamed' | tail -n 30
[Sun Dec 28 01:07:13 2025] r8169 0000:07:00.0 enp7s0: renamed from eth0
[Sun Dec 28 01:07:14 2025] r8169 0000:07:00.0 enp7s0: Link is Up - 1Gbps/Full - flow control off

Significado: Fallos de carga de firmware, resets del controlador y renombres aparecen aquí temprano. Una línea de renombrado es tu advertencia de que hacer match por nombre puede ser frágil.

Decisión: Si falta firmware, instala el paquete de firmware correcto. Si el controlador hace flapping en el enlace, considera fijar una combinación kernel/firmware conocida hasta que puedas probar.

Tarea 16 — Revisa reglas de firewall que rompan DHCP o ARP (sí, en serio)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		tcp dport 22 accept
	}
}

Significado: Una política default-drop en input sin permitir DHCP explícitamente puede romper DHCP (UDP 67/68) dependiendo de cómo estructuras reglas y hooks. También vigila rarezas en la tabla raw y filtrado de bridge.

Decisión: Si DHCP está bloqueado, permite ese tráfico en la interfaz relevante durante el arranque o usa direccionamiento estático. Manténlo explícito; “funciona la mayoría de las veces” no es una estrategia de seguridad.

Chiste #1: DHCP es como un conserje de hotel—útil, pero si llegas a las 2 a. m. y la recepción está cerrada, duermes en el vestíbulo.

Tres mini-historias del mundo corporativo (cómo falla esto en la vida real)

Incidente #1: El fallo causado por una suposición equivocada

El entorno era aburrido a propósito: una pequeña flota de servidores Debian detrás de un switch top-of-rack, reservas DHCP vinculadas por MAC y systemd-networkd gestionando todo. El equipo tenía una suposición fuerte: “los nombres de interfaz son estables en servidores”. Coincidían con Name=enp3s0 en todas partes.

Entonces un lote de hosts recibió una actualización de BIOS. Cambió la enumeración PCI lo suficiente para que la NIC pasara a otra identidad de ranura. El kernel no falló; hizo lo que siempre hace. El nombre de la interfaz cambió.

Al reiniciar, networkd arrancó limpio, leyó el archivo .network y lo aplicó a exactamente cero interfaces. Sin errores que saltaran en la consola. Sin DHCP. Sin rutas. El monitoreo mostró los hosts caídos; manos remotas insistían en que las luces del enlace parecían bien.

La solución fue técnicamente trivial: hacer match por MAC en [Match], y opcionalmente añadir un archivo .link para fijar un nombre estable si al equipo le importaba. Pero la solución real fue procedimental: dejar de confiar en “suficientemente estable”. Si una regla de match puede quedar obsoleta sin un cambio de configuración, lo hará—usualmente durante ventanas de mantenimiento cuando todos están cansados.

Incidente #2: La optimización que salió mal

Otra organización persiguió tiempos de arranque. Querían que los servicios de aplicación arrancaran más rápido tras reinicio, así que eliminaron todo lo que parecía esperar. systemd-networkd-wait-online se deshabilitó en todos lados y algunas unidades se reescribieron para arrancar antes.

Los arranques sí fueron más rápidos. También lo fueron las fallas.

Algunos servicios asumían que la red era enrutable cuando arrancaban. En arranques en frío, DHCP tardó unos segundos más porque el switchport usaba una función de seguridad que retrasaba el reenvío mientras verificaba la MAC. Los servicios se lanzaron, no pudieron conectarse a dependencias ascendentes y entraron en loop de fallos. La red se levantó momentos después—demasiado tarde para la aplicación que ya decidió que el mundo estaba roto.

El postmortem fue doloroso porque todo parecía bien cuando los ingenieros iniciaban sesión: red arriba, DHCP con lease, rutas correctas. La falla fue temporalidad. La “optimización” eliminó un punto de sincronización sin reemplazarlo por algo correcto.

Eventualmente reintrodujeron el gating, pero selectivamente: solo para hosts y servicios que realmente necesitaban red al arranque, y con un alcance más estricto (esperar una interfaz específica, no “cualquier enlace”). La penalización en el tiempo de arranque fue pequeña. La mejora de fiabilidad no lo fue.

Incidente #3: La práctica aburrida que salvó el día

Esta es mi favorita porque es agresivamente poco sexy. El equipo ejecutaba systemd-networkd con dos reglas: match por MAC y mantener una configuración mínima “conocida buena” lista para desplegar vía automatización para cada rack.

Una mañana, tras un mantenimiento planificado de energía, un conjunto de switches volvió con una configuración parcial. El relay DHCP estaba roto en una VLAN. Los servidores se reiniciaron, el enlace subió, las solicitudes DHCP salieron y no volvió nada. La red no estaba “caída”; simplemente se negaba a asignar direcciones en ese segmento.

El on-call no perdió tiempo. Usó la consola para ejecutar un tcpdump de 15 segundos en puertos DHCP, no vio respuestas y aplicó la alternativa estática predefinida (dirección, gateway, DNS). Eso dejó los hosts accesibles de inmediato, lo que permitió al equipo de red arreglar el relay sin también pelear con el problema de “no puedo ni alcanzar la máquina”.

La clave no fue heroísmo. Fue tener una vía de escape probada. Cuando ya sabes cómo se ve lo “bueno”, dejas de tratar los incidentes como misterios.

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

1) “La interfaz está UP pero no tiene dirección IPv4”

Síntoma: ip link muestra UP,LOWER_UP, pero ip -4 addr no muestra nada.

Causa raíz: DHCP no corre, respuestas DHCP bloqueadas, o la interfaz no está gestionada por networkd por fallo de match.

Solución: Confirma networkctl status y el journal de networkd. Ejecuta tcpdump para DHCP. Corrige reglas de [Match] o permite DHCP en el firewall.

2) “networkctl muestra ‘link is not managed’”

Síntoma: networkctl status enp7s0 dice not managed.

Causa raíz: No hay un archivo .network que coincida, o otro gestor se hizo cargo.

Solución: Añade un archivo .network con el match correcto; deshabilita el gestor en conflicto para esa interfaz.

3) “DHCP funciona pero no hay ruta por defecto”

Síntoma: Tienes una dirección, pero ip route no muestra default via.

Causa raíz: El servidor DHCP no suministra la opción de router, reglas de enrutamiento por política sobrescriben, o múltiples interfaces compiten.

Solución: Establece Gateway= explícitamente para configuraciones estáticas, o corrige el scope DHCP. Si es multi-homed, define métricas y reglas de routing intencionalmente.

4) “Puedo hacer ping al gateway, no puedo resolver nombres”

Síntoma: ping 192.0.2.1 funciona, ping deb.debian.org falla.

Causa raíz: DNS no configurado, stub de systemd-resolved mal conectado, o /etc/resolv.conf obsoleto.

Solución: Usa resolvectl status. Decide usar resolved o no. Asegura que DNS se establezca en networkd o que el resolv.conf está controlado por la herramienta adecuada.

5) “La red funciona tras reiniciar manualmente, falla solo al arrancar”

Síntoma: systemctl restart systemd-networkd lo deja funcionando; un reinicio no.

Causa raíz: Carrera de arranque: controlador no listo, el enlace sube tarde, el dispositivo VLAN se crea después del intento de configuración de networkd, o wait-online mal especificado.

Solución: Usa reglas de match deterministas; considera añadir una política RequiredForOnline=, ajusta wait-online para esperar la interfaz correcta e investiga el driver/firmware en dmesg.

6) “SSH muerto solo tras reinicio, consola local OK”

Síntoma: El host está funcionando, pero el acceso remoto falla hasta que alguien toca la red.

Causa raíz: El firewall se carga antes de que existan direcciones/ rutas, o una política drop bloquea DHCP/ARP/neighbor discovery durante el arranque temprano.

Solución: Haz reglas de firewall que permitan explícitamente el tráfico necesario para el arranque, o activa el firewall en etapas después de que la red esté configurada (con cuidado y dependencias claras).

Chiste #2: La frase “funciona en mi máquina” es menos reconfortante cuando tu máquina es un servidor en un rack cerrado que no puedes tocar.

Listas de verificación / plan paso a paso (de roto a aburrido)

Checklist A — Triaje inmediato en consola (10 minutos, sin ideología)

1. Lista interfaces y portadora: ip -br link. Si no hay LOWER_UP, arregla primero físico/switch/VLAN/controlador.
2. Confirma propietario: systemctl is-active systemd-networkd y revisa conflictos con NetworkManager/ifupdown.
3. Pregunta a networkd: networkctl status. Busca “not managed”, “configuring” o “failed”.
4. Lee logs: journalctl -u systemd-networkd -b. Busca timeouts DHCP, fallos de match, flapping de enlace.
5. Verifica estado del kernel: ip -4 addr y ip route. Si no hay ruta por defecto, arregla eso antes del DNS.
6. Chequeo DNS: resolvectl status y ls -l /etc/resolv.conf. Asegúrate de entender quién gestiona DNS.
7. Si DHCP está atascado: ejecuta un tcpdump de 15 segundos para DHCP. Demuestra si hay respuestas.

Checklist B — Haz tu configuración de networkd resiliente

1. Haz match por MAC (normalmente): En [Match], prefiere MACAddress= para NIC físicas. El match por nombre está bien para interfaces virtuales que controlas completamente.
2. Un archivo por interfaz: Evita “match comodín” que configure accidentalmente NICs de gestión y almacenamiento igual.
3. Sé explícito sobre DHCP vs estático: No dejes el “comportamiento DHCP por defecto” como accidente. Si quieres DHCP, dilo. Si quieres estático, escríbelo completamente (Address, Gateway, DNS).
4. Define la intención de enrutamiento en hosts multi-homed: Ajusta métricas, reglas de routing por política y evita dos rutas por defecto a menos que lo quieras de verdad.
5. Decide tu modelo DNS: O usas systemd-resolved e integras con él, o lo deshabilitas y gestionas /etc/resolv.conf. La propiedad mixta es como surgen heisenbugs.

Checklist C — Orden de arranque sin dolor autoinfligido

1. Solo usa wait-online cuando sea requisito. Si nada necesita red al inicio, no bloquees el arranque solo para sentirte seguro.
2. Si necesitas wait-online, delimítalo. Esperar “cualquier interfaz” en un host con enlaces opcionales genera bloqueos de arranque.
3. Deja de escribir servicios que asuman red instantánea. Añade reintentos/backoff. Los servicios deben sobrevivir a un DHCP lento sin deprimirse.
4. Vigila regresiones de driver/firmware. Si la red se rompe tras un cambio de kernel/firmware, confírmalo en dmesg y no dudes en revertir mientras validas.

Una cita sobre fiabilidad (una, y solo una)

La esperanza no es una estrategia. — James Cameron

No es “teoría de operaciones”. Es la diferencia entre leer logs y reiniciar hasta que “funcione”.

Preguntas frecuentes

1) ¿Debo usar systemd-networkd en servidores Debian?

Si valoras comportamiento predecible y configuración simple, sí. Es excelente para servidores, VMs y cualquier cosa que quieras configurar de forma declarativa. Si necesitas roaming Wi‑Fi interactivo o integración GUI, ahí entra NetworkManager.

2) Mi nombre de interfaz cambió tras reinicio. ¿Cómo evito que esto rompa la configuración?

No hagas match por nombre en NIC físicas. Haz match por MACAddress= en la sección [Match]. Si realmente necesitas nombres estables, usa un archivo .link para asignar un nombre basado en MAC.

3) DHCP a veces funciona, a veces no. ¿Qué debo comprobar primero?

Portadora y comportamiento del switch. Ejecuta ethtool y captura paquetes DHCP con tcpdump. Si tu host envía requests pero no ve responses, casi nunca es un “problema de Linux”.

4) ¿Por qué reiniciar systemd-networkd lo arregla?

Eso normalmente apunta a temporalidad: el enlace sube tarde, los dispositivos VLAN aparecen después del pase inicial de networkd, o otro servicio compite. La solución es eliminar la carrera (mejores reglas de match, dependencias correctas), no programar reinicios como parche.

5) ¿Debo habilitar systemd-networkd-wait-online?

Solo si tienes servicios que realmente requieren que la red esté configurada antes de arrancar. Si lo habilitas, configura tus unidades para esperar lo que necesitan—idealmente una interfaz y estado específicos—en lugar de “la red en general”.

6) El DNS está roto pero las rutas están bien. ¿Dónde miro?

Empieza con resolvectl status y ls -l /etc/resolv.conf. Confirma si usas systemd-resolved (modo stub) o un resolv.conf estático. Corrige la propiedad; luego arregla los nameservers.

7) ¿Puede nftables romper DHCP?

Sí. Especialmente con políticas default-drop y permisos incompletos. DHCP usa UDP 67/68 y broadcast; algunos conjuntos de reglas demasiado estrictos lo bloquean. Compruébalo con tcpdump y ajusta reglas explícitamente.

8) ¿Cómo depuro una falta de ruta por defecto en hosts multi-NIC?

Usa ip route y ip route get 1.1.1.1 para ver el camino elegido y la dirección origen. Luego define métricas o reglas de routing por política para que el kernel deje de “elegir” y empiece a obedecer.

9) ¿“link up” basta para considerar la red sana?

No. Link up solo significa portadora eléctrica/óptica. Aún necesitas etiquetado VLAN correcto, direccionamiento correcto, rutas correctas y DNS funcionando. “LOWER_UP” es el paso uno, no la meta final.

Conclusión: próximos pasos que agradecerás

Cuando la red de Debian 13 no se activa tras reinicio, el camino más rápido es la disciplina: verifica enlace, verifica direccionamiento, verifica enrutamiento, verifica DNS, en ese orden. Lee el journal de networkd como si te debiera dinero. No adivines.

Próximos pasos que dan resultado:

• Actualiza tus archivos .network para hacer match por MAC (u otra propiedad estable), no por nombre de interfaz salvo que controles el nombrado.
• Decide si eres una organización que usa systemd-resolved o no, y configura DNS en consecuencia. Nada de híbridos.
• Audita conflictos: solo un gestor de red debe configurar cada interfaz.
• Si las carreras de arranque son reales en tu entorno, usa wait-online selectivamente y diseña servicios con reintentos en lugar de orden mágico.
• Mantén un plan de fallback estático probado para acceso de gestión. “No podemos alcanzar la caja” no es un problema divertido de depurar cuando la caja es inalcanzable.