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:

Lokal gateway

• Plattformar som stöds: ESXi eller Hyper-V
• Dataväg och exponering: Gatewayen och dataplanet körs i kundens datacenter; gatewayen är nåbar från internet.
• Viktigaste nätverkskrav: Öppna endast TCP 80 och 443 inkommande på de externa gränssnitten, vidarebefordra båda portarna med DNAT och blockera alla andra inkommande portar. Placera ingen omvänd proxy framför gatewayen.

Sophos Cloud Gateway som VM

• Plattformar som stöds: ESXi eller Hyper-V
• Dataväg och exponering: Sophos hanterar ingången i molnet; VM:en kopplar Sophos Cloud till interna resurser och publiceras inte som en egen internetingång.
• Viktigaste nätverkskrav: Öppna endast TCP 443 utgående på gatewayens externa gränssnitt; ordna publika CNAME-poster och privat DNS-upplösning.

Sophos Cloud Gateway på Sophos Firewall

• Plattformar som stöds: centralt hanterad brandvägg som hårdvara, i molnet, virtuell eller som programvara från SFOS 19.5 MR3
• Dataväg och exponering: Ingen separat gateway-VM; autentisering och auktorisering sker i Sophos Cloud.
• Viktigaste nätverkskrav: Brandväggen måste hanteras från Sophos Fusion; planera för region, identitetsleverantör, certifikat och särskild omdirigerings-URL.

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 Certificate 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.

För skalning av gateway-VM:ar anger Sophos 10 000 agentanslutningar per nod och upp till 90 000 agentanslutningar i ett kluster med högst nio noder. Dessa tillverkaruppgifter garanterar ingen genomströmning och är inget mått på antal användare eller licenser. De ska inte generellt tillämpas på en gateway på Sophos Firewall eller på agentlösa webbläsarsessioner. Vid planeringen måste värdresurser, applikationsbelastning och önskad reservkapacitet vid nodbortfall bedömas separat; klusterreglerna och pilotkontrollerna nedan gäller fortfarande.

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. Den åtkomst till lokala, nativa applikationer som beskrivs här använder ZTNA-agenten. Agentlös RDP-/SSH-åtkomst via fullständig Protected Browser är en separat väg med egna resurser och policyer; webbläsartillägget räcker inte, och detta innebär inte generellt stöd för godtyckliga lokala protokoll. 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

Följande sökvägar och åtgärder använder de engelska gränssnittsetiketter som bekräftas i tillverkarens aktuella hjälp. Namn, gateway-FQDN och resursdomän beskrivs som tekniska inmatningsvärden, inte som obekräftade fältetiketter:

• My Products > ZTNA > Gateways och därefter Add gateway
• My Products > ZTNA > Settings > Domains
• Devices > Installers

1. Driftsätt VM-avbildningen

För ESXi:

1. Öppna Devices > Installers, 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 driftsättningsguiden.
4. Inaktivera automatisk start. VM:en får inte startas utan ISO-filen som skapas senare.

För Hyper-V:

1. Öppna Devices > Installers och klicka på Download Gateway VM image for Hyper-V under Zero Trust Network Access.
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 My Products > ZTNA > Gateways > Add gateway.
2. Välj On-premises under Gateway Mode.
3. Ange gatewaynamn, gateway-FQDN och resursdomän.
4. Välj VMware ESXi eller Hyper-V under Platform type, beroende på värden.
5. Välj One-arm eller Two-arm under Deployment mode.
6. Ange gränssnitten. Med DHCP krävs en reservation. Med Static 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 Static routes.
7. Ladda upp wildcard-certifikatet.
8. Klicka på Save and generate file. Statusen är först Waiting for Deployment; 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 My Products > ZTNA > Settings > Domains > Add domain.
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å Validate under Settings > Domains. Fortsätt först när statusen är Validated.
4. Klicka på Add gateway, välj Sophos Cloud under Gateway Mode och ange gatewaynamn och gateway-FQDN. Gatewayens FQDN måste motsvara värdet som anges vid registrering av ZTNA-applikationen.
5. Välj den validerade Domain, rätt Platform type, Identity provider och den region under Points of Presence som ligger närmast datacentret.
6. Välj One-arm eller Two-arm, konfigurera reserverade eller statiska gränssnitt och vid behov statiska rutter. Ladda upp wildcard-certifikatet.
7. Klicka på Save and generate file. Kopiera aliasdomänen som skapats i dialogrutan Gateway added 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 Settings. Välj ändå en primär PoP nära datacentret.

2C. Skapa Sophos Cloud Gateway på Sophos Firewall

Det här alternativet fungerar även för resurser i Azure: driftsätt först Sophos Firewall som en virtuell SFOS-appliance på en plattform som stöds, hantera den centralt och konfigurera sedan ZTNA-gatewayen på den brandväggen. Detta är inte den separata gateway-VM:en i 2A eller 2B; dess ESXi-/Hyper-V-krav är inte instruktioner för driftsättning i Azure.

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 My Products > ZTNA > Gateways > Add gateway och välj Gateway Mode: Sophos Cloud.
4. Ange gatewaynamn och gateway-FQDN, välj den validerade Domain och sätt Platform type 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 Identity provider och Points of Presence, ladda upp certifikatet och klicka på Save. 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.

För administrativ åtkomst rekommenderar Sophos webbadministrationsportalen som en ZTNA-resurs i stället för direkt åtkomst via WAN. Testa ZTNA-åtkomsten med en behörig administratör innan en befintlig WAN-åtkomst begränsas, och håll en godkänd alternativ hanteringsväg tillgänglig. HA- och portalbegränsningarna nedan gäller fortfarande.

På centralt hanterade brandväggar visar Control Center ZTNA-statusen: Active efter konfiguration, Not configured utan konfiguration. Detta visar integrationen, inte att resursåtkomsten fungerar; DNS-, certifikat- och pilottesterna i valideringsavsnittet behövs fortfarande.

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 Web Admin 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å Add/Edit instances > Add another instance. 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 Connect samt Connect at Power on. En befintlig seriell enhet kan tas bort.
• Hyper-V: Välj IDE Controller 1 > Image file 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 Waiting for Deployment till Awaiting Approval respektive Waiting for gateway approval.
• Klicka på Approve. 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 Connected, lokal på Hyper-V Active, Sophos Cloud på ESXi Active och Connected, Sophos Cloud på Hyper-V Active.

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 My Products > ZTNA > Gateways har gatewayen status Active eller Connected. 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å ”Waiting for Deployment” eller når inte Sophos Fusion

1. Kontrollera att den unika ISO-filen är ansluten till exakt rätt VM och att Connect at Power on ä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å Approve. 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 Validated;
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 > Troubleshooting logs.
2. Klicka på Generate logs. Det kan ta några minuter att skapa loggarna.
3. Ladda ned den nya posten i kolumnen Troubleshooting log. 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 Resources & access, 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

Delete 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 Delete 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 Now. 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.

Kontrollerat den 21 oktober 2026: Sophos presenterade den 6 oktober 2026 uppdateringarna 2.2.1 för applikationen och 2.3.0 för basimagen. De gäller kundhanterade ZTNA-gateway-VM:ar på ESXi och Hyper-V. På grund av säkerhetskorrigeringarna i 2.3.0 rekommenderar Sophos att uppgraderingsprocessen påbörjas snarast. De båda stegen valideras separat:

1. Kontrollera utgångsversionen och den erbjudna uppgraderingsvägen. En gammal gateway med 2.1.2 får inte hoppa direkt till 2.2.1; klargör först nödvändiga mellanversioner utifrån versionsordningen och stegen som erbjuds i Fusion.
2. Genomför eller schemalägg den erbjudna applikationsuppdateringen till 2.2.1.
3. Vänta tills gatewayen åter visar Active. Alla tester i gatewayens diagnoskonsol måste godkännas innan nästa steg påbörjas.
4. Uppdatera därefter basimagen till 2.3.0. Bekräfta åter Active, godkänd gatewaydiagnostik och pilotåtkomsten som beskrivs ovan.

Sophos anger ungefär 30 minuter per uppdatering för en enskild nod; med flera noder ökar tidsåtgången i motsvarande grad. Dessa gatewayuppdateringar kräver ingen uppdatering av ZTNA-agenten. En Sophos Firewall-gateway behöver inte dessa VM-uppdateringar utan följer SFOS-processen för firmware. Stoppa nästa steg om diagnostiken misslyckas; avsnittet om återställning efter uppdatering gäller fortfarande.

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.

Kontrollera AD-/Kerberos-problem separat efter gatewayuppdateringen

Uppgiften att gatewayuppdateringen inte kräver någon agentuppdatering beskriver uppgraderingsförutsättningen. Den bekräftar inte att varje fel på agentsidan därmed åtgärdas. Under NZT-10022 anger Sophos intermittenta förluster av större AD-paket för gateway 2.2 och 2.3, vilket bland annat kan påverka RDP, filresurser och Kerberos.

Efter en uppdatering ska därför även de berörda AD-beroende applikationerna kontrolleras i en begränsad Windows-pilot. Dokumentera agent-/gatewayversion, tidpunkt och reproducerbart fel. Den 24 oktober 2026 hänvisar Known Issues-listan till en ännu kommande Windows Endpoint Agent 2026.3 som korrigering. Meddelandet bevisar inte att rätt ZTNA-korrigering redan har distribuerats i den egna uppdateringskanalen. Kontrollera den konkreta releasen och kopplingen till korrigeringen före en agentutrullning; utlova inte en lösning enbart genom en gatewayuppgradering till 2.3.0. Om felet kvarstår ska underlaget lämnas till Sophos Support och en tillfällig lösning samordnas för det aktuella fallet.

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.

Här anges inget tillförlitligt övergångs-, migrations- eller EOL-datum för gatewayplaneringen. Kontrollera sådana tidsfrister mot ett aktuellt produktmeddelande innan en gateway ersätts.

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.