Planifier, déployer et exploiter une passerelle Sophos ZTNA

Une passerelle Sophos ZTNA relie les utilisateurs autorisés aux applications internes. Trois modes de déploiement sont pris en charge : une VM de passerelle locale sur VMware ESXi ou Microsoft Hyper-V, une VM de passerelle Sophos Cloud sur l’un de ces hyperviseurs, ou une passerelle Sophos Cloud sur une Sophos Firewall gérée de manière centralisée. Cette procédure vous accompagne du choix initial à la recette et à un retour arrière sûr. Pour choisir en amont entre ZTNA et l’accès distant classique, consultez Sophos Connect ou SSL VPN : quelle solution d’accès distant choisir ? et Le Zero Trust expliqué simplement : ZTNA plutôt que VPN classique.

L’interface actuelle s’appelle Sophos Fusion ; les anciens textes d’aide et certaines illustrations utilisent encore Sophos Central. En cas de différence avec une illustration, les chemins et noms de champs actuels indiqués ici font foi.

Objectif et réponse directe

Choisissez le type de passerelle selon le chemin des données et la responsabilité opérationnelle, et non selon le nombre de clics :

Une VM peut être déployée avec une seule interface ou deux interfaces. Le mode à une interface utilise l’interface externe pour le trafic entrant et sortant et réduit les changements d’infrastructure. Le mode à deux interfaces sépare les interfaces externe et interne, nécessite deux cartes réseau et, le cas échéant, des routes statiques ; selon le fabricant, il offre la meilleure sécurité et le meilleur débit. Le guide distinct Publier un serveur avec DNAT sur Sophos Firewall explique la fonction sous-jacente du pare-feu ; les ports propres à ZTNA sont précisés plus bas.

Prérequis, licence et rôles

Licence et rôles administratifs

• Les fonctions ZTNA nécessitent la licence appropriée. Les notes de version de la passerelle signalent explicitement les fonctions soumises à licence.
• Sophos Fusion Firewall Management nécessite un abonnement payant en plus de la licence de base du pare-feu.
• L’enregistrement d’un pare-feu dans Sophos Fusion nécessite un Central Super Admin. Cet administrateur peut aussi générer un OTP à partir du numéro de série du pare-feu et le transmettre à l’administrateur du pare-feu ; cet OTP est valable 14 jours.
• Les groupes d’utilisateurs affectés doivent être synchronisés dans Sophos Fusion. Microsoft Entra ID ou Active Directory sont pris en charge comme services d’annuaire. Microsoft Entra ID, Okta et Active Directory local sont documentés comme fournisseurs d’identité.
• Les groupes Entra ID doivent être activés pour la sécurité. C’est automatiquement le cas des groupes créés directement dans Entra ID ; les groupes importés d’AD ou créés dans le portail Microsoft 365 peuvent faire exception.

La documentation de la passerelle examinée ne définit pas de rôle d’administrateur ZTNA plus précis. Si le compte ne voit pas les menus ou actions décrits, n’élargissez pas ses droits par essais et erreurs : faites vérifier l’attribution des rôles propre au tenant par un administrateur Sophos Fusion autorisé.

Certificat

La passerelle nécessite un certificat wildcard. Les certificats de Let’s Encrypt ou d’une autorité de certification de confiance sont pris en charge :

• RSA d’au moins 2048 bits ;
• ECDSA, mais pas avec P-384 ni P-521.

Le déploiement en VM prend en charge un seul certificat wildcard. Préparez le certificat et sa clé privée. Vous pouvez les téléverser dans les détails de la passerelle, sous Zertifikat ; Sophos Fusion peut également y générer un certificat Let’s Encrypt.

La procédure d’obtention est décrite dans Créer un certificat wildcard Let’s Encrypt. Pour les certificats gérés directement sur Sophos Firewall, Gérer les certificats Let’s Encrypt sur Sophos Firewall présente la procédure d’exploitation distincte.

Hôte, heure et capacité

Les SSD sont recommandés pour des performances d’E/S disque plus régulières. La date et l’heure de l’hôte doivent être exactes ; le fuseau horaire doit être UTC. La passerelle reprend l’heure de l’hôte et ne peut pas fonctionner correctement si celle-ci est erronée.

Réseau, IPv4 et destinations autorisées

• N’utilisez aucun des réseaux 10.42.0.0/16, 10.43.0.0/16 ou 10.108.0.0/16 pour la passerelle. Ils sont réservés aux services internes.
• IPv6 n’est pas pris en charge pour les passerelles. Dans ce scénario, n’attribuez pas d’adresses IPv6 par DHCP à la passerelle ni aux endpoints. Si les endpoints sont déjà configurés, désactivez IPv6 manuellement.
• Utilisez une adresse IPv4 statique ou une réservation DHCP. La passerelle ne sait pas gérer un changement ultérieur de son adresse IP.
• Lorsque les utilisateurs accèdent aux ressources ZTNA depuis le même réseau que la passerelle, une règle SNAT de type MASQ évite le routage asymétrique.
• Si plusieurs nœuds de passerelle sont utilisés, ils doivent tous se trouver dans le même sous-réseau et présenter une latence très faible entre eux.

Pour une passerelle locale derrière un pare-feu, les destinations suivantes doivent être accessibles, généralement sur TCP 443 :

• sophos.jfrog.io
• jfrog-prod-use1-shared-virginia-main.s3.amazonaws.com
• *.amazonaws.com
• production.cloudflare.docker.com
• *.docker.io
• *.sophos.com
• login.microsoftonline.com
• graph.microsoft.com
• sentry.io
• *.okta.com, si Okta est le fournisseur d’identité
• wsserver-<Gateway-FQDN>
• le FQDN de passerelle configuré dans les paramètres de la passerelle

En outre, ztna.apu.sophos.com nécessite TCP 22. Si un pare-feu en amont déchiffre TLS, excluez wsserver-<Gateway-FQDN> de ce déchiffrement.

ZTNA contrôle l’accès aux applications web et locales. Les applications locales nécessitent l’agent ZTNA. Les applications qui attribuent dynamiquement leurs ports ou en utilisent un très grand nombre, par exemple certains anciens produits VoIP, ne sont pas prises en charge. L’agent est documenté pour Windows 10 1803 ou ultérieur et macOS Big Sur 11 ou ultérieur.

Configuration avec des valeurs d’exemple à adapter

Utilisez vos propres valeurs. Les noms suivants servent uniquement à illustrer leur correspondance :

Chemins actuels de l’interface

Les textes d’aide actuels en allemand indiquent les chemins et actions suivants :

• Meine Produkte > ZTNA > Gateways puis Gateway hinzufügen
• Meine Produkte > ZTNA > Einstellungen > Domänen
• Geräte > Installer

1. Déployer l’image de la VM

Pour ESXi :

1. Ouvrez Geräte > Installer, recherchez Zero Trust Network Access et téléchargez l’image de la passerelle.
2. Acceptez le contrat de licence et, le cas échéant, les formulaires de conformité à l’exportation.
3. Déployez l’OVA dans vSphere au moyen de OVF-Vorlage bereitstellen.
4. Désactivez le démarrage automatique. La VM ne doit pas démarrer sans l’ISO générée ultérieurement.

Pour Hyper-V :

1. Ouvrez Geräte > Installer > Zero Trust Network Access et téléchargez l’Gateway-VM-Image für Hyper-V.
2. Extrayez le VHDX. Chaque VHDX ne doit servir qu’à une seule VM ; créez des copies pour les VM supplémentaires.
3. Créez une VM de génération 1 avec au moins 4096 Mo de mémoire de démarrage et deux processeurs virtuels. Raccordez le VHDX existant.
4. Pour un déploiement à deux interfaces, ajoutez une deuxième carte réseau. Si vous utilisez des VLAN, attribuez les identifiants VLAN appropriés.

2A. Créer une passerelle locale

1. Ouvrez Meine Produkte > ZTNA > Gateways > Gateway hinzufügen.
2. Sous Gateway-Modus, sélectionnez Lokal.
3. Renseignez Gateway-Name, Gateway-FQDN et Domäne für Ressourcen.
4. Sous Plattformtyp, sélectionnez VMware ESXi ou Hyper-V selon l’hôte.
5. Sélectionnez le Bereitstellungsmodus Einarmig ou Zweiarmig.
6. Configurez les interfaces. Avec DHCP, une réservation est obligatoire. Avec Statische IP, indiquez l’adresse IP, le sous-réseau et le serveur DNS. Si un déploiement à deux interfaces doit atteindre des applications dans plusieurs réseaux internes, ajoutez des Statische Routen.
7. Téléversez le certificat wildcard.
8. Cliquez sur Speichern und Datei erstellen. Le statut initial est Warten auf Bereitstellung ; l’ISO de démarrage propre à cette passerelle est générée.
9. Sur le pare-feu, n’ouvrez en entrée que TCP 80 et 443, créez une règle DNAT pour chacun des deux ports vers l’IP externe de la passerelle ou la VIP du cluster, et bloquez tous les autres ports entrants. N’utilisez pas de proxy inverse.

2B. Créer une passerelle Sophos Cloud en VM

1. Validez d’abord le domaine sous Meine Produkte > ZTNA > Einstellungen > Domänen > Domäne hinzufügen.
2. Sophos Fusion génère un CNAME, par exemple 5ccdee2b04764c75ac252a0f91f161b7.cert.prod.ztna.access.sophos.com. Publiez auprès de votre fournisseur DNS la valeur exacte générée pour votre tenant.
3. Attendez la propagation DNS, puis cliquez sur Validieren sous Einstellungen > Domänen. Ne poursuivez que lorsque le statut indique validiert.
4. Cliquez sur Gateway hinzufügen, sélectionnez Sophos Cloud sous Gateway-Modus, puis renseignez Gateway-Name et Gateway-FQDN. Le FQDN de la passerelle doit correspondre à celui indiqué lors de l’enregistrement de l’application ZTNA.
5. Sélectionnez la Domäne validée, le Plattformtyp approprié, l’Identitätsanbieter et, sous Points of Presence, la région la plus proche du centre de données.
6. Sélectionnez Einarmig ou Zweiarmig, configurez les interfaces avec des adresses réservées ou statiques et, si nécessaire, les routes statiques. Téléversez le certificat wildcard.
7. Cliquez sur Speichern und Datei erstellen. Copiez le domaine alias généré dans la boîte de dialogue Gateway hinzugefügt et publiez-le comme CNAME du FQDN de la passerelle dans le DNS public.
8. N’ouvrez que TCP 443 en sortie sur l’interface externe. Ce modèle ne nécessite aucune publication de la VM par DNAT entrant.

Depuis ZTNA 2.1, un point de présence secondaire voisin du PoP principal est configuré par défaut. Il peut être désactivé sous Einstellungen. Choisissez néanmoins un PoP principal proche du centre de données.

2C. Créer une passerelle Sophos Cloud sur Sophos Firewall

1. Vérifiez que la version est SFOS 19.5 MR3 ou ultérieure et que le pare-feu est géré de manière centralisée dans Sophos Fusion. Si le pare-feu n’est pas encore enregistré, utilisez Register sur le pare-feu avec les identifiants du Super Admin ou l’OTP généré par celui-ci.
2. Validez le domaine comme indiqué à l’étape 2B.
3. Ouvrez Meine Produkte > ZTNA > Gateways > Gateway hinzufügen et sélectionnez Gateway-Modus: Sophos Cloud.
4. Renseignez Gateway-Name et Gateway-FQDN, sélectionnez la Domäne validée et définissez Plattformtyp sur Firewall.
5. Sous Firewall, sélectionnez l’appareil SFOS. La liste n’affiche que les pare-feu gérés de manière centralisée à partir de 19.5 MR3. Dans une paire HA, le pare-feu actif peut être choisi ; le trafic et les services peuvent ainsi être repris lors du basculement.
6. Sélectionnez l’Identitätsanbieter et les Points of Presence, téléversez le certificat, puis cliquez sur Speichern. La passerelle devrait être active après environ cinq minutes.
7. Ajoutez auprès du fournisseur d’identité l’URL de redirection spécifique https://<externer-Gateway-FQDN>/ztna-oauth2/callback.

Limites de cette variante :

• Dans un déploiement HA actif-actif, le portail d’administration web du pare-feu n’est pas accessible via ZTNA.
• Les portails utilisateur et VPN du pare-feu ne sont pas pris en charge via la passerelle ZTNA.
• Dans les autres cas, le portail d’administration web peut être créé comme ressource de type Webadmin-Portal. Pour l’accès sans agent, le domaine alias généré est publié comme CNAME public ; pour l’accès avec agent, celui-ci intercepte le FQDN externe.

3. Créer éventuellement un cluster de VM

Créez le cluster avant de télécharger les ISO de démarrage :

1. Ouvrez la nouvelle passerelle et cliquez sur Instanzen hinzufügen/bearbeiten > Eine weitere Instanz hinzufügen. Le clustering est activé automatiquement.
2. Indiquez une IP virtuelle de cluster non utilisée, dans la même plage d’adresses IP que les instances. Pour un déploiement à deux interfaces avec équilibreur de charge externe, laissez vide la VIP externe du cluster.
3. Indiquez le nom de la VM et l’IP de l’interface ; pour un déploiement à deux interfaces, indiquez les IP interne et externe.
4. Répétez l’opération pour obtenir au moins trois instances. De trois à neuf instances sont prises en charge, toujours en nombre impair.
5. Faites pointer le DNAT d’une passerelle locale vers la VIP externe du cluster. Au moins la moitié des nœuds doivent rester actifs.

4. Monter l’ISO de démarrage et approuver l’enregistrement

Chaque ISO est associée exclusivement à une passerelle ou à une instance et ne doit pas être réutilisée.

• ESXi : montez l’ISO sur le lecteur CD/DVD, puis sélectionnez Verbinden et Beim Einschalten verbinden. Un périphérique série existant peut être supprimé.
• Hyper-V : dans les paramètres de la VM, sélectionnez IDE Controller 1 > Image-Datei pour le lecteur DVD et montez l’ISO.
• Ne démarrez la VM qu’ensuite. L’ISO doit rester montée même après un démarrage réussi.
• Ouvrez les détails de la passerelle. Le statut passe de Warten auf Bereitstellung à Warte auf Genehmigung ou Warten auf Gateway-Genehmigung.
• Cliquez sur Genehmigen. Pour un cluster, n’approuvez que la première instance ; les autres sont ensuite gérées automatiquement.
• L’approbation peut prendre jusqu’à dix minutes. Vérifiez le statut final propre à chaque plateforme : en local sur ESXi Verbunden, en local sur Hyper-V Aktiv, Sophos Cloud sur ESXi Aktiv et Verbunden, Sophos Cloud sur Hyper-V Aktiv.

Vérifier correctement le DNS et le chemin des données

Les serveurs DNS publics et privés ont des rôles distincts :

Passerelle locale

• Avec agent : l’agent intercepte la requête destinée à l’application privée et lui attribue une adresse de la plage 100.64.x.x. Pour établir le tunnel, il résout le FQDN de la passerelle au moyen d’un enregistrement A public pointant vers l’IP de la passerelle. Celle-ci résout ensuite le FQDN de l’application via le serveur DNS privé.
• Sans agent : un CNAME public de l’application pointe vers le FQDN de la passerelle, dont l’enregistrement A public pointe vers l’IP de la passerelle. Celle-ci interroge le serveur DNS privé pour trouver la destination interne de l’application.

Passerelle Sophos Cloud

• Avec agent : le DNS public résout l’application privée vers le domaine alias qui lui est attribué. Celui-ci mène à la passerelle via le PoP Sophos Cloud. La passerelle résout ensuite la destination interne via le DNS privé.
• Sans agent : le CNAME public de la ressource pointe vers le domaine alias généré par Sophos. Pour chaque nouvelle ressource sans agent, la passerelle ouvre un nouveau tunnel vers le PoP sur TCP 443. Le PoP associe la requête à la passerelle grâce à l’alias.

La connexion entre l’agent et la passerelle ou le PoP utilise une authentification TLS mutuelle. TLS 1.2 et les versions ultérieures, ainsi que des protocoles de chiffrement avec des clés allant jusqu’à 256 bits, sont documentés.

L’agent ZTNA modifie l’adaptateur TAP par défaut. Par conséquent, nslookup peut sembler échouer pour les noms hors ZTNA. Indiquez explicitement le serveur DNS réellement compétent :

nslookup <FQDN> <DNS-Server>

Validation et résultat attendu

Ne vous contentez pas d’un statut de passerelle vert. Utilisez un utilisateur pilote aux droits limités et une seule ressource de test.

1. Gestion : sous Meine Produkte > ZTNA > Gateways, la passerelle est Aktiv ou Verbunden. Sous Gateway-Details, vérifiez la version logicielle et, pour un cluster, tous les nœuds.
2. DNS public : pour une passerelle locale, l’enregistrement A de la passerelle et, le cas échéant, le CNAME de la ressource renvoient l’IP publique prévue. Pour une passerelle Cloud, les CNAME de validation du domaine, de la passerelle et des ressources correspondent exactement aux valeurs générées par Sophos.
3. DNS privé : la passerelle peut résoudre le FQDN de la ressource interne vers l’IP interne du serveur.
4. Certificat : le FQDN, le périmètre du wildcard, la chaîne, la durée de validité et la clé privée correspondent. Le navigateur ou l’agent n’affiche aucune alerte de confiance.
5. Réseau : pour une passerelle locale, TCP 80 et 443 atteignent les règles DNAT prévues ; les autres ports entrants sont bloqués. Pour une passerelle Cloud, le tunnel TCP 443 sortant fonctionne sans publication entrante.
6. Accès : l’utilisateur pilote autorisé n’accède qu’à l’application qui lui est attribuée. Un utilisateur de test non autorisé n’y accède pas.
7. Application : ne vérifiez pas seulement la connexion, mais aussi une transaction réelle et limitée. Le chemin retour fonctionne et l’application voit l’origine de connexion attendue.
8. Stabilité : testez depuis l’extérieur et, si cela est prévu, depuis le même réseau que la passerelle. Ce second test confirme notamment le fonctionnement de MASQ et du chemin retour.
9. Cluster : n’arrêtez aucun nœud hors d’un test de maintenance et de basculement approuvé. Lors d’un test planifié, au moins la moitié des instances restent actives et les requêtes sont transmises par les autres nœuds.

Si le résultat attendu n’est pas au rendez-vous, consultez ci-dessous le symptôme correspondant. Ne modifiez pas simultanément le DNS, le certificat, le NAT et la politique.

Pour analyser séparément la couche pare-feu, consultez Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture et Comprendre le NAT sur Sophos Firewall.

Dépannage par symptôme

La passerelle reste sur « Warten auf Bereitstellung » ou ne joint pas Sophos Fusion

1. Vérifiez que l’ISO unique est montée sur la bonne VM et que Beim Einschalten verbinden est activé.
2. Vérifiez l’heure de l’hôte et le fuseau horaire UTC.
3. Vérifiez l’IP statique ou la réservation DHCP, le DNS et les destinations autorisées ; ztna.apu.sophos.com nécessite TCP 22.
4. Vérifiez l’exception au déchiffrement TLS pour wsserver-<Gateway-FQDN>.
5. Exécutez le diagnostic de la VM dans vSphere ou Hyper-V Manager.

Le statut attend une approbation

Ouvrez les détails de la passerelle et cliquez sur Genehmigen. Attendez jusqu’à dix minutes. Pour un cluster, n’approuvez que la première instance. Si le statut ne change pas, vérifiez d’abord la connectivité et l’heure au lieu de créer de nouvelles instances.

La passerelle cesse de fonctionner après une modification DHCP ou réseau

La passerelle ne gère pas les changements d’adresse IP. Rétablissez l’attribution d’adresse initiale et configurez une réservation DHCP ou une adresse statique. Vérifiez ensuite le DNS, le DNAT et, pour un cluster, les cibles de la VIP. Un changement d’IP planifié n’est pas une simple modification en cours d’exploitation : il doit être traité comme un nouveau déploiement.

La connexion réussit, mais la ressource reste inaccessible

1. Résolvez le FQDN de la ressource directement auprès du serveur DNS privé.
2. Vérifiez la route et la règle de pare-feu entre la passerelle et le port de destination documenté.
3. Avec deux interfaces, vérifiez les routes statiques vers les autres réseaux internes.
4. Pour un accès depuis le même réseau que la passerelle, vérifiez la règle MASQ et le routage asymétrique.
5. Vérifiez si l’application utilise des ports dynamiques ou très nombreux ; ces applications ne sont pas prises en charge.

L’accès externe à une passerelle locale échoue

Vérifiez l’enregistrement A public, TCP 80 et 443, les deux règles DNAT et leur IP cible ou VIP de cluster. Assurez-vous qu’aucun proxy inverse ne se trouve en amont. Les autres ports entrants restent bloqués.

La passerelle Cloud ou une ressource sans agent est inaccessible

Vérifiez dans cet ordre :

1. le statut du domaine validiert ;
2. le CNAME de la passerelle et celui de la ressource par rapport aux domaines alias générés dans Sophos Fusion ;
3. TCP 443 sortant de la passerelle vers le PoP ;
4. la résolution DNS privée de la passerelle vers l’application ;
5. la région PoP correcte et, pour une passerelle sur pare-feu, l’URL de redirection OAuth2 particulière.

nslookup renvoie des résultats erronés après l’installation de l’agent

L’agent définit l’adaptateur TAP ZTNA comme adaptateur par défaut. Répétez la requête en précisant le serveur DNS. Un échec via l’adaptateur TAP ne prouve pas que le serveur DNS habituel ne connaît pas le nom.

Erreurs de certificat

Vérifiez le périmètre du wildcard, la chaîne complète, la clé privée et l’algorithme. ECDSA avec P-384/P-521 et RSA de moins de 2048 bits ne sont pas pris en charge. Comparez le FQDN de la passerelle, le domaine des ressources et les noms du certificat avant d’en téléverser un nouveau.

Paquet de diagnostic pour le support Sophos

Pour les passerelles en VM sur ESXi ou Hyper-V :

1. Ouvrez Gateway-Details > Fehlerbehebungsprotokolle.
2. Cliquez sur Protokolle generieren. La génération peut prendre quelques minutes.
3. Téléchargez la nouvelle entrée dans la colonne Fehlerbehebungsprotokoll. Elle expire après une heure.
4. Si nécessaire, activez dans les détails de la passerelle un accès temporaire pour le support et transmettez le jeton affiché exclusivement au support Sophos.

Cette fonction de journalisation ne s’applique pas à la passerelle intégrée à Sophos Firewall.

Retour arrière sûr ou retrait du service

Distinguez une modification de configuration, une mise à jour de passerelle en VM, un changement de firmware du pare-feu et la suppression définitive. Ces opérations ne suivent pas les mêmes procédures de retour arrière.

Avant toute modification

• Relevez le mode de la passerelle, son FQDN, ses IP, la VIP du cluster, la plateforme, la version, le certificat, les enregistrements CNAME/A publics, le DNAT/SNAT, les routes statiques, les ressources affectées et le groupe pilote.
• Identifiez les ressources et les utilisateurs qui dépendent de la passerelle, puis convenez d’une fenêtre de maintenance.
• Pendant le pilote, ne modifiez qu’une seule couche à chaque étape. Conservez les dernières valeurs DNS et pare-feu fonctionnelles.

Déplacer des ressources vers une passerelle sur pare-feu

Pour la migration documentée d’une passerelle existante vers une passerelle sur pare-feu :

1. Configurez entièrement la passerelle sur pare-feu.
2. Ajoutez sa nouvelle URL de redirection OAuth2 auprès du fournisseur d’identité.
3. Ouvrez Ressourcen und Zugriff, sélectionnez la ressource et définissez Gateway sur la passerelle sur pare-feu.
4. Pour l’accès sans agent, publiez le nouveau domaine alias du pare-feu comme CNAME public.
5. Validez avec un utilisateur aux droits limités. Ne retirez l’ancien enregistrement DNS ni l’ancienne passerelle qu’après un test réussi de l’application.

Supprimer la passerelle

L’action Gateway löschen est disponible dans les détails de la passerelle. Toutefois, les sources associées ne décrivent ni la restauration d’une passerelle supprimée ni un retrait automatique et transactionnel du DNS, du NAT, des ressources et des certificats. Par conséquent :

1. Ne commencez pas le retour arrière par une suppression.
2. Déplacez ou désactivez d’abord les ressources dépendantes pendant la fenêtre de changement convenue et vérifiez qu’aucun accès de production ne passe encore par la passerelle.
3. Retirez ensuite les enregistrements DNS publics et les règles de pare-feu devenus obsolètes en vous appuyant sur la liste dressée au préalable.
4. Ne supprimez la passerelle qu’après l’accord des responsables des applications et du réseau.
5. Si les dépendances ou la procédure de restauration ne sont pas claires, arrêtez-vous avant Gateway löschen et contactez le support Sophos.

Retour arrière après une mise à jour

Les instructions examinées ne décrivent pas de rétrogradation pour les mises à jour de passerelle en VM. En cas d’échec, ne tentez pas de restaurer une image selon une procédure non documentée ; générez les journaux, maintenez l’accès via l’instance restée inchangée ou le cluster et faites remonter le problème au support Sophos.

Pour une passerelle intégrée à Sophos Firewall, la procédure documentée de retour à un firmware antérieur s’applique :

1. Vérifiez que l’abonnement au support est valide et sauvegardez la configuration du pare-feu.
2. Avant le changement, vérifiez que la version cible prend en charge le nombre de passerelles configurées ; les passerelles excédentaires doivent être supprimées avant de changer de firmware.
3. Planifiez le changement hors des heures de pointe. Le pare-feu met fin aux sessions et redémarre.
4. Sous Backup and firmware > Firmware, vous pouvez téléverser une version compatible et la démarrer avec Upload and boot, ou démarrer une image déjà inactive avec Boot firmware image.
5. Le firmware actif et le précédent résident sur des partitions distinctes avec leurs configurations respectives. Un retour au firmware précédent rétablit donc également sa configuration antérieure.
6. Après le redémarrage, connectez-vous et vérifiez le firmware actif en haut à gauche du Control Center, puis le statut de la passerelle, le DNS et l’accès pilote.

Exploitation, révision et cycle de vie

Mettre à jour une passerelle en VM

Sous Gateways, une coche verte à côté du numéro de version signale qu’une version de VM est disponible. Cliquez sur le numéro de version, choisissez la version cible, puis planifiez la mise à jour ou sélectionnez Jetzt. Si un redémarrage est nécessaire, l’interface affiche un avertissement ; prévoyez-le pendant une fenêtre de maintenance. Cette fonction ne concerne que les passerelles ESXi et Hyper-V. Une passerelle sur pare-feu se met à jour au moyen du firmware SFOS.

Les notes de version consultées mentionnent ZTNA 2.2 du 13 janvier 2026 pour ESXi et Hyper-V, aussi bien en déploiement local que Sophos Cloud, et qualifient cette mise à niveau d’obligatoire en raison de nouvelles fonctionnalités requises. Avant la fenêtre de maintenance, vérifiez néanmoins toujours la version cible proposée dans Sophos Fusion ainsi que les notes de version actuelles ; ne déduisez de cette ancienne indication ni une date de fin de vie ni la version cible actuelle.

L’historique des versions mentionne également un délai d’inactivité configurable pour les tunnels agent-passerelle et la désactivation du Resource Connection Pooling à partir de 2.1.2. Pour la version 2.2, il documente des correctifs concernant les connexions intermittentes aux ressources avec agent via une passerelle locale, un statut Updating bloqué après une mise à jour d’image, des messages de diagnostic trompeurs sur les pods du cluster et une condition de concurrence entre pods Kubernetes. Utilisez cet historique pour évaluer les changements et les incidents, sans remplacer par lui la vue actuelle des détails de la passerelle.

Révision régulière

Au minimum selon votre propre calendrier de maintenance, vérifiez :

• le statut de la passerelle et des nœuds, ainsi que les versions installée et proposée ;
• la durée de validité du certificat et sa chaîne complète ;
• les CNAME publics de validation de domaine, de passerelle et de ressources ;
• la résolution DNS privée et les routes, règles DNAT, SNAT et de pare-feu encore nécessaires ;
• la région PoP, le PoP secondaire et la latence réelle de la passerelle Cloud ;
• les groupes d’utilisateurs synchronisés et activés pour la sécurité, ainsi que le fournisseur d’identité ;
• les affectations de ressources aux passerelles et les passerelles devenues inutiles ;
• les procédures de diagnostic et de support, les fenêtres de maintenance et les responsables.

Ne publiez aucune affirmation sur une période de transition ou de migration, un retrait ou une fin de vie sans communication produit actuelle et lisible. Les sources disponibles étayent l’exploitation et l’état des versions, mais aucune date de cycle de vie de ce type.

Guides connexes existants

Cette procédure s’arrête volontairement aux limites de la passerelle. La configuration complète du service d’annuaire et du fournisseur d’identité, l’installation ou la suppression de l’agent ZTNA, son dépannage spécifique, les règles d’accès aux ressources et les architectures particulières comportant plusieurs contrôleurs de domaine relèvent des guides existants correspondants. Les articles de référence cités plus haut sur le Zero Trust, l’accès distant, les certificats, le DNAT et le diagnostic du pare-feu complètent la procédure relative à la passerelle sans dupliquer ces démarches distinctes.