Un plano de control para una malla privada.

Comprende qué se coordina

El plano de control gestiona el registro de nodos y distribuye la información de red. El tráfico de datos puede usar conexiones directas entre pares o un relay según la conectividad. Ejecutar el coordinador no significa que cada paquete pase a través de él.

Hacer la inscripción intencionada

Proteja el API administrativo y utilice métodos de registro de corta duración o con el alcance adecuado. Elimine los dispositivos perdidos o retirados. La capacidad de unirse a la malla no debería implicar acceso a todos los servicios.

Revisa las ACL y las rutas

Aplica reglas de mínimo privilegio entre usuarios y nodos. Las rutas de subred anunciadas y los nodos de salida amplían la red accesible y requieren aprobación explícita. Prueba el tráfico denegado con el mismo cuidado que el tráfico permitido.

Conserva el material de recuperación

Haz copias de seguridad de la configuración, el estado y las claves según el procedimiento de la versión compatible. Mantén una forma de administrar el VPS si la malla falla. Verifica la compatibilidad de los clientes y las notas de actualización antes de cambiar el plano de control.

El registro, el enrutamiento y la política son comprobaciones separadas

Headscale coordina clientes compatibles con Tailscale; las conexiones directas y las rutas de retransmisión DERP tienen un comportamiento de red diferente. Un enrutador de subred anuncia un rango, el servidor de control lo aprueba y el cliente debe aceptar la ruta. Habilita el reenvío en el nodo de enrutamiento y mantén los rangos anunciados estrechos. Una ruta aprobada sigue necesitando una política de acceso que limite quién puede usar qué destino y puerto.

• Verifica la lista de rutas del servidor de control
• Pruebe desde un dispositivo autorizado
• Repita la misma prueba desde un dispositivo al que se le deba denegar el acceso

headscale nodes list-routes

Documentación oficial: Rutas de Headscale

No pongas la única ruta de recuperación dentro de la malla

Mantenga una segunda forma de acceder a la consola del servidor o una ruta de administrador estrictamente restringida. Pruebe qué ocurre cuando el coordinador, el relay o el cliente no están disponibles. Conserve el estado y las claves del plano de control según la versión instalada. Una malla privada puede simplificar el acceso, pero no debe convertirse en una dependencia no documentada que impida su propia reparación.

Fije la identidad del plano de control y la ruta de recuperación

Elija un nombre de HTTPS estable, una versión de Headscale compatible y clientes Tailscale compatibles. Lea el ejemplo de configuración incluido con esa versión exacta; una configuración copiada de otra versión puede fallar la validación o describir silenciosamente una política distinta. Persista la base de datos del plano de control y las claves necesarias. Mantenga privado el API administrativo y conserve una consola separada o una ruta SSH restringida, para que perder la malla no haga imposible reparar su coordinador.

• Utilice un certificado válido para el nombre público del plano de control.
• Mantenga las claves de inscripción con una vida útil corta y un alcance adecuado.
• Trata el diseño del relay y el espacio de nombres DNS como decisiones explícitas.

Documentación oficial: Despliegue del contenedor Headscale

Inscribe un dispositivo antes de anunciar una red

Levanta el servidor siguiendo las instrucciones upstream y registra un usuario/dispositivo de prueba mediante el método de inscripción documentado. Confirma que el dispositivo alcanza el URL de control esperado y aparece bajo la identidad prevista. Inspecciona el estado del cliente y prueba un servicio privado antes de añadir rutas de nodo de salida o de subred. Una ruta DERP puede preservar la conectividad donde una ruta directa no está disponible; no indica que el coordinador esté reenviando cada paquete.

• Empieza con un dispositivo y un servicio que puedas retirar de forma segura.
• Comprueba si el tráfico entre pares es directo o retransmitido.
• Protege los endpoints de retransmisión y control según el despliegue elegido.

Documentación oficial: Referencia de despliegue de Headscale

Aprueba el enrutamiento y la autorización de forma independiente

Para el acceso a subredes, habilita el reenvío en el nodo de enrutamiento, anuncia un rango estrecho, apruébalo en el servidor de control y asegúrate de que el cliente de destino lo acepte. Evita redes superpuestas que hagan ambigua la ruta de retorno. Una ruta aprobada no es una política de acceso: define quién puede conectarse a qué destino y puerto, incluidos los dispositivos invitados. Prueba una conexión permitida y una conexión idéntica denegada antes de ampliar la malla.

# Run on the control server; syntax follows the installed release:
headscale nodes list-routes
# Client-side inspection:
tailscale status

Documentación oficial: Subred y rutas de salida de Headscale

Encuentra la capa averiada antes de cambiar la política

Si la inscripción falla, inspecciona DNS, HTTPS y el URL del servidor. Si el dispositivo se une pero una subred no es accesible, inspecciona el anuncio, la aprobación, la aceptación de rutas del cliente, el reenvío y la ruta de retorno. Si solo falla un servicio, inspecciona su dirección de enlace, el firewall del host y la política de la malla. Conserva una copia de seguridad coherente de la base de datos y la configuración y prueba una actualización de versión con un cliente desechable antes de cambiar el único plano de control.