El enrutador de subred de Tailscale se detuvo: revise primero la clave del dispositivo

El teléfono sigue mostrando la ruta de subred, el panel sigue listando el anuncio y nada detrás del enrutador responde. Parece una regresión de enrutamiento o del cortafuegos, así que el movimiento natural es volver a añadir la subred en el cliente. Normalmente eso no cambia nada, porque el conector perdió su identidad, no su configuración. Una clave de dispositivo caducada deja la ruta visible mientras el dispositivo deja de reenviar.

La ruta se queda y los paquetes se detienen

Tailscale trata el anuncio de rutas y la autorización del dispositivo como hechos separados. Un enrutador de subred anuncia un prefijo, los clientes lo aceptan y lo usan, y el conector transporta el tráfico. Cuando la clave del dispositivo caduca, el nodo ya no puede autenticarse con el servicio de coordinación, así que deja de participar. Los clientes pueden mantener la ruta en su tabla porque quitarla podría enviar el tráfico por un camino no previsto. Esa decisión de cerrarse ante un fallo explica el síntoma confuso: una ruta que existe y un destino que no.

El anuncio sigue siendo una afirmación cierta sobre la intención. Ha dejado de ser una afirmación sobre la capacidad.

Lea la clave y el estado del conector

Confirme el estado del conector antes de cambiar cualquier cliente. Dos salidas separan la identidad de la accesibilidad.

tailscale status
tailscale ping 100.101.102.103

La salida de estado marca el enrutador como desconectado o caducado e informa cuándo vence la clave, mientras que el ping apunta a la dirección tailnet del propio nodo y no a un servicio detrás de él. Un ping que nunca sale del cliente y una línea de estado que dice caducado son el mismo hallazgo desde dos direcciones. Compruebe si un segundo dispositivo que usa ese enrutador falla en el mismo momento, ya que un fallo compartido apunta al conector y un fallo único apunta a la aceptación de la ruta por parte de un cliente. No reutilice una dirección tailnet de notas antiguas sin confirmarla con el estado en vivo.

Vuelva a autenticarse sin cortar su propio camino

La renovación restaura la identidad, pero hacerla sobre la única sesión que funciona puede dejarlo aislado. Mantenga primero otra vía administrativa.

tailscale up --force-reauth
tailscale status --self

En un nodo con acceso a consola, --force-reauth reinicia el flujo de inicio de sesión e imprime una URL que una cuenta autorizada debe completar. En un enrutador remoto, confirme que existe una consola serie, una consola del proveedor o una vía de gestión fuera de banda antes de empezar, porque la sesión tailnet puede caer durante la renovación. Después de la renovación, verifique que el nodo está en línea y que sus rutas anunciadas siguen habilitadas. Volver a añadir el prefijo en el cliente no es un paso de renovación y no puede sustituirla.

Decida la política de caducidad para dispositivos sin supervisión

La caducidad de la clave existe para que un portátil perdido acabe dejando de funcionar, y la infraestructura sin supervisión cambia esa protección por disponibilidad. Los administradores pueden desactivar la caducidad de un dispositivo concreto, lo que encaja con un enrutador de confianza en un armario de cableado pero exige un inventario y un plan de retirada. Los dispositivos etiquetados llevan su propia identidad y su propio comportamiento de caducidad, así que la configuración de un portátil no los describe. Revise el registro real del dispositivo en lugar de confiar en un recordatorio creado hace meses.

Luego pruebe el recurso detrás del enrutador, no solo el nodo. Una clave renovada corrige la identidad, mientras que la aprobación de la ruta, la política y el reenvío todavía tienen que funcionar.