Pianificare, distribuire e gestire un gateway Sophos ZTNA

Un gateway Sophos ZTNA collega gli utenti autorizzati alle applicazioni interne. Sono supportate tre modalità di distribuzione: una VM gateway locale su VMware ESXi o Microsoft Hyper-V, una VM Sophos Cloud Gateway su uno di questi hypervisor oppure un Sophos Cloud Gateway su una Sophos Firewall gestita centralmente. Questo runbook accompagna dalla scelta alla verifica finale, fino a un ritorno sicuro alla configurazione precedente. Per decidere prima tra ZTNA e accesso remoto tradizionale, consultare Sophos Connect o SSL VPN: quale soluzione di accesso remoto scegliere? e Zero Trust spiegato semplicemente: ZTNA invece della VPN tradizionale.

L’interfaccia attuale si chiama Sophos Fusion; i testi della guida meno recenti e alcune immagini usano ancora Sophos Central. Se un’immagine differisce, fanno fede i percorsi e i nomi dei campi aggiornati riportati qui per esteso.

Scopo e risposta immediata

Scegliere il tipo di gateway in base al percorso dei dati e alle responsabilità operative, non al numero di clic:

Gateway locale

• Piattaforma supportata: ESXi o Hyper-V
• Percorso dei dati ed esposizione: Il gateway e il piano dati operano nel data center del cliente; il gateway è raggiungibile da Internet.
• Requisito di rete principale: Sulle interfacce esterne aprire in ingresso solo TCP 80 e 443, inoltrare entrambe le porte tramite DNAT e bloccare tutte le altre porte in ingresso. Non anteporre un reverse proxy.

Sophos Cloud Gateway come VM

• Piattaforma supportata: ESXi o Hyper-V
• Percorso dei dati ed esposizione: Sophos gestisce il punto di ingresso cloud; la VM collega Sophos Cloud alle risorse interne e non viene pubblicata come punto di ingresso Internet autonomo.
• Requisito di rete principale: Sull’interfaccia esterna del gateway aprire in uscita solo TCP 443; predisporre CNAME pubblici e risoluzione DNS privata.

Sophos Cloud Gateway su Sophos Firewall

• Piattaforma supportata: firewall hardware, cloud, virtuale o software gestita centralmente, da SFOS 19.5 MR3
• Percorso dei dati ed esposizione: Non occorre una VM gateway separata; autenticazione e autorizzazione avvengono in Sophos Cloud.
• Requisito di rete principale: La firewall deve essere gestita da Sophos Fusion; pianificare regione, provider di identità, certificato e URL di reindirizzamento specifico.

Una VM può essere distribuita con una sola interfaccia o con due interfacce. La prima usa l’interfaccia esterna per il traffico in entrata e in uscita e riduce al minimo le modifiche all’infrastruttura. La seconda separa l’interfaccia esterna da quella interna, richiede due schede di rete ed eventualmente rotte statiche; secondo il produttore offre la migliore sicurezza e il miglior throughput. La guida separata Pubblicare un server con DNAT su Sophos Firewall spiega la funzione firewall sottostante; i requisiti delle porte specifici per ZTNA sono riportati sotto.

Prerequisiti, licenza e ruoli

Licenza e ruoli amministrativi

• Per utilizzare le funzioni ZTNA occorre la licenza appropriata. Le note di rilascio del gateway indicano esplicitamente quali funzioni dipendono dalla licenza.
• Sophos Fusion Firewall Management richiede un abbonamento a pagamento oltre alla licenza base della firewall.
• Per registrare una firewall in Sophos Fusion è necessario un Central Super Admin. In alternativa, questo amministratore può generare un OTP usando il numero di serie della firewall e consegnarlo all’amministratore della firewall; l’OTP è valido per 14 giorni.
• I gruppi di utenti assegnati devono essere sincronizzati in Sophos Fusion. Come servizio di directory sono supportati Microsoft Entra ID o Active Directory. Come provider di identità sono documentati Microsoft Entra ID, Okta e Active Directory locale.
• I gruppi Entra ID devono essere abilitati alla sicurezza. Per i gruppi creati direttamente in Entra ID ciò avviene automaticamente; i gruppi importati da AD o creati tramite il portale Microsoft 365 possono fare eccezione.

La documentazione del gateway esaminata non indica un ruolo amministrativo ZTNA più specifico. Se l’account non vede i menu o le azioni descritti, non ampliare i privilegi per tentativi: far verificare l’assegnazione dei ruoli specifica del tenant da un amministratore Sophos Fusion autorizzato.

Certificato

Il gateway richiede un certificato wildcard. Sono supportati certificati Let’s Encrypt o di un’autorità di certificazione attendibile:

• RSA con almeno 2048 bit;
• ECDSA, ma non con P-384 o P-521.

Per la distribuzione come VM è supportato un solo certificato wildcard. Tenere pronti il certificato e la chiave privata. È possibile caricarli nei dettagli del gateway alla voce Certificate; in alternativa, Sophos Fusion può generare lì un certificato Let’s Encrypt.

La procedura pratica per ottenerlo è descritta in Creare un certificato wildcard Let’s Encrypt. Per i certificati gestiti direttamente su Sophos Firewall, Gestire i certificati Let’s Encrypt su Sophos Firewall descrive il flusso operativo separato.

Host, ora e capacità

Si consigliano SSD per prestazioni I/O del disco più uniformi. Data e ora dell’host devono essere corrette; il fuso orario deve essere UTC. Il gateway eredita l’ora dell’host e non può funzionare correttamente se questa è errata.

Rete, IPv4 e destinazioni consentite

• Non usare per il gateway né 10.42.0.0/16 né 10.43.0.0/16 o 10.108.0.0/16. Queste reti sono riservate ai servizi interni.
• IPv6 non è supportato per i gateway. In questo scenario, non assegnare indirizzi IPv6 tramite DHCP al gateway o agli endpoint. Sugli endpoint già configurati occorre disabilitare IPv6 manualmente.
• Usare un indirizzo IPv4 statico o una prenotazione DHCP. Il gateway non è in grado di gestire una successiva modifica del proprio indirizzo IP.
• Se gli utenti accedono alle risorse ZTNA dalla stessa rete del gateway, una regola SNAT di tipo MASQ evita il routing asimmetrico.
• Se sono presenti più nodi gateway, tutti devono trovarsi nella stessa sottorete e avere una latenza reciproca molto bassa.

Per un gateway locale dietro una firewall, devono essere raggiungibili le seguenti destinazioni, normalmente tramite 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, se Okta funge da provider di identità
• wsserver-<Gateway-FQDN>
• il FQDN del gateway configurato nelle impostazioni del gateway

Inoltre, ztna.apu.sophos.com richiede TCP 22. Se una firewall a monte esegue la decifratura TLS, escludere wsserver-<Gateway-FQDN> dalla decifratura.

ZTNA controlla l’accesso alle applicazioni web e locali. Le applicazioni locali richiedono l’agente ZTNA. Non sono supportate applicazioni che assegnano dinamicamente le porte o ne usano moltissime, per esempio i prodotti VoIP meno recenti. L’agente è documentato per Windows 10 1803 o successivo e macOS Big Sur 11 o successivo.

Configurazione con valori di esempio adattabili

Usare valori propri. I nomi seguenti illustrano soltanto le corrispondenze:

Percorsi dell’interfaccia attuale

I percorsi e le azioni seguenti usano le etichette inglesi dell’interfaccia confermate dalla guida attuale del produttore. Il nome, il FQDN del gateway e il dominio delle risorse sono descritti come valori tecnici da inserire, non come etichette di campi non confermate:

• My Products > ZTNA > Gateways e poi Add gateway
• My Products > ZTNA > Settings > Domains
• Devices > Installers

1. Distribuire l’immagine della VM

Per ESXi:

1. Aprire Devices > Installers, cercare Zero Trust Network Access e scaricare l’immagine del gateway.
2. Accettare il contratto di licenza e, se richiesti, i moduli di conformità per l’esportazione.
3. Distribuire l’OVA in vSphere tramite la procedura guidata di distribuzione.
4. Disabilitare l’accensione automatica. La VM non deve avviarsi senza l’ISO generata successivamente.

Per Hyper-V:

1. Aprire Devices > Installers e, in Zero Trust Network Access, fare clic su Download Gateway VM image for Hyper-V.
2. Estrarre la VHDX. Una VHDX viene usata per una sola VM; crearne copie per le VM aggiuntive.
3. Creare una VM di generazione 1 con almeno 4096 MB di memoria all’avvio e due processori virtuali. Collegare la VHDX esistente.
4. Per la distribuzione con due interfacce, aggiungere una seconda scheda di rete. Se si usano VLAN, assegnare gli ID VLAN appropriati.

2A. Creare un gateway locale

1. Aprire My Products > ZTNA > Gateways > Add gateway.
2. In Gateway Mode, selezionare On-premises.
3. Inserire il nome del gateway, il FQDN del gateway e il dominio delle risorse.
4. In Platform type, selezionare VMware ESXi o Hyper-V in base all’host.
5. In Deployment mode, selezionare One-arm o Two-arm.
6. Configurare le interfacce. Con DHCP è obbligatoria una prenotazione. Con Static IP, indicare indirizzo IP, sottorete e server DNS. Se una distribuzione con due interfacce raggiunge applicazioni in più reti interne, aggiungere le Static routes.
7. Caricare il certificato wildcard.
8. Fare clic su Save and generate file. Lo stato iniziale è Waiting for Deployment; viene generata l’ISO di avvio specifica.
9. Sulla firewall aprire in ingresso solo TCP 80 e 443, creare il DNAT di entrambe le porte verso l’IP esterno del gateway o la VIP del cluster e bloccare tutte le altre porte in ingresso. Non usare un reverse proxy.

2B. Creare un Sophos Cloud Gateway come VM

1. Convalidare prima il dominio in My Products > ZTNA > Settings > Domains > Add domain.
2. Sophos Fusion genera un CNAME, per esempio 5ccdee2b04764c75ac252a0f91f161b7.cert.prod.ztna.access.sophos.com. Pubblicare presso il proprio provider DNS il valore esatto generato per il proprio tenant.
3. Attendere la propagazione DNS e fare clic su Validate in Settings > Domains. Proseguire solo quando lo stato risulta Validated.
4. Fare clic su Add gateway, selezionare Sophos Cloud in Gateway Mode e inserire il nome del gateway e il FQDN del gateway. Il FQDN del gateway deve corrispondere al valore indicato durante la registrazione dell’applicazione ZTNA.
5. Selezionare la Domain convalidata, il Platform type appropriato, l’Identity provider e, in Points of Presence, la regione più vicina al data center.
6. Selezionare One-arm o Two-arm, configurare le interfacce con indirizzo prenotato o statico e, se necessario, le rotte statiche. Caricare il certificato wildcard.
7. Fare clic su Save and generate file. Copiare il dominio alias generato nella finestra Gateway added e pubblicarlo come CNAME del FQDN del gateway nel DNS pubblico.
8. Sull’interfaccia esterna aprire in uscita solo TCP 443. Per questo modello non si configura alcuna pubblicazione DNAT in ingresso della VM.

Da ZTNA 2.1 è configurato per impostazione predefinita un punto di accesso secondario adiacente al PoP primario. È possibile disabilitarlo in Settings. Scegliere comunque un PoP primario vicino al data center.

2C. Creare un Sophos Cloud Gateway su Sophos Firewall

Questa opzione è adatta anche alle risorse in Azure: distribuire prima Sophos Firewall come appliance SFOS virtuale su una piattaforma supportata, gestirla centralmente e poi configurare il gateway ZTNA su quella firewall. Non si tratta della VM gateway separata dei punti 2A o 2B; i relativi requisiti ESXi/Hyper-V non sono istruzioni per la distribuzione in Azure.

1. Verificare che sia installato SFOS 19.5 MR3 o successivo e che la firewall sia gestita centralmente in Sophos Fusion. Se la firewall non è ancora registrata, usare Register sulla firewall con le credenziali di Super Admin oppure con l’OTP generato dal Super Admin.
2. Convalidare il dominio come in 2B.
3. Aprire My Products > ZTNA > Gateways > Add gateway e selezionare Gateway Mode: Sophos Cloud.
4. Inserire il nome del gateway e il FQDN del gateway, selezionare la Domain convalidata e impostare Platform type su Firewall.
5. In Firewall, selezionare il dispositivo SFOS. L’elenco mostra solo firewall gestite centralmente dalla versione 19.5 MR3. È possibile scegliere la firewall attiva di una coppia HA; in questo modo traffico e servizi possono essere trasferiti in caso di failover.
6. Selezionare Identity provider e Points of Presence, caricare il certificato e fare clic su Save. Il gateway dovrebbe diventare attivo dopo circa cinque minuti.
7. Aggiungere presso il provider di identità il diverso URL di reindirizzamento https://<externer-Gateway-FQDN>/ztna-oauth2/callback.

Per l’accesso amministrativo, Sophos consiglia di utilizzare il portale Webadmin come risorsa ZTNA anziché accedervi direttamente tramite WAN. Prima di limitare un accesso WAN esistente, verificare l’accesso ZTNA con un amministratore autorizzato e mantenere disponibile un percorso di gestione alternativo approvato. Restano valide le limitazioni HA e dei portali indicate di seguito.

Sulle firewall gestite centralmente, il Control Center mostra lo stato ZTNA: Active dopo la configurazione, Not configured se non è stato configurato. Questa indicazione conferma l’integrazione, non il funzionamento dell’accesso alle risorse; restano necessari i controlli di DNS, certificato e accesso pilota della sezione di validazione.

Limiti di questa variante:

• In una distribuzione HA attiva-attiva, il portale Webadmin della firewall non è raggiungibile tramite ZTNA.
• Il portale utente e il portale VPN della firewall non sono supportati tramite il gateway ZTNA.
• Negli altri casi, il portale Webadmin può essere configurato come tipo di risorsa Web Admin Portal. Per l’accesso senza agente, il dominio alias generato viene pubblicato come CNAME pubblico; per l’accesso tramite agente, l’agente intercetta il FQDN esterno.

3. Creare facoltativamente un cluster di VM

Creare il cluster prima di scaricare le ISO di avvio:

1. Aprire il nuovo gateway e fare clic su Add/Edit instances > Add another instance. Il clustering viene attivato automaticamente.
2. Inserire un IP virtuale del cluster ancora inutilizzato, nello stesso intervallo IP delle istanze. Con una distribuzione a due interfacce e un load balancer esterno, lasciare vuota la VIP esterna del cluster.
3. Inserire il nome della VM e l’IP dell’interfaccia; per una distribuzione con due interfacce, gli IP interno ed esterno.
4. Ripetere per almeno tre istanze. Sono supportate da tre a nove istanze, sempre in numero dispari.
5. Puntare il DNAT di un gateway locale alla VIP esterna del cluster. Almeno la metà dei nodi deve rimanere attiva.

4. Collegare l’ISO di avvio e approvare la registrazione

Ogni ISO è associata in modo univoco a un gateway o a un’istanza e non può essere riutilizzata.

• ESXi: montare l’ISO nell’unità CD/DVD e selezionare Connect e Connect at Power on. È possibile rimuovere un dispositivo seriale esistente.
• Hyper-V: nelle impostazioni della VM selezionare IDE Controller 1 > Image file per l’unità DVD e montare l’ISO.
• Avviare la VM solo a questo punto. L’ISO deve rimanere collegata anche dopo un avvio riuscito.
• Aprire i dettagli del gateway. Lo stato passa da Waiting for Deployment a Awaiting Approval oppure Waiting for gateway approval.
• Fare clic su Approve. Per un cluster, approvare solo la prima istanza; le altre vengono gestite successivamente.
• L’approvazione può richiedere fino a dieci minuti. Verificare lo stato finale specifico della piattaforma: locale su ESXi Connected, locale su Hyper-V Active, Sophos Cloud su ESXi Active e Connected, Sophos Cloud su Hyper-V Active.

Verificare correttamente DNS e percorso dei dati

I server DNS pubblici e privati svolgono compiti diversi:

Gateway locale

• Con agente: l’agente intercetta la richiesta per l’applicazione privata e le assegna un indirizzo dell’intervallo 100.64.x.x. Per stabilire il tunnel, risolve il FQDN del gateway tramite un record A pubblico nell’IP del gateway. Il gateway risolve quindi il FQDN dell’applicazione tramite il server DNS privato.
• Senza agente: un CNAME pubblico dell’applicazione punta al FQDN del gateway; il relativo record A pubblico punta all’IP del gateway. Il gateway interroga il server DNS privato per individuare la destinazione interna dell’applicazione.

Sophos Cloud Gateway

• Con agente: il DNS pubblico risolve l’applicazione privata nel dominio alias associato. Questo conduce al gateway attraverso il PoP Sophos Cloud. Il gateway risolve poi la destinazione interna tramite il DNS privato.
• Senza agente: il CNAME pubblico della risorsa punta al dominio alias generato da Sophos. Per ogni nuova risorsa senza agente, il gateway avvia un nuovo tunnel TCP 443 verso il PoP. Il PoP associa la richiesta al gateway in base all’alias.

La connessione dall’agente al gateway o al PoP usa TLS reciproco. Sono documentati TLS 1.2 e versioni successive, oltre a protocolli di cifratura con chiavi fino a 256 bit.

L’agente ZTNA modifica l’adattatore TAP predefinito. Per questo nslookup può sembrare non funzionare con nomi esterni a ZTNA. Specificare esplicitamente il server DNS effettivamente responsabile:

nslookup <FQDN> <DNS-Server>

Convalida e risultato atteso

Non considerare sufficiente il solo stato verde del gateway. Usare un utente di prova con accesso limitato e una sola risorsa di test.

1. Gestione: in My Products > ZTNA > Gateways, il gateway è Active o Connected. Nei Gateway Details, verificare la versione software e, per i cluster, tutti i nodi.
2. DNS pubblico: per il gateway locale, il record A del gateway e, se necessario, il CNAME della risorsa restituiscono l’IP pubblico previsto. Per il Cloud Gateway, i CNAME di convalida del dominio, del gateway e delle risorse corrispondono esattamente ai valori generati da Sophos.
3. DNS privato: il gateway riesce a risolvere il FQDN della risorsa interna nell’IP del server interno.
4. Certificato: FQDN, ambito del wildcard, catena, validità e chiave privata sono corretti. Il browser o l’agente non mostrano avvisi di attendibilità.
5. Rete: per il gateway locale, TCP 80 e 443 raggiungono le regole DNAT previste; le altre porte in ingresso sono bloccate. Per il Cloud Gateway, il tunnel TCP 443 in uscita funziona senza pubblicazione in ingresso.
6. Accesso: l’utente pilota autorizzato raggiunge solo l’applicazione assegnata. Un utente di prova non autorizzato non ottiene l’accesso.
7. Applicazione: verificare non soltanto l’accesso, ma anche una transazione reale e circoscritta. Il percorso di ritorno funziona e l’applicazione vede l’origine di connessione prevista.
8. Stabilità: eseguire un test dall’esterno e, se previsto, dalla stessa rete del gateway. Il secondo test conferma in particolare MASQ e il percorso di ritorno.
9. Cluster: non arrestare alcun nodo al di fuori di un test di manutenzione e failover approvato. Durante un test pianificato, almeno la metà delle istanze resta attiva e le richieste vengono inoltrate attraverso i nodi rimanenti.

Se il risultato atteso manca, passare al sintomo pertinente nella sezione seguente. Non modificare contemporaneamente DNS, certificato, NAT e policy.

Per un’analisi separata del livello firewall sono disponibili Verificare una regola firewall con Log Viewer, Policy Test e Packet Capture e Comprendere il NAT su Sophos Firewall.

Risoluzione dei problemi per sintomo

Il gateway resta in «Waiting for Deployment» o non raggiunge Sophos Fusion

1. Verificare che l’ISO univoca sia collegata esattamente alla VM corretta e che Connect at Power on sia attivo.
2. Verificare l’ora dell’host e il fuso orario UTC.
3. Verificare l’IP statico o la prenotazione DHCP, il DNS e le destinazioni consentite; ztna.apu.sophos.com richiede TCP 22.
4. Verificare la presenza di un’eccezione alla decrittazione TLS per wsserver-<Gateway-FQDN>.
5. Eseguire la diagnostica della VM in vSphere o Hyper-V Manager.

Lo stato è in attesa di approvazione

Aprire i dettagli del gateway e fare clic su Approve. Attendere fino a dieci minuti. Per un cluster, approvare solo la prima istanza. Se lo stato non cambia, verificare prima connettività e ora anziché creare nuovamente altre istanze.

Il gateway smette di funzionare dopo una modifica DHCP o di rete

Il gateway non gestisce la modifica del proprio indirizzo IP. Ripristinare l’assegnazione originale dell’indirizzo e impostare una prenotazione DHCP o un indirizzo statico. Verificare quindi DNS, DNAT e, per i cluster, le destinazioni VIP. Una modifica IP pianificata non è una semplice modifica a caldo: deve essere trattata come una nuova distribuzione.

L’autenticazione funziona, ma la risorsa no

1. Risolvere il FQDN della risorsa interrogando direttamente il server DNS privato.
2. Verificare la rotta e la regola firewall che consente la connessione dal gateway alla porta di destinazione documentata.
3. In una distribuzione con due interfacce, verificare le rotte statiche verso le altre reti interne.
4. Per gli accessi dalla stessa rete del gateway, verificare la regola MASQ e il routing asimmetrico.
5. Verificare se l’applicazione usa porte dinamiche o moltissime porte; tali applicazioni non sono supportate.

L’accesso esterno a un gateway locale non funziona

Verificare il record A pubblico, TCP 80 e 443, entrambe le regole DNAT e il loro IP di destinazione o la VIP del cluster. Accertarsi che non vi sia un reverse proxy a monte. Le altre porte in ingresso devono rimanere bloccate.

Il Cloud Gateway o una risorsa senza agente non è raggiungibile

Verificare nell’ordine seguente:

1. stato del dominio Validated;
2. CNAME del gateway e della risorsa rispetto ai domini alias generati in Sophos Fusion;
3. TCP 443 in uscita dal gateway verso il PoP;
4. risoluzione DNS privata dal gateway all’applicazione;
5. regione PoP corretta e, per i gateway su firewall, l’URL di reindirizzamento OAuth2 specifico.

nslookup restituisce risultati errati dopo l’installazione dell’agente

L’agente imposta l’adattatore TAP ZTNA come predefinito. Ripetere la query specificando esplicitamente il server DNS. Un errore tramite l’adattatore TAP non dimostra che il normale server DNS non conosca il nome.

Errori del certificato

Verificare l’ambito del wildcard, la catena completa, la chiave privata e l’algoritmo. P-384/P-521 con ECDSA e RSA sotto i 2048 bit non sono supportati. Confrontare FQDN del gateway, dominio delle risorse e nomi sul certificato prima di caricare un nuovo certificato.

Pacchetto diagnostico per Sophos Support

Per gateway VM su ESXi o Hyper-V:

1. Aprire Gateway Details > Troubleshooting logs.
2. Fare clic su Generate logs. La generazione può richiedere alcuni minuti.
3. Scaricare la nuova voce nella colonna Troubleshooting log. Scade dopo un’ora.
4. Se necessario, abilitare l’accesso temporaneo per il supporto nei dettagli del gateway e trasmettere il token visualizzato esclusivamente a Sophos Support.

Questa funzione di registrazione dei log non è disponibile per il gateway integrato in Sophos Firewall.

Ritorno sicuro alla configurazione precedente o dismissione

Distinguere tra modifica della configurazione, aggiornamento di un gateway VM, cambio del firmware della firewall ed eliminazione definitiva. Queste operazioni non prevedono le stesse procedure di ritorno.

Prima di ogni modifica

• Registrare modalità del gateway, FQDN, IP, VIP del cluster, piattaforma, versione, certificato, CNAME e record A pubblici, DNAT/SNAT, rotte statiche, risorse assegnate e gruppo pilota.
• Verificare quali risorse e utenti dipendono dal gateway e concordare una finestra di manutenzione.
• Nella fase pilota modificare un solo livello per volta. Annotare gli ultimi valori DNS e firewall funzionanti.

Spostare le risorse su un gateway firewall

Per la migrazione documentata da un gateway esistente a un gateway firewall:

1. Configurare completamente il gateway firewall.
2. Aggiungere il suo nuovo URL di reindirizzamento OAuth2 presso il provider di identità.
3. Aprire Resources & access, selezionare la risorsa e impostare Gateway sul gateway firewall.
4. Per l’accesso senza agente, pubblicare il nuovo dominio alias della firewall come CNAME pubblico.
5. Convalidare con un utente ad accesso limitato. Rimuovere il vecchio valore DNS o il vecchio gateway solo dopo un test riuscito dell’applicazione.

Eliminare un gateway

Nei dettagli del gateway è disponibile Delete. Le fonti associate, tuttavia, non descrivono né il ripristino di un gateway eliminato né uno smantellamento automatico transazionalmente sicuro di DNS, NAT, risorse e certificati. Pertanto:

1. Non eliminare il gateway come primo passo del rollback.
2. Spostare o disabilitare prima le risorse dipendenti nella finestra di modifica concordata e verificare che nessun accesso produttivo passi ancora dal gateway.
3. Rimuovere poi le regole DNS pubbliche e firewall obsolete in base all’elenco raccolto in precedenza.
4. Eliminare il gateway solo dopo l’approvazione dei responsabili delle applicazioni e della rete.
5. Se le dipendenze o il percorso di ripristino non sono chiari, fermarsi prima di usare Delete e rivolgersi a Sophos Support.

Ritorno alla versione precedente dopo gli aggiornamenti

Le istruzioni esaminate non descrivono un downgrade per gli aggiornamenti dei gateway VM. Se un aggiornamento fallisce, non tentare di ripristinare l’immagine con una procedura non documentata: generare i log, mantenere l’accesso tramite l’istanza rimasta invariata o il cluster e rivolgersi a Sophos Support.

Per un gateway integrato in Sophos Firewall si applica la procedura documentata di ritorno al firmware precedente:

1. Verificare la validità dell’abbonamento al supporto ed eseguire il backup della configurazione della firewall.
2. Prima del cambio, verificare che la versione di destinazione supporti il numero di gateway configurati; i gateway eccedenti devono essere eliminati prima del cambio del firmware.
3. Pianificare il cambio fuori dagli orari di punta. La firewall interrompe le sessioni e si riavvia.
4. In Backup and firmware > Firmware, caricare una versione compatibile e avviarla con Upload and boot, oppure avviare un’immagine già inattiva con Boot firmware image.
5. Il firmware attivo e quello precedente, con le rispettive configurazioni, risiedono su partizioni separate. Un rollback al firmware precedente ripristina quindi anche la configurazione allo stato precedente.
6. Dopo il riavvio, accedere e verificare il firmware attivo in alto a sinistra nel Control Center, quindi lo stato del gateway, il DNS e l’accesso pilota.

Gestione, revisione e ciclo di vita

Aggiornare un gateway VM

In Gateways, un segno di spunta verde accanto al numero di versione indica che è disponibile una versione per la VM. Fare clic sul numero di versione, selezionare la versione di destinazione e pianificare l’aggiornamento oppure scegliere Now. Se è necessario un riavvio, l’interfaccia mostra un avviso; pianificarlo in una finestra di manutenzione. Questa funzione vale solo per i gateway ESXi e Hyper-V. Un gateway su firewall si aggiorna tramite il firmware SFOS.

Stato della verifica al 21 ottobre 2026: il 6 ottobre 2026, Sophos ha annunciato gli aggiornamenti 2.2.1 per l’applicazione e 2.3.0 per l’immagine di base. Si applicano alle VM gateway ZTNA gestite dal cliente su ESXi e Hyper-V. Per le correzioni di sicurezza incluse nella versione 2.3.0, Sophos raccomanda di avviare il processo di upgrade tempestivamente. Le due fasi vengono convalidate separatamente:

1. Verificare la versione di partenza e il percorso di upgrade proposto. Un vecchio gateway con 2.1.2 non deve passare direttamente a 2.2.1; chiarire prima le versioni intermedie necessarie in base alla sequenza delle release e ai passaggi proposti in Fusion.
2. Eseguire o pianificare l’aggiornamento dell’applicazione proposto alla versione 2.2.1.
3. Attendere che il gateway mostri nuovamente lo stato Active. Tutti i test nella console di diagnostica del gateway devono essere superati prima di iniziare la fase successiva.
4. Aggiornare poi l’immagine di base alla versione 2.3.0. Confermare nuovamente lo stato Active, l’esito positivo della diagnostica del gateway e l’accesso pilota descritto sopra.

Sophos indica circa 30 minuti per aggiornamento per un singolo nodo; con più nodi, il tempo necessario aumenta di conseguenza. Questi aggiornamenti del gateway non richiedono un aggiornamento dell’agente ZTNA. Un gateway Sophos Firewall non necessita di questi aggiornamenti VM e resta nel processo di aggiornamento del firmware SFOS. Se la diagnostica fallisce, interrompere il passaggio alla fase successiva; la sezione sul rollback degli aggiornamenti resta valida.

Le note di rilascio esaminate riportano ZTNA 2.2 del 13 gennaio 2026 per ESXi e Hyper-V, sia nelle distribuzioni locali sia in quelle Sophos Cloud, e indicano l’aggiornamento come obbligatorio per via delle nuove funzionalità richieste. Prima della finestra di manutenzione verificare comunque sempre la versione di destinazione offerta in Sophos Fusion e le note di rilascio aggiornate; da questa versione storica non dedurre né una data EOL né la versione di destinazione attuale.

La cronologia dei rilasci cita inoltre un timeout di inattività configurabile per i tunnel agente-gateway e la disattivazione del Resource Connection Pooling dalla versione 2.1.2. Per la 2.2 documenta correzioni per le connessioni intermittenti delle risorse con agente attraverso un gateway locale, uno stato Updating che rimaneva bloccato dopo l’aggiornamento dell’immagine, messaggi diagnostici fuorvianti sui pod del cluster e una race condition nei pod Kubernetes. Usare questa cronologia per valutare modifiche e problemi, non al posto della vista aggiornata dei dettagli del gateway.

Revisione periodica

Verificare almeno secondo il proprio ciclo di manutenzione:

• stato del gateway e dei nodi, versione installata e versione disponibile;
• validità e catena completa del certificato;
• CNAME pubblici di convalida del dominio, del gateway e delle risorse;
• risoluzione DNS privata e rotte, regole DNAT, SNAT e firewall ancora necessarie;
• regione PoP, PoP secondario e latenza effettiva del Cloud Gateway;
• gruppi di utenti sincronizzati e abilitati alla sicurezza, nonché il provider di identità;
• assegnazioni delle risorse ai gateway e gateway non più necessari;
• procedure diagnostiche e di supporto, finestre di manutenzione e responsabili.

Non pubblicare affermazioni su periodi di transizione, scadenze di migrazione, ritiro o EOL senza una comunicazione di prodotto aggiornata e consultabile. Le fonti disponibili documentano la gestione e lo stato dei rilasci, ma non tali date del ciclo di vita.

Guide correlate già disponibili

Questo runbook si conclude intenzionalmente ai confini del gateway. La configurazione completa del servizio di directory e del provider di identità, l’installazione o la rimozione dell’agente ZTNA, la diagnosi dei problemi specifici dell’agente, le regole di accesso alle risorse e le architetture particolari con più controller di dominio sono trattate nelle rispettive guide già disponibili. Le guide di base collegate sopra su Zero Trust, accesso remoto, certificati, DNAT e diagnostica firewall completano la procedura del gateway senza duplicare queste procedure separate.