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,ufwosystemd.
1. Estado del firewall al momento del fallo
La tabla INPUT mostraba esta estructura (resumen de iptables -L INPUT -n -v --line-numbers):
| # | Target | Notas |
|---|---|---|
| 1 | ACCEPT | in tailscale0 (991 paquetes) |
| 2 | CROWDSEC_CHAIN | Pasa todo el tráfico restante |
| 3 | ts-input | Cadena de Tailscale |
| 4-9 | ufw-* | 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ótesis | Resultado |
|---|---|
CrowdSec bloqueaba el tráfico de tailscale0 | Descartada. La regla 1 acepta ese tráfico antes de llegar a CrowdSec. |
La cadena ts-input estaba debajo de las cadenas de ufw | Descartada. Estaba en posición 3, por delante de ufw. |
Falta de reglas de Tailscale en ts-input | Descartada. La cadena estaba completa (ver sección 3). |
Error de iptables/nftables en tailscaled | Descartada. El journal muestra router: default choosing iptables sin errores de firewall. |
| ufw reordenó las cadenas al arrancar | No 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:
| Mensaje | Interpretación |
|---|---|
TPM: error opening: /dev/tpmrm0 | Inofensivo: el equipo no tiene TPM. |
logtail: dial log.tailscale.com failed / bootstrapDNS ... network is unreachable | Clave: tailscaled arrancó antes de que la red estuviera lista. |
router: enumerating tailscale0 addresses ... Link not found | Normal: tailscale0 aún no existía. |
router: default choosing iptables | Correcto. |
health(warnable=ip-forwarding-off): Subnet routing is enabled, but IP forwarding is disabled | Pendiente (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.targetsolo bloquea sisystemd-networkd-wait-online.service(o equivalente) está habilitado y activo. Verificar consystemctl 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 ACCEPTaparece tras el arranque y quenc -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=1en/etc/sysctl.confy aplicar consudo sysctl -p.
Conclusiones / En resumen
- Causa raíz probable:
tailscaledinicia antes de que la red esté operativa, impidiendo la creación oportuna detailscale0y el poblamiento dets-input. - Solución efectiva: override de systemd con
After=network-online.targetyWants=network-online.target, siempre quesystemd-networkd-wait-online.serviceesté habilitado. - Reglas redundantes: la regla manual en
INPUTy la regla UFW entailscale0probablemente sean innecesarias; se confirmará tras el reinicio de validación. - 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
- Diagnóstico interno: Tailscale bloqueado tras reinicio (example.com)
- Tailscale Linux installation & systemd integration — Tailscale Docs
- systemd.unit(5) — network-online.target — freedesktop.org
- systemd-networkd-wait-online.service(8) — freedesktop.org
- iptables(8) — Linux man page
- UFW — Ubuntu Firewall documentation