Access Gate a besoin d'un chemin réseau pour que les utilisateurs distants, les sites distants ou la gestion centrale puissent l'atteindre. Ce chemin n'est lié à aucune technologie unique. Access Gate est agnostique vis-à-vis du transport : il s'appuie sur le WAN ou le VPN que le site exploite déjà, et applique l'accès localement, au niveau de la passerelle, par-dessus celui-ci.
Comment l'atteindre
Access Gate se place derrière ce qui achemine déjà le trafic jusqu'au site. Il ne fournit ni n'exige de WAN ou de VPN spécifique, et il applique l'accès localement sur tout ce qui arrive. Il est utile de distinguer ici deux couches, car ce sont des choses différentes, et non des choix concurrents.
1. Le transport : comment le trafic atteint le site
Il s'agit ici d'accessibilité, pas de chiffrement. Vous atteignez Access Gate via votre réseau existant comme n'importe quel autre hôte interne, qu'il s'agisse d'un LAN routé, d'un WAN privé ou d'un backbone MPLS entre sites, ou de l'internet public. Une liaison WAN privé ou MPLS est déjà privée, elle n'a donc souvent besoin de rien d'autre par-dessus.
2. Le chiffrement en transit : un overlay VPN, uniquement si le chemin n'est pas déjà privé
Si le chemin traverse des réseaux non fiables, activez le VPN chiffré que vous utilisez déjà. Les tunnels site à site IPSec, OpenVPN ou WireGuard se terminent sur votre pare-feu ou routeur existant, et Access Gate se trouve derrière eux, appliquant l'accès par enclave sur le trafic déchiffré. Un VPN est un overlay que vous superposez à un transport ; il n'est pas lui-même un transport, et MPLS est un transport, pas un VPN.
Le client Tailscale intégré : le seul overlay fourni par Access Gate
Pour les équipes qui souhaitent un réseau maillé fondé sur l'identité sans déployer leur propre concentrateur, Access Gate inclut un client Tailscale intégré, ce qui lui permet de rejoindre directement un tailnet sans modification de pare-feu ni recâblage. Il s'agit de l'option clé en main et du seul composant de connectivité qu'Access Gate fournit lui-même ; tout ce qui précède n'est que votre réseau existant. Voir Configurer Tailscale VPN sur Access Gate.
Choisir une approche
Il n'y a pas de réponse unique. Choisissez en fonction de ce que vous exploitez déjà et de ce que vous devez préserver :
- Vous avez déjà un pare-feu qui gère l'IPSec, ou un concentrateur OpenVPN ? Conservez-le. Placez Access Gate derrière lui. Rien à démonter.
- Multi-sites avec des ingénieurs itinérants et aucune envie de concentrateurs ? Le client Tailscale intégré est généralement le chemin le plus rapide, puisque la passerelle rejoint elle-même le réseau maillé.
- Posture de souveraineté stricte ou air-gapped ? Un backbone WAN privé ou MPLS maintient le trafic entièrement hors de l'internet public, sans qu'aucun overlay chiffré soit nécessaire. Access Gate est entièrement on-premise et n'a aucune dépendance cloud propre, de sorte que la couche de connectivité est le seul endroit par lequel un tiers pourrait entrer, et vous la contrôlez.
Ce qui ne change pas
Quelle que soit la manière dont le trafic atteint la passerelle :
- Le contrôle d'accès est appliqué par enclave, lié à une identité nommée, avec MFA lorsque cela est requis. Voir Accès Zero Trust à distance.
- La session est relayée via le proxy de la passerelle et enregistrée à des fins d'audit.
- Rien n'est installé sur les PLC, HMI ou serveurs SCADA situés derrière la passerelle.
Le transport n'est qu'une question d'acheminement. La sécurité est la même dans tous les cas, et c'est Access Gate qui l'assure.