Tailscale bloqueado tras reinicio: diagnóstico y solución con systemd override

·5 min de lectura·

Un servidor que tenía en cloud (server.example.com) dejó de responder tráfico entrante por la interfaz tailscale0 después de un reinicio. Desde el firewall perimetral (OPNsense) las pruebas nc -vz 100.125.218.68 22 (acceso a consola SSH) fallaban, aunque tcpdump mostraba los SYN llegando a la interfaz. La política por defecto de INPUT es DROP, por lo que cualquier regla que no acepte explícitamente el tráfico lo descarta.

Este artículo documenta el diagnóstico paso a paso, las hipótesis descartadas y la solución definitiva: un override de systemd que fuerza a tailscaled a esperar a que la red esté operativa antes de iniciar.

Advertencia: cambiar reglas de firewall o el orden de arranque de servicios de red en un servidor remoto puede dejarte sin acceso. Ten siempre una consola de emergencia del proveedor (consola serie, KVM, IPMI) antes de tocar iptables, ufw o systemd.


1. Estado del firewall al momento del fallo

La tabla INPUT mostraba esta estructura (resumen de iptables -L INPUT -n -v --line-numbers):

#TargetNotas
1ACCEPTin tailscale0 (991 paquetes)
2CROWDSEC_CHAINPasa todo el tráfico restante
3ts-inputCadena de Tailscale
4-9ufw-*Cadenas de ufw

La política de INPUT es DROP. La regla 1 solo acepta tráfico que entra por tailscale0; no es un ACCEPT global. Una búsqueda en /etc/iptables, /etc/network/if-pre-up.d y /etc/sysconfig no reveló ninguna regla de aceptación total persistente [1].


2. Hipótesis descartadas durante el diagnóstico

HipótesisResultado
CrowdSec bloqueaba el tráfico de tailscale0Descartada. La regla 1 acepta ese tráfico antes de llegar a CrowdSec.
La cadena ts-input estaba debajo de las cadenas de ufwDescartada. Estaba en posición 3, por delante de ufw.
Falta de reglas de Tailscale en ts-inputDescartada. La cadena estaba completa (ver sección 3).
Error de iptables/nftables en tailscaledDescartada. El journal muestra router: default choosing iptables sin errores de firewall.
ufw reordenó las cadenas al arrancarNo comprobada. Plausible, pero sin evidencia en los logs.

3. Contenido de la cadena ts-input (correcta)

-N ts-input
-A ts-input -s 100.125.218.68/32 -i lo -j ACCEPT
-A ts-input -i tailscale0 -j ACCEPT
-A ts-input -p udp -m udp --dport 45645 -j ACCEPT
-A ts-input -s 100.115.92.0/23 ! -i tailscale0 -j RETURN
-A ts-input -s 100.64.0.0/10 ! -i tailscale0 -j DROP

Tailscale insertó sus reglas correctamente en este arranque. La regla -A INPUT -i tailscale0 -j ACCEPT no la inserta Tailscale (solo inserta el salto a ts-input); probablemente se añadió a mano durante pruebas y no es persistente [1].


4. Journal de tailscaled: la pista decisiva

El arranque del 17/10/2026 a las 17:19:37 muestra:

MensajeInterpretación
TPM: error opening: /dev/tpmrm0Inofensivo: el equipo no tiene TPM.
logtail: dial log.tailscale.com failed / bootstrapDNS ... network is unreachableClave: tailscaled arrancó antes de que la red estuviera lista.
router: enumerating tailscale0 addresses ... Link not foundNormal: tailscale0 aún no existía.
router: default choosing iptablesCorrecto.
health(warnable=ip-forwarding-off): Subnet routing is enabled, but IP forwarding is disabledPendiente (ver sección 7).

La evidencia apunta a una condición de carrera: tailscaled inicia antes de que network-online.target se active, por lo que no puede crear la interfaz tailscale0 ni poblar ts-input a tiempo.


5. Reglas de UFW relevantes

Anywhere on tailscale0  ALLOW  Anywhere          (IPv4)
Anywhere (v6) on tailscale0  ALLOW  Anywhere (v6) (IPv6)

Estas reglas se añadieron manualmente y persisten en /etc/ufw/user.rules (copia de seguridad en /root/user.rules.bak). Siguen activas, pero no deberían ser necesarias si ts-input funciona correctamente [1].


6. Solución aplicada: override de systemd

Se creó un override para tailscaled con sudo systemctl edit tailscaled:

[Unit]
After=network-online.target
Wants=network-online.target

Luego:

sudo systemctl daemon-reload
sudo systemctl restart tailscaled

Verificación: systemctl cat tailscaled debe mostrar el bloque override.conf.

Nota importante: network-online.target solo bloquea si systemd-networkd-wait-online.service (o equivalente) está habilitado y activo. Verificar con systemctl is-enabled systemd-networkd-wait-online.service.

Tras el cambio, la conexión funciona. La prueba definitiva será un reinicio completo (sección 7).


7. Pendientes de validación tras reinicio

  • [ ] Confirmar systemctl is-enabled systemd-networkd-wait-online.service.
  • [ ] Eliminar la regla manual de INPUT si persiste: sudo iptables -D INPUT -i tailscale0 -j ACCEPT.
  • [ ] Evaluar borrar la regla UFW allow in on tailscale0 (probar tras reinicio con acceso alternativo).
  • [ ] Prueba de reinicio completa: verificar que -A ts-input -i tailscale0 -j ACCEPT aparece tras el arranque y que nc -vz 100.125.218.68 22 (acceso a consola SSH) responde desde OPNsense sin la regla manual.
  • [ ] Si se anuncian rutas de subred: activar net.ipv4.ip_forward=1 en /etc/sysctl.conf y aplicar con sudo sysctl -p.

Conclusiones / En resumen

  1. Causa raíz probable: tailscaled inicia antes de que la red esté operativa, impidiendo la creación oportuna de tailscale0 y el poblamiento de ts-input.
  2. Solución efectiva: override de systemd con After=network-online.target y Wants=network-online.target, siempre que systemd-networkd-wait-online.service esté habilitado.
  3. Reglas redundantes: la regla manual en INPUT y la regla UFW en tailscale0 probablemente sean innecesarias; se confirmará tras el reinicio de validación.
  4. Buenas prácticas: nunca confíes en reglas de firewall añadidas a mano durante troubleshooting; documenta, versiona y prueba con reinicios completos.

📚 Fuentes consultadas

  1. Diagnóstico interno: Tailscale bloqueado tras reinicio (example.com)
  2. Tailscale Linux installation & systemd integration — Tailscale Docs
  3. systemd.unit(5) — network-online.target — freedesktop.org
  4. systemd-networkd-wait-online.service(8) — freedesktop.org
  5. iptables(8) — Linux man page
  6. UFW — Ubuntu Firewall documentation

Tailscale bloqueado tras reinicio: diagnóstico y solución con systemd override

¿Te ha resultado útil?

Compártelo con tu red de contactos profesionales.

Comentarios (0)

Sé el primero en comentar.