Conectar routers detrás de NAT: alta, aprobación y reconexión en Fleetd

Conectar un servidor en la nube a un panel suele ser sencillo: instalar el programa, indicar una dirección y comprobar la conexión. Con un router doméstico aparece otra capa: quizá no tenga IPv4 pública y esté detrás del módem y de la red del operador. Reenvío de puertos, DNS dinámico o un servidor de salto pueden convertir el propio acceso en otra tarea de mantenimiento.

En la presentación de Fleetd mencioné que el agente inicia la conexión. Aquí explico su dirección, la aprobación de dispositivos y la recuperación tras una desconexión, siguiendo la implementación de v0.3.0.

Fleetd conecta tus servidores y routers a un panel. No es un servicio general de túneles ni expone automáticamente toda la LAN del router.

Invertir la dirección de la conexión

En vez de preguntar cómo encuentra el panel al router, Fleetd hace que el agente del router busque al servidor. Este ofrece una dirección accesible; el agente abre una conexión WebSocket para los informes y las solicitudes posteriores.

Tanto los agentes Linux como los situados detrás de NAT conectan hacia fleetd-server. El servidor almacena datos en PostgreSQL y el administrador utiliza su interfaz web.

El equipo administrado no necesita un puerto entrante específico para Fleetd. Tampoco hace falta que el servidor descubra la dirección pública actual de cada router antes de contactar con él.

La condición sigue siendo clara: el agente debe poder alcanzar el servidor. DNS, reglas de salida, proxies y calidad de red importan. El servidor puede usar un dominio público o una red privada accesible; una red WireGuard existente también puede aportar esa conectividad.

Funcionar detrás de NAT significa cambiar quién inicia la conexión. No evita restricciones de salida ni vuelve accesible un servidor al que nadie puede llegar.

Poder abrir el panel solo verifica una ruta

El navegador puede iniciar sesión mientras el agente falla. La interfaz y las API siguen una ruta; el agente necesita su endpoint WebSocket, por ejemplo:

wss://fleetd.example.com/agent/ws

Es un dominio de ejemplo que debe sustituirse. El proxy inverso tiene que admitir la actualización a WebSocket y no cerrar prematuramente las conexiones largas.

Si la portada funciona pero falta ese reenvío, reinstalar el agente no suele ayudar. Hay que revisar la dirección, los registros del proxy y el error del handshake.

Dentro de WebSocket, Fleetd establece una sesión cifrada Noise entre agente y servidor. El agente fija la clave pública del servidor: alcanzar una dirección no implica confiar en cualquier servicio que responda allí.

El certificado HTTPS y la identidad Noise cumplen funciones distintas. Una clave equivocada o una identidad cambiada durante una migración pueden impedir la conexión. En producción sigue siendo necesario configurar HTTPS. Noise no sustituye la protección del navegador y el servidor, como extremo de la sesión, puede leer las métricas recibidas.

Preparar el agente antes de copiar el instalador

El ejemplo Docker Compose anterior iniciaba el servidor y PostgreSQL. No generaba automáticamente paquetes firmados de agente.

Para un uso continuado, crea tu clave de publicación, compila y sube un paquete adecuado y utiliza el comando de instalación del panel. Los binarios v0.3.0 son Linux amd64 y arm64; hay que verificar la arquitectura del router.

Recomiendo empezar con permiso monitor y comprobar la conexión antes de habilitar operaciones. El comando tiene esta forma:

curl -fsSL https://fleetd.example.com/install.sh | sh -s -- --permission monitor

No copies el dominio de ejemplo. Obtén la orden desde tu propio panel y confirma su origen. El instalador necesita privilegios elevados y su procedencia forma parte de la confianza inicial. Las firmas posteriores no autentican retroactivamente ese primer script.

El script configura systemd o procd, escribe la configuración y registra el servicio. Sus claves tienen funciones diferentes:

Información	Pregunta que responde
Clave pública del servidor	¿Es el servidor Fleetd esperado?
Identidad y huella del agente	¿Qué agente solicita el alta?
Clave pública de firma de comandos	¿Autorizó la orden un firmante de confianza?
Clave pública de versiones	¿Firmó esta actualización un publicador de confianza?

Un fallo de conexión y un comando rechazado pueden pertenecer a verificaciones distintas. Cambiar una clave cualquiera no es una solución general.

Pendiente de aprobación es una etapa prevista

Al arrancar, el agente carga o genera su clave de identidad. Una identidad desconocida que completa el handshake correspondiente se registra como pendiente.

Se conservan nombre, dirección de origen y clave, pero todavía no hay una sesión normal de monitorización y comandos. Una fila pendiente sin gráficas no demuestra un fallo de recopilación.

Lee la huella desde el terminal de instalación o una conexión que ya controles y compárala con el panel. En un agente instalado con la configuración correcta:

fleetd-agent -config /etc/fleetd/agent.yaml fingerprint

Aprueba solo si coincide. No confíes en una solicitud desconocida porque su nombre resulte familiar.

La IP es una pista, no una identidad. Varios dispositivos pueden compartir salida; las direcciones cambian y el proxy influye en la dirección registrada. Nombres e IP ayudan a reconocer, pero hay que comprobar la identidad prevista del cliente.

Aprobar tampoco equivale a conceder una terminal root. Un agente monitor continúa siendo de solo monitorización. Las acciones siguen sujetas a firma y permisos locales.

Por qué aprobar no actualiza todo al instante

En v0.3.0, un agente pendiente reintenta aproximadamente cada minuto. Tras aprobarlo, normalmente espera a la siguiente conexión para iniciar su sesión y enviar métricas. No se transforma de inmediato la conexión anterior.

Si faltan datos unos segundos después, revisa el registro antes de borrar o reinstalar. Ese minuto tampoco garantiza disponibilidad: DNS, red o handshake pueden seguir fallando. Conviene distinguir la espera hasta el próximo intento de un intento realmente fallido.

Las desconexiones normales tienen otra política

Ante errores de red se utiliza espera exponencial con variación aleatoria, para evitar que todos los agentes reconecten simultáneamente cuando vuelve el servidor.

La base empieza en un segundo y aumenta hasta 60; la espera efectiva añade una cantidad aleatoria. Por tanto, no significa reconectar garantizadamente en menos de 60 segundos. Una sesión estable durante más de un minuto reinicia la base al terminar.

El servidor envía mensajes de mantenimiento de conexión. Una ausencia prolongada de recepción termina la sesión y provoca reconexión. Esto recupera el canal, no necesariamente las operaciones.

Que la máquina vuelva a estar conectada no demuestra que el comando previo terminara ni que una tarea de terminal continúe. Actualizar programas, modificar la red o reiniciar servicios puede cortar el canal. Comprueba el resultado real antes de repetir una acción por no haber recibido su mensaje final.

La vida de las tareas tendrá su artículo; aquí basta con separar recuperación de sesión y recuperación de trabajo.

Renombrar, cambiar de IP y reinstalar no son lo mismo

La identidad depende de la clave, no del nombre ni de la dirección. Volver con la misma clave desde otra IP difiere de generar una identidad nueva.

Si una reinstalación borra la clave, el mismo nombre puede aparecer como nuevo y requerir otra verificación. A la inversa, clonar un sistema ya registrado puede copiar esa identidad a otra máquina.

Dos máquinas con la misma identidad no son agentes independientes. El servidor actual cancela la conexión anterior cuando llega una nueva para la misma máquina registrada, lo que puede parecer una sucesión de desconexiones.

No distribuyas la clave privada de un agente registrado en una plantilla de sistema. Los reinicios deben conservar identidad; los equipos nuevos deben obtener identidades distintas. Copiar todo el directorio no resuelve ambos objetivos.

Borrar una máquina no impide que vuelva

Eliminarla borra el registro y su historial. Si el agente sigue funcionando, puede reaparecer como pendiente: el servidor olvidó la aprobación, pero el cliente sigue solicitando acceso.

Para cambiar la etiqueta, usa renombrar. Para dejar de administrar, detén y desinstala el agente. Para bloquear una identidad, utiliza rechazar: su clave queda bloqueada hasta que se retire el bloqueo.

La prohibición corresponde a una clave. Si se genera otra, será una identidad distinta que todavía necesitará aprobación; no es un bloqueo permanente del hardware.

El máximo actual de solicitudes pendientes es 50. Limita la cola, no constituye una defensa completa contra ataques. La exposición de red, la protección del acceso y las cuentas administrativas siguen requiriendo atención.

Diagnosticar por etapas

Síntoma	Primera revisión
No hay servicio después de instalar	Arquitectura, descarga, errores de instalación y systemd/procd
No aparece pendiente	Dirección, DNS, salida, WebSocket y clave del servidor
Pendiente sin métricas	Huella, aprobación y plazo del próximo intento
Sigue desconectado tras aprobar	Último handshake y establecimiento de sesión aprobada
Conectado, pero rechaza órdenes	Permisos, claves de firma, destino y vigencia
Reaparece después de borrarlo	Si el agente sigue activo y debe detenerse o rechazarse

En systemd:

systemctl status fleetd-agent
journalctl -u fleetd-agent -n 80 --no-pager

En OpenWrt o iStoreOS:

/etc/init.d/fleetd-agent status
logread | grep fleetd

La salida puede variar con la versión del sistema. Localiza la etapa fallida y elimina dominios, direcciones y datos sensibles antes de compartir registros. Nunca publiques claves privadas.

Una primera prueba pequeña

Empieza con un dispositivo de prueba en monitor. Verifica su huella mediante un canal fiable, apruébalo, observa datos nuevos y programa un reinicio controlado del agente para confirmar que vuelve con la misma identidad.

Es más fácil entender el alta así que otorgando full a todas las máquinas y ejecutando órdenes en lote desde el principio.

Fleetd separa conectividad, identidad del servidor, identidad del agente y autoridad local. Esa separación facilita diagnosticar y autorizar. La siguiente entrega explicará por qué el agente vuelve a verificar una orden que ya pasó por el servidor y cuáles son los límites de la firma en el navegador.