Access Gate est livré avec un client Tailscale intégré. Il s'agit de l'intégration documentée pour connecter Access Gate à un tailnet Tailscale, afin que les utilisateurs distants, les sites distants et Access Gate lui-même partagent un réseau maillé sécurisé sans modification de pare-feu ni recâblage.
Ce guide couvre l'intégralité de la configuration Tailscale sur Access Gate : création du tailnet, configuration du pool d'adresses IP, octroi d'un accès OAuth API pour qu'Access Gate puisse lire l'état du tailnet, synchronisation des assets et des utilisateurs vers Access Gate, et octroi d'accès aux enclaves via le réseau superposé.
Configurer votre tailnet Tailscale
Si vous ne disposez pas encore d'un compte Tailscale, rendez-vous sur tailscale.com pour en créer un. Le menu intégré vous guidera à travers les étapes de création de votre compte ; vous pouvez vous arrêter dès que l'écran vous invite à connecter des appareils.
Configurer la ou les plages d'adresses IP du tailnet
Chaque machine connectée au tailnet se voit attribuer une adresse IP. Pour contrôler le pool d'adresses à partir duquel ces adresses sont assignées, ajoutez dans le fichier de configuration Access controls :
"nodeAttrs": [
{ "target": ["*"], "ipPool": ["100.100.0.0/16"] }
]
puis cliquez sur Save pour enregistrer et appliquer. Vous pouvez également définir des pools différents pour différents groupes d'utilisateurs :
"nodeAttrs": [
{ "target": ["autogroup:member"], "ipPool": ["100.100.1.0/24"] },
{ "target": ["autogroup:admin"], "ipPool": ["100.100.2.0/24"] }
]
Pour modifier l'adresse IP d'une machine déjà connectée, accédez à Machines section -> machine options (trois points à droite de la ligne d'information de la machine) -> Edit machine IPv4, saisissez une adresse IP disponible dans la plage souhaitée et appuyez sur le bouton Update IP.
Depuis l'interface, vous pouvez effectuer cette opération via Access Controls > Node Attributes.
Configurer l'approbation automatique des machines nouvellement connectées
Par défaut, chaque nouvelle machine ajoutée est automatiquement approuvée pour rejoindre le tailnet. Il est facultatif (et plus sûr) de modifier cette politique et d'exiger une approbation manuelle pour chaque nouvelle machine. Pour l'activer, accédez à Settings -> Device management et réglez Device Approval sur On.
Après cela, chaque nouvelle machine ajoutée au tailnet apparaîtra dans la section Machines avec le libellé « Needs approval » et devra être approuvée manuellement en cliquant sur les options de la machine (trois points à droite) et en sélectionnant Approve. Depuis l'interface, vous pouvez effectuer cette opération via Access Controls > Auto approvers.
Configurer l'approbation automatique des routes annoncées (partagées)
Lorsqu'une machine nouvellement connectée annonce (partage) des routes à rendre accessibles via le tailnet, ces sous-réseaux doivent être approuvés dans Machines section -> machine options (trois points à droite) -> Edit route settings en activant la case à cocher correspondant aux sous-réseaux concernés.
Le processus d'approbation des sous-réseaux peut être automatisé en configurant l'approbation automatique pour des utilisateurs et des sous-réseaux spécifiques dans le fichier de configuration Access controls :
"autoApprovers": {
"routes": {
"100.64.0.0/24": ["autogroup:member"],
"100.64.0.0/10": ["autogroup:admin"]
}
}
Configurer l'expiration des clés de machine
Chaque machine connectée au tailnet se voit attribuer une clé valide par défaut pendant 180 jours. Passé ce délai, la clé expire et la machine doit être ré-authentifiée.
L'expiration de la clé peut être désactivée par machine pour les machines de confiance (y compris AccessGate) dans la section Machines en cliquant sur machine options (trois points à droite) -> Disable key expiry.
Configurer l'accès OAuth API à la configuration du tailnet
Pour permettre à Access Gate de lire l'état du tailnet (appareils, utilisateurs, DNS et routes) et de maintenir les assets et les accès synchronisés, un accès API doit être configuré et l'ID et le Secret obtenus doivent être saisis dans la configuration d'Access Gate.
Pour activer l'accès OAuth API au tailnet, dans Tailscale :
- Dans Tailscale, accédez à Settings -> Trust Credentials -> OAuth clients
- Saisissez une Description (par exemple, AccessGate API client)
- Accordez les portées suivantes :
- DNS : Read and Write
- Policy File : Read
- Users : Read
- Services : Read
- Devices (Core) : Read
- Posture Attributes : Read
- Routes : Read and Write
- Cliquez sur Generate credential
Copiez et conservez en lieu sûr les identifiants du client OAuth affichés (ID et Secret), puis saisissez-les dans AccessGate via l'administration Web AccessGate -> Settings -> Networking -> VPN Access -> API Credentials.
À partir de la version v26.6, vous pouvez mettre à jour ou remplacer ces identifiants API à tout moment depuis le même écran. Cela est utile si vous devez faire tourner le client OAuth ou reconfigurer l'intégration sans la reconstruire entièrement.
Synchroniser les Assets et les utilisateurs depuis Tailscale
Dans Access Gate, cliquez sur Authenticate.
Après une connexion réussie, l'écran suivant s'affiche.
De retour côté Tailscale, mettez à jour votre onglet Access controls pour accorder l'accès aux membres (ou à toute autre source de votre choix) au sous-réseau annoncé et routé par Access Gate :
Par exemple :
// access Access Gate LAN
{
"src": ["autogroup:member"],
"dst": ["100.64.144.0/24"],
"ip": ["*"],
},
Accéder aux Assets locaux
Vous pouvez maintenant accéder à Enclaves et accorder l'accès aux Assets et aux utilisateurs souhaités. Pour y accéder, utilisez simplement l'IP ou l'URL affichée dans l'onglet Assets. La magie opère en arrière-plan :)
Résoudre les noms à travers le tailnet (DNS)
À partir de la version v26.6, la résolution DNS fonctionne dans les deux sens : une machine sur le tailnet peut résoudre les assets derrière Access Gate, et les assets locaux peuvent résoudre les hôtes du tailnet. Pour résoudre les noms d'hôtes locaux depuis un client Tailscale, ajoutez Access Gate comme serveur de noms pour les domaines concernés dans Tailscale sous DNS > Nameservers (DNS divisé : limitez-le aux domaines servis par Access Gate, afin que le reste de votre DNS ne soit pas affecté).
Routage : atteindre les sous-réseaux locaux
Les clients Tailscale atteignent les assets d'un réseau local via les routes annoncées décrites ci-dessus (voir Configurer l'approbation automatique des routes annoncées (partagées)). Access Gate annonce ses sous-réseaux locaux au tailnet ; une fois ces routes approuvées, les clients du tailnet atteignent les assets locaux par IP ou par nom d'hôte. Les utilisateurs autorisés à accéder à quels assets restent gouvernés par enclave selon l'identité et les ACL. Ce modèle d'accès est couvert dans Remote Zero Trust Access, qui repose sur ce réseau superposé. Pour la plupart des déploiements, cette approche basée sur les routes est préférable à la configuration d'Access Gate comme nœud de sortie Tailscale, ce qui ferait transiter tout le trafic client par lui.
Rejet par chemin inverse ("Reverse-path drop")
Symptôme, cause racine et correctif
Symptôme. Un appareil annoncé via Access Gate (par exemple 100.64.144.50) est inaccessible via Tailscale : nc ou curl expirent. Un tcpdump côté passerelle montre des SYN sortants sans réponse. En prenant l'exemple d'un pare-feu FortiGate, la trace de flux indique le rejet :
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
Cause racine. Les paquets atteignent le FortiGate avec l'adresse IP source Tailscale brute du client (100.127.0.0/24, dans 100.64.0.0/10). Access Gate effectue un NAT de destination (100.64.144.0/24 vers 172.31.144.0/24) mais pas de NAT source, de sorte que le FortiGate n'a pas de route de retour vers la plage Tailscale. Sa vérification stricte du chemin de retransmission inverse (anti-usurpation) rejette alors le paquet avant qu'il n'atteigne l'appareil OT. L'appareil lui-même est sain : rien ne lui parvient jamais.
Ce problème se situe en fin de chaîne d'accès ; vérifiez d'abord les couches précédentes. Les quatre points suivants doivent être au vert :
- Autorisation ACL Tailscale. Une autorisation doit lister le CIDR du sous-réseau comme
dst. L'approbation de route (autoApprovers) est distincte de l'accès à la route (autorisations) : l'approbation seule ne distribue pas la route aux clients. - Route dans la netmap du client. Exécutez
tailscale status --json; lesAllowedIPsde la passerelle doivent inclure le sous-réseau. - Tunnel vers la passerelle.
tailscale ping <target>retourne un pong. - Chemin de retour FortiGate. L'échec traité ici.
Correctif (préserve l'identité). Donnez au routeur une route de retour vers Tailscale et une politique correspondante, afin que les règles OT par identité continuent de fonctionner. Par exemple sur un équipement 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
Ajoutez ensuite une politique de pare-feu de Trout Connect vers OT, avec comme source 100.64.0.0/10 et comme destination la cible. Avec la route en place, la vérification RPF stricte passe, il n'est donc pas nécessaire de désactiver strict-src-check.
Récapitulatif
Nous avons connecté Access Gate à un tailnet Tailscale : création du tailnet et du pool IP, octroi de l'accès OAuth API, synchronisation des assets et des utilisateurs vers Access Gate, activation du DNS bidirectionnel, et accès aux sous-réseaux locaux via des routes approuvées. Utilisez cette configuration pour offrir aux utilisateurs distants et aux sites distants un réseau maillé sécurisé vers les assets locaux, sans modification de pare-feu, sans recâblage et sans nœud de sortie Tailscale.
Ressources associées
- Remote Zero Trust Access : le modèle d'accès distant par enclave avec vérification d'identité, qui repose sur ce réseau superposé Tailscale
- Privileged Access Management : sessions d'administration RDP/SSH/VNC proxifiées par navigateur (chemin distinct, indépendant du réseau superposé)
- Access control lists : définir quels protocoles chaque utilisateur peut atteindre