Planifier et créer la passerelle Sophos ZTNA
Une passerelle Sophos ZTNA connecte les utilisateurs aux applications internes sans avoir besoin d’un accès VPN classique à tunnel complet. Cependant, le véritable avantage n’apparaît que lorsque le mode passerelle, le DNS, le certificat, les règles de pare-feu et l’accessibilité interne sont correctement planifiés.
Ce guide décrit comment planifier et créer une passerelle ZTNA dans Sophos Central. L’accent est mis sur la partie passerelle. Pour la décision de base entre VPN, ZTNA et autres variantes d’accès à distance, Sophos Connect ou SSL VPN : quelle solution d’accès à distance est la bonne ? convient également.
Pour les bases neutres sur Zero Trust, ZTNA et la différence avec VPN, commencer par Zero Trust expliqué simplement : ZTNA au lieu du VPN classique.
Comprendre les modes de passerelle
Sophos ZTNA peut être utilisé avec une Passerelle sur site ou une Sophos Cloud Gateway. Les deux variantes donnent accès aux ressources internes, mais diffèrent considérablement en termes d’exposition Internet, de DNS, d’opérations et de dépannage.
- Passerelle sur site: La VM de passerelle est située dans votre propre centre de données ou réseau de site, votre propre VM, votre propre DNS public, DNAT sur le port 443, un contrôle plus direct.
- Passerelle Sophos Cloud: Les utilisateurs se connectent via les points de présence Sophos Cloud. exposition Internet moins directe, différents DNS CNAME, sélection du point de présence.
- Sophos Firewall comme passerelle cloud: Sophos Firewall assume le rôle de passerelle pour ZTNA Cloud Gateway. pas de VM de passerelle séparée, mais dépendance au SFOS, au fonctionnement central et au pare-feu.
Le mode n’est pas seulement une case à cocher technique. Il détermine où entre le trafic, qui exploite le chemin de données, quelles entrées DNS sont nécessaires et si une règle DNAT est nécessaire sur le pare-feu.
Passerelle sur site
Avec une passerelle sur site, une VM de passerelle est déployée sur VMware ESXi ou Microsoft Hyper-V. La passerelle est accessible depuis Internet et accepte l’accès ZTNA. En pratique, un nom DNS public pointe vers le pare-feu et une règle DNAT transmet le HTTPS à la passerelle.
Avantages :
- chemin de données direct vers votre propre emplacement,
- contrôle total sur les règles de passerelle, de segment, de DNS et de pare-feu,
- aucune dépendance vis-à-vis du Sophos Cloud Data Plane pour le point d’entrée réel.
Inconvénients :
- La Gateway VM doit être exploitée et mise à jour,
- Le port 443 doit être accessible de l’extérieur,
- Le certificat, le DNS, le DNAT et le routage interne doivent être corrects,
- La disponibilité dépend de votre localisation, de votre connexion Internet et de votre hyperviseur.
Lors de la publication d’une passerelle sur site via DNAT, la règle doit être planifiée avec autant de soin que les autres publications. Les bases se trouvent dans Publier des serveurs avec DNAT sur Sophos Firewall.
Passerelle Sophos Cloud
Avec Sophos Cloud Gateway, l’accès est géré via les points de présence Sophos Cloud. Le composant de passerelle interne connecte Sophos Cloud aux ressources internes. Cela élimine le besoin pour les utilisateurs d’accéder directement à leur propre adresse IP de passerelle publique.
Cela réduit l’exposition directe à Internet mais déplace une partie du chemin des données vers le cloud Sophos. Les éléments suivants sont donc importants :
- point de présence adapté à proximité du data center,
- corriger les enregistrements publics CNAME,
- résolution DNS interne fonctionnelle,
- des attentes claires concernant la latence, la disponibilité et les profils de trafic,
- Vérification des limites de licence, de produit et de trafic pour l’environnement spécifique.
Pour les applications très gourmandes en données telles que le stockage de fichiers volumineux, les fichiers CAO ou les téléchargements de masse, vous ne devez pas simplement tester ZTNA Cloud Gateway sur la base d’un enregistrement. Ce qui compte, c’est le comportement de l’utilisation réelle, de la latence et du volume de données au quotidien.
Sophos Firewall en tant que passerelle cloud ZTNA
Une Sophos Cloud Gateway peut également être configurée sur des appareils de pare-feu Sophos gérés de manière centralisée. Ceci est intéressant s’il existe déjà un pare-feu Sophos sur place et qu’aucune VM de passerelle distincte ne doit être exploitée.
Cette variante ne doit cependant pas être activée comme fonction secondaire. Les éléments suivants doivent être vérifiés :- Version SFOS prise en charge et statut de gestion centrale.
- Licence ZTNA et cartographie des utilisateurs.
- Accessibilité des ressources internes du point de vue du pare-feu.
- Impact sur les fenêtres de maintenance, les mises à jour du firmware et le fonctionnement du pare-feu.
- Journalisation et responsabilité des perturbations.
Si le pare-feu est de toute façon le nœud central d’accès à distance, cette variante peut être élégante. D’un autre côté, si vous souhaitez que ZTNA s’exécute indépendamment de la maintenance du pare-feu, une VM de passerelle dédiée ou une autre conception est parfois plus propre.
Exigences
Avant le déploiement, ces points doivent être clarifiés :
- Sophos Central Tenant avec licence ZTNA.
- Utilisateurs et groupes synchronisés.
- Fournisseur d’identité, par exemple Microsoft Entra ID.
- Choisissez une passerelle sur site ou une passerelle Sophos Cloud.
- Hyperviseur ou Sophos Firewall pris en charge, selon le mode.
- DNS public pour la passerelle et les ressources.
- Certificat Wildcard ou concept de certificat approprié.
- Résolution DNS interne des applications cibles.
- Segment de réseau pour la passerelle.
- Règles de pare-feu de la passerelle vers les applications.
- Propriétaire des opérations, journaux, certificats et modifications ultérieures.
Pour les certificats, un certificat générique est souvent l’option la plus pratique. L’obtention d’un certificat générique est décrite dans Let’s Encrypt crée un certificat générique. Si les certificats sont gérés directement sur Sophos Firewall, Gérer les certificats Let’s Encrypt sur Sophos Firewall convient également.
Plateforme et dimensionnement
Pour les machines virtuelles de passerelle, VMware ESXi et Microsoft Hyper-V sont les plates-formes typiques. Selon le mode et le statut Sophos, d’autres options peuvent être pertinentes. Il est crucial que la plateforme soit officiellement prise en charge, à jour et correctement surveillée.
Pour les configurations petites à moyennes, une VM de passerelle avec 2 vCPU et 4 Go de RAM constitue un point de départ réaliste. Mais cela ne remplace pas la planification opérationnelle. Les facteurs décisifs sont le nombre d’utilisateurs, les ressources, le profil du trafic, TLS, la latence et la disponibilité.
Pour les environnements productifs, vous devez également prévoir :
- Existe-t-il un cluster de passerelle ?
- La passerelle fonctionne-t-elle dans son propre VLAN ?
- Comment la VM est-elle sauvegardée ou restaurée ?
- Y a-t-il une surveillance par hyperviseur ?
- Qui met à jour la passerelle ?
- Y a-t-il une fenêtre de maintenance pour les redémarrages ?
Réseau et sous-réseau
La passerelle ZTNA doit être exploitée dans son propre sous-réseau ou VLAN. Il ne doit pas simplement être placé sur un réseau client ou serveur. Un segment distinct facilite les règles de pare-feu, la journalisation, la capture de paquets et le dépannage ultérieur.
Ces réseaux ne doivent pas être utilisés pour la passerelle :
10.42.0.0/1610.43.0.0/1610.108.0.0/16
Pour une passerelle sur site, un nom DNS public, par exemple ztna.example.com, pointe vers l’adresse IP publique du pare-feu. Le pare-feu transmet le port 443 à la passerelle via DNAT. La passerelle nécessite alors un accès à Internet et un accès aux VLAN ou réseaux de serveurs dans lesquels se trouvent les applications publiées.
Les entrées DNS sont différentes pour une Sophos Cloud Gateway. Là, les CNAME deviennent pertinents pour la validation de domaine, les alias de passerelle et, selon le type d’accès, les alias de ressources. Les entrées DNS publiques doivent donc être vérifiées lors d’une étape distincte avant le déploiement.
Décider avant le déploiement
Avant de cliquer sur Add gateway, il convient de répondre à ces questions :
- Quelles applications sont publiées ?: L’application Web, l’application TCP et le stockage de fichiers ont des exigences différentes.
- Accès sans agent ou avec agent ?: Les DNS, les CNAME et l’expérience utilisateur diffèrent.
- Passerelle sur site ou cloud ?: Décide du DNAT, du chemin des données et de la responsabilité opérationnelle.
- Quels groupes d’utilisateurs sont autorisés à accéder ?: ZTNA prospère grâce à des associations étroites et non à de grands groupes.
- Comment le DNS est-il résolu en interne et en externe ?: Les destinations DNS incorrectes sont l’une des sources d’erreurs les plus courantes.
- Quel certificat est utilisé ?: Les erreurs de certificat agissent comme un échec ZTNA pour les utilisateurs.
- Qui examine les journaux et les modifications ?: Sans propriétaire, ZTNA devient vite difficile à supporter.
Télécharger la passerelle ZTNA
Dans Sophos Central, les fichiers de la machine virtuelle peuvent être téléchargés sous Protéger les appareils dans le menu principal.

Déployer une VM sur Hyper-V ou ESXi
Pour une passerelle sur site ou une VM de passerelle, la machine virtuelle est créée en premier.
Paramètres typiques :
- Génération 1 pour Hyper-V.
- 2 processeurs virtuels comme valeur de départ.
- 4 Go de RAM comme valeur de départ.
- Réseau dans son propre segment VLAN ou passerelle.
- Hyper-V : utilisez les fichiers
.vhdxtéléchargés. - ESXi : utilisez le fichier OVA.
La VM ne doit pas être démarrée tant que l’image ISO n’est pas créée avec les paramètres de la passerelle. Cet ISO connecte ultérieurement la VM au locataire Sophos Central et aux paramètres de la passerelle.
Paramètres de la passerelle dans Sophos Central
La passerelle est ensuite ajoutée et configurée dans Sophos Central.
Champs importants :
- Mode: Choisissez consciemment la passerelle sur site ou la passerelle cloud Sophos.
- Nom: Utilisez l’emplacement, le but ou le nom d’hôte.
- Localisation: Facultatif, mais utile avec plusieurs passerelles.
- Nom de domaine complet: Pour la passerelle sur site, le nom DNS public pointant vers l’adresse IP du pare-feu ou de la passerelle.
- Domaine: Domaine correspondant au certificat et aux ressources.
- Type de plateforme: VMware ESXi, Hyper-V, AWS ou variante de pare-feu Sophos prise en charge selon le mode.
- Fournisseur d’identité: Sélectionnez le fournisseur d’identité précédemment configuré.
- Mode de déploiement de l’instance de passerelle: Un bras pour les scénarios DNAT simples, deux bras pour une conception WAN/LAN séparée.
- Adresse IP: Préférez une adresse IP statique ou réservée pour les passerelles productives.
- Certificat: Utilisez un caractère générique ou un certificat de passerelle approprié.
Un seul bras est souvent plus simple car une seule interface est utilisée pour le trafic entrant et sortant. Deux bras séparent les côtés WAN et LAN, mais nécessitent deux interfaces et une conception réseau plus claire.
Après l’enregistrement, Sophos Central crée une image ISO avec les informations de la passerelle. Cette ISO est attribuée à la VM en tant qu’ISO de démarrage.
En fonction des performances et de l’environnement de l’hôte, le démarrage initial et l’enregistrement auprès de Sophos Central peuvent prendre un certain temps. Dès que la passerelle répond, elle peut être acceptée dans Central.




Vérifiez après le démarrage
Après l’enregistrement, la passerelle n’est pas automatiquement prête pour la production. Seuls ces tests montrent si la conception fonctionne :
- Statut de la passerelle: Gateway est en ligne dans Sophos Central et affiche une version plausible.
- DNS public: Le FQDN de la passerelle ou les CNAME pointent vers la destination attendue.
- Certificat: Le navigateur et le client ZTNA font confiance au certificat.
- Résolution DNS interne: Gateway peut résoudre correctement les ressources internes.
- Règles de pare-feu: La passerelle atteint uniquement les applications et les ports dont elle a besoin.
- DNAT sur site: Le port 443 répond à la règle NAT et pare-feu attendue.
- Utilisateur test: Un groupe pilote peut atteindre exactement les ressources prévues.
- Journaux: Les journaux de la passerelle, de la centrale et du pare-feu affichent les événements traçables.
Si ZTNA est introduit comme alternative au VPN, un projet pilote ne devrait pas être testé avec un simple exemple de site Web. Les vraies applications cibles sont meilleures : portail web interne, saut RDP/SSH, application spécialisée ou accès aux fichiers, selon l’usage prévu.
Erreurs typiques
- Le DNS public affiche faux: Les utilisateurs ne peuvent pas accéder à la passerelle. A/CNAME, TTL, vérifier la résolution externe.
- Résolution DNS interne manquante: La connexion fonctionne, la ressource ne s’ouvre pas. Vérifiez le DNS privé, le nom de domaine complet de la ressource ou l’adresse IP de destination.
- Le certificat ne correspond pas: Avertissement du navigateur ou du client. Vérifiez le caractère générique, le SAN, la chaîne et le domaine.
- DNAT est absent de la passerelle sur site: La passerelle reste inaccessible de l’extérieur. Vérifiez la règle NAT, le port 443, l’adresse IP WAN et la visionneuse de journaux.
- La passerelle n’est pas autorisée à accéder à l’application: La ressource reste hors ligne ou expire. Vérifier les règles de pare-feu du segment de passerelle vers la destination.
- Changements d’adresse DHCP: ZTNA échoue après le redémarrage. Utiliser une adresse IP réservée ou statique.
- Groupe d’utilisateurs trop large: Trop de ressources visibles. Répartir plus étroitement les groupes, les politiques et les ressources.
- Passerelle Cloud avec PoP incorrect: latence notable. Choisissez un point de présence proche du data center. Pour l’analyse des règles et du NAT sur Sophos Firewall, Tester les règles de pare-feu avec Log Viewer, Policy Test and Packet Capture et Comprendre NAT sur Sophos Firewall vous aideront.
Liste de contrôle opérationnel
- Mode passerelle documenté.
- DNS public et DNS privé testés.
- Certificat valide et renouvelable.
- Gateway exploitée sur son propre segment.
- DNAT configuré uniquement pour la passerelle sur site.
- Les règles de passerelle pour les ressources internes sont strictement limitées.
- Utilisateurs pilotes et ressources pilotes définis.
- Journaux, propriétaire et processus de support clarifiés.
- Fenêtres de mise à jour et de maintenance de la passerelle programmées.
- Plan de démantèlement en place si Pilot ne fonctionne pas.