La forma más sencilla de usar Twingate con CasaOS hoy en día es ejecutar un conector de Twingate como contenedor de Docker en el host de CasaOS o en otro equipo de la misma LAN. El conector establece conexiones salientes con Twingate, por lo que no necesitas redirigir puertos para el panel de CasaOS.
El tutorial del foro de 2023 es anterior a la plantilla actual de Docker Compose de Twingate. Usa los tokens actuales del conector y las variables oficiales de Compose en lugar de copiar a ciegas un paquete antiguo de la tienda de instalación con un solo clic.
Crea una red remota y un conector
En la consola de administración de Twingate, crea una red remota y un conector. Twingate genera un token de acceso y un token de actualización únicos para ese conector.
Usa la plantilla actual de Docker Compose
La guía actual de Docker Compose de Twingate documenta estas variables obligatorias:
services:
twingate-connector:
image: twingate/connector:latest
restart: always
environment:
- TWINGATE_NETWORK=YOUR_TENANT
- TWINGATE_ACCESS_TOKEN=YOUR_ACCESS_TOKEN
- TWINGATE_REFRESH_TOKEN=YOUR_REFRESH_TOKEN
No incluyas los tokens en capturas de pantalla públicas
Los tokens de acceso y de actualización autentican de forma exclusiva al conector. Guárdalos en la configuración de la aplicación de CasaOS o en un archivo de entorno que no se suba a Git ni se publique.
Añade CasaOS como recurso de Twingate
En la consola de administración de Twingate, define la IP de la LAN o el nombre de host de CasaOS y el puerto web como recurso. Concede acceso solo a los usuarios o grupos que lo necesiten.
Red en modo bridge o host
Twingate indica que el modo bridge es el predeterminado, mientras que el modo host puede facilitar la conexión entre pares en la red local. Empieza con la configuración predeterminada oficial, salvo que tengas un motivo específico para compartir la pila de red del host.
No es necesario redirigir puertos en el router
El conector se ejecuta detrás del firewall y establece una conexión saliente. No abras el puerto de administración de CasaOS a Internet solo porque quieras acceder de forma remota.
Instala el cliente de Twingate en tu dispositivo remoto
El conector se ejecuta dentro de la red de tu casa; el cliente de Twingate se ejecuta en el portátil o el teléfono que usas a distancia. Ambos se registran en la red de Twingate antes de que el tráfico llegue al recurso privado.
Verifica el acceso antes de añadir más recursos
Prueba primero el panel de CasaOS y luego añade otras aplicaciones NAS de forma individual. Así, la política de acceso será explícita en lugar de exponer innecesariamente toda una subred.
La guía de acceso remoto privado ofrece un contexto más amplio sobre servidores domésticos.
Comprueba el estado del conector antes de probar CasaOS
docker ps | grep twingate
docker logs --tail 100 twingate-connectorEl conector debería registrarse correctamente y permanecer en ejecución. Si se reinicia repetidamente, verifica el nombre del tenant y los tokens antes de solucionar problemas del recurso de CasaOS.
Usa la definición de recurso más específica
Si solo necesitas el panel de CasaOS, define la IP exacta de CasaOS y el puerto web, en lugar de exponer toda la subred de la LAN. Añade otras aplicaciones como recursos independientes cuando realmente las necesites.
Planifica las actualizaciones del conector
Twingate publica actualizaciones de contenedores de forma independiente de CasaOS. Cada cierto tiempo, descarga la imagen actual del conector y reinícialo durante una ventana de mantenimiento. Luego, confirma que el acceso remoto siga funcionando.
Preguntas frecuentes
¿Tengo que abrir los puertos de CasaOS en el router?
No. Los conectores de Twingate están diseñados para ejecutarse detrás del firewall y establecer conexiones salientes.
¿De dónde salen los tokens de Twingate?
La consola de administración los genera al implementar un conector.
¿Debería usar la red del host?
Solo cuando lo requiera la topología o el comportamiento entre pares; el modo bridge es el predeterminado.
¿Puede un conector exponer algo más que CasaOS?
Sí, pero define los recursos y los permisos de forma intencionada en lugar de conceder acceso general a la subred de forma predeterminada.
