Planera, driftsätt och hantera Sophos ZTNA Gateway

En Sophos ZTNA Gateway kopplar behöriga användare till interna applikationer. Det finns tre stödda sätt att driftsätta den: en lokal gateway-VM på VMware ESXi eller Microsoft Hyper-V, en Sophos Cloud Gateway-VM på någon av dessa hypervisorer eller en Sophos Cloud Gateway på en centralt hanterad Sophos Firewall. Den här driftguiden tar dig från val till godkännande och en säker väg tillbaka. Inför valet mellan ZTNA och traditionell fjärråtkomst kan du läsa Sophos Connect eller SSL VPN: Vilken fjärråtkomstlösning passar? och Zero Trust enkelt förklarat: ZTNA i stället för traditionellt VPN.

Det aktuella gränssnittet heter Sophos Fusion; äldre hjälptexter och vissa bilder använder fortfarande Sophos Central. De aktuella sökvägar och fältnamn som skrivs ut här gäller om en bild visar något annat.

Syfte och kort svar

Välj gatewaytyp utifrån dataväg och driftansvar, inte antalet klick:

En VM kan driftsättas med ett nätverksgränssnitt eller två nätverksgränssnitt. Med ett gränssnitt används det externa gränssnittet för både inkommande och utgående trafik, vilket minimerar ändringar i infrastrukturen. Med två gränssnitt separeras externt och internt gränssnitt; det kräver två nätverkskort och eventuellt statiska rutter. Enligt tillverkaren ger detta alternativ bäst säkerhet och genomströmning. Den separata guiden Publicera en server med DNAT på Sophos Firewall förklarar brandväggsfunktionen bakom detta; portkraven för ZTNA följer nedan.

Förutsättningar, licens och roller

Licens och administratörsroller

• ZTNA-funktionerna kräver rätt licens. I versionsinformationen för gatewayen anges uttryckligen vilka funktioner som är licensberoende.
• Sophos Fusion Firewall Management kräver en betald prenumeration utöver brandväggens baslicens.
• För att registrera en brandvägg i Sophos Fusion krävs en Central Super Admin. Alternativt kan denna administratör skapa ett engångslösenord (OTP) utifrån brandväggens serienummer och lämna det till brandväggsadministratören; engångslösenordet gäller i 14 dagar.
• De tilldelade användargrupperna måste vara synkroniserade i Sophos Fusion. Microsoft Entra ID eller Active Directory stöds som katalogtjänst. Microsoft Entra ID, Okta och lokalt Active Directory finns dokumenterade som identitetsleverantörer.
• Entra ID-grupper måste vara säkerhetsaktiverade. Det sker automatiskt för grupper som skapas direkt i Entra ID, men kan vara annorlunda för grupper som importeras från AD eller skapas i Microsoft 365-portalen.

Den granskade gatewaydokumentationen anger ingen mer specifik administratörsroll för ZTNA. Om kontot inte ser menyerna eller åtgärderna som beskrivs ska du inte utöka behörigheterna genom att prova dig fram. Låt i stället en behörig Sophos Fusion-administratör kontrollera rolltilldelningen för den aktuella klientorganisationen.

Certifikat

Gatewayen kräver ett wildcard-certifikat. Certifikat från Let’s Encrypt eller en betrodd certifikatutfärdare stöds:

• RSA med minst 2048 bitar;
• ECDSA, dock inte med P-384 eller P-521.

Vid VM-driftsättning stöds ett enda wildcard-certifikat. Ha certifikatet och den privata nyckeln till hands. De kan laddas upp under Zertifikat i gatewayinformationen; alternativt kan Sophos Fusion skapa ett Let’s Encrypt-certifikat där.

Den praktiska anskaffningen beskrivs i Skapa ett Let’s Encrypt-wildcard-certifikat. För certifikat som hanteras direkt på Sophos Firewall finns ett separat arbetsflöde i Hantera Let’s Encrypt-certifikat på Sophos Firewall.

Värd, tid och kapacitet

SSD-enheter rekommenderas för jämnare disk-I/O. Värdens datum och tid måste stämma och tidszonen måste vara UTC. Gatewayen övertar värdens tid och kan inte fungera korrekt om den är fel.

Nätverk, IPv4 och tillåtna mål

• Använd varken 10.42.0.0/16, 10.43.0.0/16 eller 10.108.0.0/16 för gatewayen. Dessa nät är reserverade för interna tjänster.
• IPv6 stöds inte för gateways. Tilldela inte gatewayen eller slutenheterna IPv6-adresser via DHCP i det här scenariot. På redan konfigurerade slutenheter måste IPv6 inaktiveras manuellt.
• Använd en statisk IPv4-adress eller en DHCP-reservation. En gateway kan inte hantera om dess IP-adress ändras senare.
• Om användare ansluter till ZTNA-resurser från samma nät som gatewayen förhindrar en SNAT-regel av typen MASQ asymmetrisk routning.
• Om det finns flera gatewaynoder måste alla ligga i samma undernät och ha mycket låg latens mellan sig.

För en lokal gateway bakom en brandvägg måste följande mål kunna nås, normalt via 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, om Okta används som identitetsleverantör
• wsserver-<Gateway-FQDN>
• gatewayens FQDN som anges i gatewayinställningarna

Dessutom behöver ztna.apu.sophos.com TCP 22. Om en brandvägg framför gatewayen dekrypterar TLS ska wsserver-<Gateway-FQDN> undantas från dekrypteringen.

ZTNA styr åtkomst till webbaserade och lokala applikationer. Lokala applikationer kräver ZTNA-agenten. Applikationer med dynamisk porttilldelning eller mycket många portar, exempelvis äldre VoIP-produkter, stöds inte. Agenten finns dokumenterad för Windows 10 1803 eller senare och macOS Big Sur 11 eller senare.

Konfiguration med anpassningsbara exempelvärden

Använd egna värden. Följande namn visar bara hur värdena hör ihop:

Aktuella sökvägar i gränssnittet

De aktuella tyskspråkiga hjälptexterna anger följande sökvägar och åtgärder:

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

1. Driftsätt VM-avbildningen

För ESXi:

1. Öppna Geräte > Installer, sök efter Zero Trust Network Access och ladda ned gatewayavbildningen.
2. Godkänn licensavtalet och eventuella formulär för exportefterlevnad.
3. Driftsätt OVA-filen i vSphere via OVF-Vorlage bereitstellen.
4. Inaktivera automatisk start. VM:en får inte startas utan ISO-filen som skapas senare.

För Hyper-V:

1. Öppna Geräte > Installer > Zero Trust Network Access och ladda ned Gateway-VM-Image für Hyper-V.
2. Extrahera VHDX-filen. En VHDX-fil används bara för en VM; skapa kopior för ytterligare VM:ar.
3. Skapa en generation 1-VM med minst 4096 MB startminne och två virtuella processorer. Anslut den befintliga VHDX-filen.
4. Lägg till ett andra nätverkskort vid driftsättning med två gränssnitt. Tilldela rätt VLAN-ID:n om VLAN används.

2A. Skapa en lokal gateway

1. Öppna Meine Produkte > ZTNA > Gateways > Gateway hinzufügen.
2. Välj Lokal under Gateway-Modus.
3. Ange Gateway-Name, Gateway-FQDN och Domäne für Ressourcen.
4. Välj VMware ESXi eller Hyper-V under Plattformtyp, beroende på värden.
5. Välj Einarmig eller Zweiarmig under Bereitstellungsmodus.
6. Ange gränssnitten. Med DHCP krävs en reservation. Med Statische IP anger du IP-adress, undernät och DNS-server. Om en driftsättning med två gränssnitt ska nå applikationer i flera interna nät anger du Statische Routen.
7. Ladda upp wildcard-certifikatet.
8. Klicka på Speichern und Datei erstellen. Statusen är först Warten auf Bereitstellung; en unik start-ISO skapas.
9. Öppna endast TCP 80 och 443 inkommande i brandväggen, skapa DNAT för båda portarna till gatewayens externa IP-adress respektive klustrets VIP och blockera alla andra inkommande portar. Använd ingen omvänd proxy.

2B. Skapa Sophos Cloud Gateway som VM

1. Validera först domänen under Meine Produkte > ZTNA > Einstellungen > Domänen > Domäne hinzufügen.
2. Sophos Fusion skapar en CNAME-post, exempelvis 5ccdee2b04764c75ac252a0f91f161b7.cert.prod.ztna.access.sophos.com. Publicera exakt det värde som skapats för din klientorganisation hos din DNS-leverantör.
3. Vänta tills DNS-ändringen har spridits och klicka på Validieren under Einstellungen > Domänen. Fortsätt först när statusen är validiert.
4. Klicka på Gateway hinzufügen, välj Sophos Cloud under Gateway-Modus och ange Gateway-Name och Gateway-FQDN. Gatewayens FQDN måste motsvara värdet som anges vid registrering av ZTNA-applikationen.
5. Välj den validerade Domäne, rätt Plattformtyp, Identitätsanbieter och den region under Points of Presence som ligger närmast datacentret.
6. Välj Einarmig eller Zweiarmig, konfigurera reserverade eller statiska gränssnitt och vid behov statiska rutter. Ladda upp wildcard-certifikatet.
7. Klicka på Speichern und Datei erstellen. Kopiera aliasdomänen som skapats i dialogrutan Gateway hinzugefügt och publicera den som en CNAME-post för gatewayens FQDN i publik DNS.
8. Öppna endast TCP 443 utgående på det externa gränssnittet. För den här modellen ska ingen inkommande DNAT-publicering av VM:en konfigureras.

Sedan ZTNA 2.1 konfigureras som standard en sekundär anslutningspunkt nära den primära PoP:en. Den kan inaktiveras under Einstellungen. Välj ändå en primär PoP nära datacentret.

2C. Skapa Sophos Cloud Gateway på Sophos Firewall

1. Kontrollera att brandväggen kör SFOS 19.5 MR3 eller senare och hanteras centralt i Sophos Fusion. Om brandväggen ännu inte är registrerad använder du Register på brandväggen med inloggningsuppgifter för en Super Admin eller det engångslösenord som en Super Admin skapat.
2. Validera domänen enligt 2B.
3. Öppna Meine Produkte > ZTNA > Gateways > Gateway hinzufügen och välj Gateway-Modus: Sophos Cloud.
4. Ange Gateway-Name och Gateway-FQDN, välj den validerade Domäne och sätt Plattformtyp till Firewall.
5. Välj SFOS-enheten under Firewall. Listan visar bara centralt hanterade brandväggar från 19.5 MR3. I ett HA-par kan den aktiva brandväggen väljas; därmed kan trafik och tjänster tas över vid failover.
6. Välj Identitätsanbieter och Points of Presence, ladda upp certifikatet och klicka på Speichern. Gatewayen bör vara aktiv efter cirka fem minuter.
7. Lägg till den särskilda omdirigerings-URL:en https://<externer-Gateway-FQDN>/ztna-oauth2/callback hos identitetsleverantören.

Begränsningar för den här varianten:

• Vid en aktiv–aktiv HA-driftsättning går det inte att nå brandväggens webbadministrationsportal via ZTNA.
• Brandväggens användarportal och VPN-portal stöds inte via ZTNA-gatewayen.
• Webbadministrationsportalen kan i övrigt läggas till som resurstypen Webadmin-Portal. Vid åtkomst utan agent publiceras den skapade aliasdomänen som en publik CNAME-post; vid agentbaserad åtkomst fångar agenten upp det externa FQDN-namnet.

3. Skapa eventuellt ett VM-kluster

Skapa klustret innan du laddar ned start-ISO-filerna:

1. Öppna den nya gatewayen och klicka på Instanzen hinzufügen/bearbeiten > Eine weitere Instanz hinzufügen. Klustring aktiveras automatiskt.
2. Ange en virtuell kluster-IP som inte redan används och som ligger i samma IP-intervall som instanserna. Vid driftsättning med två gränssnitt och extern lastbalanserare lämnas klustrets externa VIP tom.
3. Ange VM-namn och gränssnittets IP-adress; vid driftsättning med två gränssnitt anger du både intern och extern IP-adress.
4. Upprepa för minst tre instanser. Tre till nio instanser stöds, alltid ett udda antal.
5. Rikta DNAT för en lokal gateway mot klustrets externa VIP. Minst hälften av noderna måste förbli aktiva.

4. Anslut start-ISO:n och godkänn registreringen

Varje ISO är unikt knuten till en gateway respektive instans och får inte återanvändas.

• ESXi: Montera ISO-filen i CD/DVD-enheten och välj Verbinden samt Beim Einschalten verbinden. En befintlig seriell enhet kan tas bort.
• Hyper-V: Välj IDE Controller 1 > Image-Datei för DVD-enheten i VM-inställningarna och montera ISO-filen.
• Starta VM:en först därefter. ISO-filen måste förbli ansluten även efter en lyckad start.
• Öppna gatewayinformationen. Statusen ändras från Warten auf Bereitstellung till Warte auf Genehmigung respektive Warten auf Gateway-Genehmigung.
• Klicka på Genehmigen. För ett kluster godkänner du bara den första instansen; övriga instanser hanteras sedan automatiskt.
• Godkännandet kan ta upp till tio minuter. Kontrollera slutstatus för respektive plattform: lokal på ESXi Verbunden, lokal på Hyper-V Aktiv, Sophos Cloud på ESXi Aktiv och Verbunden, Sophos Cloud på Hyper-V Aktiv.

Kontrollera DNS och datavägen

Publika och privata DNS-servrar har olika uppgifter:

Lokal gateway

• Med agent: Agenten fångar upp begäran till den privata applikationen och tilldelar den en adress i 100.64.x.x. För att upprätta tunneln slår den upp gatewayens FQDN via en publik A-post till gatewayens IP-adress. Gatewayen slår därefter upp applikationens FQDN via den privata DNS-servern.
• Utan agent: En publik CNAME-post för applikationen pekar på gatewayens FQDN, vars publika A-post pekar på gatewayens IP-adress. Gatewayen frågar den privata DNS-servern efter applikationens interna mål.

Sophos Cloud Gateway

• Med agent: Publik DNS slår upp den privata applikationen till den tilldelade aliasdomänen. Den leder via Sophos Cloud PoP till gatewayen. Därefter slår gatewayen upp det interna målet via privat DNS.
• Utan agent: Resursens publika CNAME-post pekar på den aliasdomän som Sophos har skapat. För varje ny resurs utan agent initierar gatewayen en ny tunnel på TCP 443 till PoP:en. PoP:en kopplar begäran till gatewayen utifrån aliaset.

Anslutningen från agenten till gatewayen respektive PoP:en använder ömsesidig TLS. TLS 1.2 och senare samt krypteringsprotokoll med nyckellängder upp till 256 bitar finns dokumenterade.

ZTNA-agenten ändrar vilken TAP-adapter som används som standard. Därför kan nslookup skenbart misslyckas för namn utanför ZTNA. Ange uttryckligen den DNS-server som faktiskt ansvarar för uppslagningen:

nslookup <FQDN> <DNS-Server>

Validering och förväntat resultat

Nöj dig inte med att gatewayens status är grön. Använd en pilotanvändare med begränsade rättigheter och exakt en testresurs.

1. Hantering: Under Meine Produkte > ZTNA > Gateways har gatewayen status Aktiv eller Verbunden. Under Gateway-Details stämmer programvaruversionen och, för kluster, samtliga noder.
2. Publik DNS: För en lokal gateway ger gatewayens A-post och i förekommande fall resursens CNAME-post den planerade publika IP-adressen. För en Cloud Gateway motsvarar CNAME-posterna för domänvalidering, gateway och resurser exakt de värden Sophos har skapat.
3. Privat DNS: Gatewayen kan slå upp den interna resursens FQDN till den interna serverns IP-adress.
4. Certifikat: FQDN, wildcard-certifikatets täckning, kedja, giltighetstid och privata nyckel stämmer. Webbläsaren eller agenten visar ingen förtroendevarning.
5. Nätverk: För en lokal gateway träffar TCP 80 och 443 de avsedda DNAT-reglerna; övriga inkommande portar är blockerade. För en Cloud Gateway fungerar den utgående TCP 443-tunneln utan inkommande publicering.
6. Åtkomst: Den behöriga pilotanvändaren kan bara nå den tilldelade applikationen. En testanvändare utan behörighet får inte åtkomst.
7. Applikation: Kontrollera inte bara inloggningen utan även en verklig, avgränsad transaktion. Returvägen fungerar och applikationen ser anslutningens förväntade ursprung.
8. Stabilitet: Testa externt och, om det är aktuellt, från samma nät som gatewayen. Det andra testet bekräftar särskilt MASQ och returvägen.
9. Kluster: Stoppa inte någon nod utanför ett godkänt underhålls- och failovertest. Vid ett planerat test förblir minst hälften av instanserna aktiva och förfrågningar vidarebefordras via de andra noderna.

Om det förväntade resultatet uteblir går du till motsvarande symptom nedan. Ändra inte DNS, certifikat, NAT och policy samtidigt.

För separat analys av brandväggslagret finns Testa brandväggsregler med Log Viewer, Policy Test och Packet Capture och Förstå NAT på Sophos Firewall.

Felsökning utifrån symptom

Gatewayen stannar på ”Warten auf Bereitstellung” eller når inte Sophos Fusion

1. Kontrollera att den unika ISO-filen är ansluten till exakt rätt VM och att Beim Einschalten verbinden är aktiverat.
2. Kontrollera värdens tid och att tidszonen är UTC.
3. Kontrollera statisk IP-adress respektive DHCP-reservation, DNS och tillåtna mål; ztna.apu.sophos.com behöver TCP 22.
4. Kontrollera att wsserver-<Gateway-FQDN> är undantagen från TLS-dekryptering.
5. Kör VM-diagnostik i vSphere respektive Hyper-V Manager.

Statusen väntar på godkännande

Öppna gatewayinformationen och klicka på Genehmigen. Vänta upp till tio minuter. För ett kluster godkänner du bara den första instansen. Om statusen inte ändras ska du först kontrollera nåbarhet och tid i stället för att skapa nya instanser.

Gatewayen slutar fungera efter en DHCP- eller nätverksändring

Gatewayen kan inte hantera en ändrad IP-adress. Återställ den ursprungliga adresstilldelningen och inför en DHCP-reservation eller statisk adress. Kontrollera därefter DNS, DNAT och, för kluster, VIP-målen. Planerade IP-ändringar är inte enkla ändringar under drift utan måste behandlas som en ny driftsättning.

Inloggningen fungerar men inte resursen

1. Slå upp resursens FQDN direkt mot den privata DNS-servern.
2. Kontrollera rutten och brandväggens tillåtelse från gatewayen till den dokumenterade målporten.
3. Vid driftsättning med två gränssnitt kontrollerar du statiska rutter till andra interna nät.
4. Vid åtkomst från samma nät som gatewayen kontrollerar du MASQ-regeln och asymmetrisk routning.
5. Kontrollera om applikationen använder dynamiska eller mycket många portar; sådana applikationer stöds inte.

Extern åtkomst till en lokal gateway misslyckas

Kontrollera den publika A-posten, TCP 80 och 443, båda DNAT-reglerna och deras mål-IP respektive klustrets VIP. Säkerställ att ingen omvänd proxy ligger framför gatewayen. Övriga inkommande portar ska fortsatt vara blockerade.

Cloud Gateway eller en resurs utan agent kan inte nås

Kontrollera i följande ordning:

1. att domänstatusen är validiert;
2. gatewayens och resursens CNAME-poster mot aliasdomänerna som skapats i Sophos Fusion;
3. utgående TCP 443 från gatewayen till PoP:en;
4. privat DNS-upplösning från gatewayen till applikationen;
5. rätt PoP-region och, för brandväggsgateways, den särskilda OAuth2-omdirigerings-URL:en.

nslookup ger fel resultat efter att agenten installerats

Agenten gör ZTNA-TAP-adaptern till standard. Upprepa uppslagningen med en uttryckligen angiven DNS-server. Ett misslyckande via TAP-adaptern bevisar inte att den vanliga DNS-servern inte känner till namnet.

Certifikatfel

Kontrollera wildcard-certifikatets täckning, hela kedjan, den privata nyckeln och algoritmen. P-384/P-521 för ECDSA och RSA under 2048 bitar stöds inte. Jämför gatewayens FQDN, resursdomänen och certifikatnamnen innan du laddar upp ett nytt certifikat.

Diagnostikpaket för Sophos Support

För VM-gateways på ESXi eller Hyper-V:

1. Öppna Gateway-Details > Fehlerbehebungsprotokolle.
2. Klicka på Protokolle generieren. Det kan ta några minuter att skapa loggarna.
3. Ladda ned den nya posten i kolumnen Fehlerbehebungsprotokoll. Den upphör att gälla efter en timme.
4. Aktivera vid behov tidsbegränsad supportåtkomst i gatewayinformationen och lämna den visade token endast till Sophos Support.

Denna loggfunktion gäller inte för gatewayen som är integrerad i Sophos Firewall.

Säker återgång eller avveckling

Skilj mellan en konfigurationsändring, en uppdatering av en VM-gateway, ett byte av brandväggsfirmware och en permanent radering. Återgången är inte densamma i dessa fall.

Före varje ändring

• Dokumentera gatewayläge, FQDN, IP-adresser, klustrets VIP, plattform, version, certifikat, publika CNAME-/A-poster, DNAT/SNAT, statiska rutter, tilldelade resurser och pilotgrupp.
• Kontrollera vilka resurser och användare som är beroende av gatewayen och kom överens om ett underhållsfönster.
• Ändra bara ett lager åt gången under piloten. Spara de senast fungerande DNS- och brandväggsvärdena.

Flytta resurser till en brandväggsgateway

För den dokumenterade migreringen från en befintlig gateway till en brandväggsgateway:

1. Konfigurera brandväggsgatewayen fullt ut.
2. Lägg till dess nya OAuth2-omdirigerings-URL hos identitetsleverantören.
3. Öppna Ressourcen und Zugriff, välj resursen och sätt Gateway till brandväggsgatewayen.
4. För åtkomst utan agent publicerar du brandväggens nya aliasdomän som en publik CNAME-post.
5. Validera med en användare med begränsade rättigheter. Ta inte bort det gamla DNS-värdet eller den gamla gatewayen förrän applikationstestet har lyckats.

Radera gatewayen

Gateway löschen finns i gatewayinformationen. De tillhörande källorna beskriver dock varken hur en raderad gateway återställs eller någon transaktionssäker automatisk återställning av DNS, NAT, resurser och certifikat. Därför:

1. Använd inte radering som första steg vid återgång.
2. Flytta eller inaktivera först beroende resurser under det överenskomna ändringsfönstret och kontrollera att ingen produktionsåtkomst längre går via gatewayen.
3. Ta därefter bort föråldrade publika DNS-poster och brandväggsregler utifrån listan du upprättade i förväg.
4. Radera inte gatewayen förrän applikations- och nätverksansvariga har godkänt det.
5. Om beroenden eller återställningsväg är oklara ska du stanna före Gateway löschen och eskalera till Sophos Support.

Återgång vid uppdateringar

I de granskade instruktionerna beskrivs ingen nedgradering för uppdateringar av VM-gateways. Om en uppdatering misslyckas ska du inte försöka återställa avbildningen på ett odokumenterat sätt. Skapa loggar, upprätthåll åtkomst via den oförändrade instansen respektive klustret och eskalera till Sophos Support.

För en gateway integrerad i Sophos Firewall gäller den dokumenterade återgången för firmware:

1. Kontrollera att det finns en giltig supportprenumeration och säkerhetskopiera brandväggens konfiguration.
2. Kontrollera före bytet att målversionen stöder det konfigurerade antalet gateways; överskjutande gateways måste raderas före firmwarebytet.
3. Planera bytet utanför högtrafikperioder. Brandväggen avslutar sessioner och startar om.
4. Under Backup and firmware > Firmware kan du ladda upp en kompatibel version och starta den med Upload and boot eller starta en redan inaktiv avbildning med Boot firmware image.
5. Aktuell och föregående firmware ligger med respektive konfiguration på separata partitioner. En återgång till föregående firmware återställer därför också konfigurationen till dess tidigare tillstånd.
6. Logga in efter omstarten och kontrollera aktiv firmware längst upp till vänster i Control Center samt därefter gatewaystatus, DNS och pilotåtkomst.

Drift, översyn och livscykel

Uppdatera VM-gatewayen

Under Gateways visar en grön bock bredvid versionsnumret att en VM-version finns tillgänglig. Klicka på versionsnumret, välj målversion och schemalägg uppdateringen eller välj Jetzt. Om en omstart krävs visar gränssnittet en varning; planera den under ett underhållsfönster. Funktionen gäller bara ESXi- och Hyper-V-gateways. En brandväggsgateway uppdateras via SFOS-firmware.

Den granskade versionsinformationen listar ZTNA 2.2 från 13 januari 2026 för ESXi och Hyper-V, både vid lokal driftsättning och med Sophos Cloud, och betecknar uppgraderingen som obligatorisk på grund av nya nödvändiga funktioner. Kontrollera ändå alltid målversionen som erbjuds i Sophos Fusion och aktuell versionsinformation före underhållsfönstret. Härled varken ett EOL-datum eller en målversion för i dag ur denna historiska versionsuppgift.

Versionshistoriken nämner också en konfigurerbar timeout för inaktivitet i tunnlar mellan agent och gateway samt att Resource Connection Pooling stängts av från 2.1.2. För 2.2 dokumenterar den korrigeringar för intermittenta anslutningar till agentbaserade resurser via en lokal gateway, en status som fastnar på Updating efter uppdatering av avbildningen, missvisande diagnostikmeddelanden om klusterpoddar och ett konkurrensvillkor mellan Kubernetes-poddar. Använd historiken för att bedöma ändringar och fel, inte som ersättning för gatewayens aktuella detaljvy.

Regelbunden översyn

Kontrollera åtminstone enligt den egna underhållsrytmen:

• status för gateway och noder samt installerad och erbjuden version;
• certifikatets giltighetstid och hela kedjan;
• publika CNAME-poster för domänvalidering, gateway och resurser;
• privat DNS-upplösning samt rutter, DNAT-, SNAT- och brandväggsregler som fortfarande behövs;
• PoP-region, sekundär PoP och faktisk latens för Cloud Gateway;
• synkroniserade, säkerhetsaktiverade användargrupper och identitetsleverantören;
• tilldelning av resurser till gateways och gateways som inte längre behövs;
• rutiner för diagnostik och support, underhållsfönster och ansvariga personer.

Publicera inga uppgifter om övergångs- eller migrationsfrister, utfasning eller EOL utan ett aktuellt och läsbart produktmeddelande. De tillgängliga källorna stöder uppgifter om drift och versionsläge men inte några sådana livscykeldatum.

Relaterade befintliga guider

Den här driftguiden stannar avsiktligt vid gatewayens gränser. Fullständig konfiguration av katalogtjänst och identitetsleverantör, installation eller borttagning av ZTNA-agenten, agentspecifik felsökning, regler för resursåtkomst och särskilda lösningar med flera domänkontrollanter hör hemma i respektive befintlig guide. De ovan länkade grunderna om Zero Trust, fjärråtkomst, certifikat, DNAT och brandväggsdiagnostik kompletterar gatewayarbetsflödet utan att duplicera dessa separata förfaranden.