Access Gate incluye un cliente Tailscale integrado. Esta es la integración documentada para conectar Access Gate a una tailnet de Tailscale, de modo que los usuarios remotos, los sitios remotos y el propio Access Gate compartan una malla superpuesta segura sin cambios en el firewall ni recableado.
Esta guía cubre la configuración completa de Tailscale en Access Gate: creación de la tailnet, configuración del pool de IP, concesión de acceso OAuth a la API para que Access Gate pueda leer el estado de la tailnet, sincronización de activos y usuarios de vuelta a Access Gate, y concesión de acceso a enclaves a través de la superposición.
Configurar la tailnet de Tailscale
Si aún no tiene una cuenta de Tailscale, vaya a tailscale.com para crear una. El menú integrado lo guiará por los pasos para crear su cuenta; puede detenerse en cuanto la pantalla indique que conecte dispositivos.
Configurar el rango de direcciones IP de la tailnet
A cada máquina conectada a la tailnet se le asigna una dirección IP. Para controlar el pool de direcciones desde el que se asignan estas direcciones, agregue al archivo de configuración de Access Controls:
"nodeAttrs": [
{ "target": ["*"], "ipPool": ["100.100.0.0/16"] }
]
y haga clic en Save para guardar y aplicar. Opcionalmente, especifique pools distintos para diferentes grupos de usuarios:
"nodeAttrs": [
{ "target": ["autogroup:member"], "ipPool": ["100.100.1.0/24"] },
{ "target": ["autogroup:admin"], "ipPool": ["100.100.2.0/24"] }
]
Para cambiar la dirección IP de una máquina ya conectada, vaya a Machines section -> machine options (tres puntos a la derecha de la fila de información de la máquina) -> Edit machine IPv4, introduzca una IP disponible del rango deseado y pulse el botón Update IP.
Desde la interfaz, puede hacerlo en Access Controls > Node Attributes.
Configurar la aprobación automática para máquinas recién conectadas
De forma predeterminada, cada máquina recién añadida se aprueba automáticamente para unirse a la tailnet. Es opcional (y más seguro) modificar esta política y requerir aprobación manual para cada nueva máquina. Para habilitarlo, vaya a Settings -> Device management y establezca Device Approval en On.
A partir de ese momento, cada nueva máquina añadida a la tailnet aparecerá en la sección Machines con la etiqueta "Needs approval" y deberá aprobarse manualmente haciendo clic en las opciones de la máquina (tres puntos a la derecha) y seleccionando Approve. Desde la interfaz, puede hacerlo en Access Controls > Auto approvers.
Configurar la aprobación automática para rutas anunciadas (compartidas)
Cuando una máquina recién conectada anuncia (comparte) rutas para que sean accesibles a través de la tailnet, estas subredes deben aprobarse en Machines section -> machine options (tres puntos a la derecha) -> Edit route settings habilitando la casilla junto a las subredes correspondientes.
El proceso de aprobación de subredes puede automatizarse configurando la aprobación automática para usuarios y subredes específicos en el archivo de configuración de Access Controls:
"autoApprovers": {
"routes": {
"100.64.0.0/24": ["autogroup:member"],
"100.64.0.0/10": ["autogroup:admin"]
}
}
Configurar la expiración de claves de máquina
A cada máquina conectada a la tailnet se le asigna una clave que, de forma predeterminada, es válida durante 180 días. Transcurrido ese tiempo, la clave expira y la máquina debe volver a autenticarse.
La expiración de claves puede deshabilitarse por máquina para las máquinas de confianza (incluido AccessGate) en la sección Machines haciendo clic en machine options (tres puntos a la derecha) -> Disable key expiry.
Configurar el acceso OAuth a la API de la tailnet
Para permitir que Access Gate lea el estado de la tailnet (dispositivos, usuarios, DNS y rutas) y mantenga los activos y el acceso sincronizados, es necesario configurar el acceso a la API e introducir el ID y el Secret obtenidos en la configuración de Access Gate.
Para habilitar el acceso OAuth a la API de la tailnet, en Tailscale:
- En Tailscale, vaya a Settings -> Trust Credentials -> OAuth clients
- Introduzca una descripción (p. ej., AccessGate API client)
- Conceda los siguientes ámbitos:
- DNS: Read and Write
- Policy File: Read
- Users: Read
- Services: Read
- Devices (Core): Read
- Posture Attributes: Read
- Routes: Read and Write
- Haga clic en Generate credential
Copie y guarde de forma segura las credenciales del cliente OAuth mostradas (ID y Secret), e introdúzcalas en AccessGate a través de la administración web de AccessGate -> Settings -> Networking -> VPN Access -> API Credentials.
A partir de la versión v26.6, puede actualizar o reemplazar estas credenciales de API en cualquier momento desde la misma pantalla. Esto resulta útil si necesita rotar el cliente OAuth o reconfigurar la integración sin reconstruirla.
Sincronizar activos y usuarios desde Tailscale
En Access Gate, haga clic en Authenticate.
Tras una conexión exitosa, verá la siguiente pantalla.
De vuelta en Tailscale, actualice la pestaña Access Controls para conceder acceso a los miembros (u otra fuente de su elección) a la subred anunciada y enrutada por Access Gate:
Por ejemplo:
// access Access Gate LAN
{
"src": ["autogroup:member"],
"dst": ["100.64.144.0/24"],
"ip": ["*"],
},
Acceder a activos locales
Ahora puede ir a Enclaves y conceder acceso a los activos y usuarios que desee. Para acceder a ellos, simplemente use la IP o la URL que aparece en la pestaña Assets. La magia ocurre en segundo plano :)
Resolución de nombres en la tailnet (DNS)
A partir de la versión v26.6, el DNS resuelve en ambas direcciones: una máquina en la tailnet puede resolver activos detrás de Access Gate, y los activos locales pueden resolver hosts de la tailnet. Para resolver nombres de host locales desde un cliente Tailscale, agregue Access Gate como servidor de nombres para los dominios relevantes en Tailscale en DNS > Nameservers (DNS dividido: restrínjalos a los dominios que sirve Access Gate, para que el resto de su DNS no se vea afectado).
Enrutamiento: acceso a subredes locales
Los clientes Tailscale acceden a los activos de una red local a través de las rutas anunciadas descritas anteriormente (consulte Configurar la aprobación automática para rutas anunciadas (compartidas)). Access Gate anuncia sus subredes locales a la tailnet; una vez aprobadas esas rutas, los clientes de la tailnet acceden a los activos locales por IP o nombre de host. Qué usuarios pueden acceder a qué activos sigue estando gobernado por enclave mediante identidad y ACL. Ese modelo de acceso se describe en Acceso remoto Zero Trust, que opera sobre esta superposición. Para la mayoría de los despliegues, este enfoque basado en rutas es preferible a configurar Access Gate como nodo de salida de Tailscale, lo que enviaría todo el tráfico del cliente a través de él.
Descarte por ruta inversa ("Reverse-path drop")
Síntoma, causa raíz y solución
Síntoma. Un dispositivo anunciado a través de Access Gate (por ejemplo, 100.64.144.50) es inaccesible a través de Tailscale: nc o curl agotan el tiempo de espera. Un tcpdump en el lado del gateway muestra SYNs salientes sin respuesta. Tomando como ejemplo un firewall FortiGate, el rastreo de flujo muestra el descarte:
received a packet(proto=1, 100.127.0.34->172.31.144.50) from Trout Connect
func=ip_route_input_slow msg="reverse path check fail, drop"
func=ip_session_handle_no_dst
Causa raíz. Los paquetes llegan al FortiGate con la IP de origen Tailscale sin procesar del cliente (100.127.0.0/24, dentro de 100.64.0.0/10). Access Gate realiza NAT de destino (100.64.144.0/24 a 172.31.144.0/24) pero no NAT de origen, por lo que el FortiGate no tiene ruta de retorno al rango de Tailscale. Su verificación estricta de reenvío por reverse-path (anti-spoofing) descarta entonces el paquete antes de que llegue al dispositivo OT. El dispositivo en sí está en buen estado: nada llega a él.
Esto se encuentra al final de la cadena de acceso, por lo que primero descarte las capas anteriores. Las cuatro deben estar en verde:
- Concesión en la ACL de Tailscale. Una concesión debe listar el CIDR de la subred como
dst. La aprobación de rutas (autoApprovers) es independiente del acceso a rutas (concesiones): la aprobación por sí sola no distribuye la ruta a los clientes. - Ruta en el netmap del cliente. Ejecute
tailscale status --json; losAllowedIPsdel gateway deben incluir la subred. - Túnel al gateway.
tailscale ping <target>devuelve un pong. - Ruta de retorno en FortiGate. El fallo que se trata aquí.
Solución (preserva la identidad). Proporcione al router una ruta de retorno a Tailscale y una política correspondiente, para que las reglas OT por identidad sigan funcionando. Por ejemplo, en un dispositivo FortiGate:
config router static
edit 0
set dst 100.64.0.0 255.192.0.0
set gateway <Access Gate 'Trout Connect' IP>
set device "<Trout Connect interface>"
next
end
Luego agregue una política de firewall de Trout Connect a OT, con origen 100.64.0.0/10 y destino el objetivo. Con la ruta presente, el RPF estricto pasa, por lo que no es necesario deshabilitar strict-src-check.
Resumen
Conectamos Access Gate a una tailnet de Tailscale: creamos la tailnet y el pool de IP, concedimos acceso OAuth a la API, sincronizamos activos y usuarios de vuelta a Access Gate, habilitamos DNS bidireccional y accedimos a subredes locales a través de rutas aprobadas. Use esta configuración para dar a usuarios remotos y sitios remotos una malla superpuesta segura hacia activos locales sin cambios en el firewall, recableado ni nodo de salida de Tailscale.
Relacionados
- Acceso remoto Zero Trust: el modelo de acceso remoto por enclave con verificación de identidad que opera sobre esta superposición de Tailscale
- Privileged Access Management: sesiones de administración RDP/SSH/VNC con proxy de navegador (una vía independiente, no a través de la superposición)
- Listas de control de acceso: defina qué protocolos puede alcanzar cada usuario