Planera och skapa Sophos ZTNA Gateway
En Sophos ZTNA Gateway ansluter användare till interna applikationer utan behov av klassisk full-tunnel VPN-åtkomst. Den faktiska fördelen uppstår dock först när gatewayläget, DNS, certifikat, brandväggsregler och intern tillgänglighet är ordentligt planerade.
Den här guiden beskriver hur man planerar och skapar en ZTNA-gateway i Sophos Central. Fokus ligger på gateway-delen. För det grundläggande beslutet mellan VPN, ZTNA och andra fjärråtkomstvarianter passar även Sophos Connect eller SSL VPN: Vilket råd finns det?.
För den leverantörsneutrala grunden om Zero Trust, ZTNA och skillnaden mot VPN, börja med Zero Trust enkelt förklarat: ZTNA i stället för klassisk VPN.
Förstå gateway-lägena
Sophos ZTNA kan drivas med en On-premise Gateway eller en Sophos Cloud Gateway. Båda varianterna ger tillgång till interna resurser, men skiljer sig markant i internetexponering, DNS, drift och felsökning.
- On-premise Gateway: Gateway VM finns i ditt eget datacenter eller webbplatsnätverk egen VM, egen offentlig DNS, DNAT på port 443, mer direkt kontroll.
- Sophos Cloud Gateway: Användare ansluter via Sophos Cloud Points of Presence. mindre direkt internetexponering, olika DNS-CNAME, val av närvaro.
- Sophos Firewall som en molngateway: Sophos Firewall tar på sig gatewayrollen för ZTNA Cloud Gateway. ingen separat gateway-VM, men beroende av SFOS, central och brandväggsdrift.
Läget är inte bara en teknisk kryssruta. Den bestämmer var trafik kommer in, vem som driver datavägen, vilka DNS-poster som är nödvändiga och om en DNAT-regel behövs på brandväggen.
On-premise gateway
Med en lokal gateway distribueras en gateway-VM på VMware ESXi eller Microsoft Hyper-V. Gatewayen kan nås från Internet och accepterar ZTNA-åtkomst. I praktiken pekar ett offentligt DNS-namn på brandväggen och en DNAT-regel vidarebefordrar HTTPS till gatewayen.
Fördelar:
- direkt dataväg till din egen plats,
- Full kontroll över gateway, segment, DNS och brandväggsregler,
- inget beroende av Sophos Cloud Data Plane för den faktiska ingångspunkten.
Nackdelar:
- Gateway VM måste drivas och uppdateras,
- Port 443 måste vara tillgänglig utifrån,
- Certifikat, DNS, DNAT och intern routing måste vara korrekt, – Tillgänglighet beror på din plats, internetuppkoppling och hypervisor.
Vid publicering av en lokal gateway via DNAT bör regeln planeras lika noggrant som andra publikationer. Grunderna finns i Publicera servrar med DNAT till Sophos Firewall.
Sophos Cloud Gateway
Med Sophos Cloud Gateway hanteras åtkomst via Sophos Cloud Points of Presence. Den interna gateway-komponenten kopplar Sophos Cloud till de interna resurserna. Detta eliminerar behovet för användare att komma åt sin egen offentliga gateway-IP direkt.
Detta minskar direkt internetexponering men flyttar delar av datavägen till Sophos-molnet. Följande är därför viktiga:
- lämplig närvaroplats nära datacentret,
- korrigera offentliga CNAME-poster,
- fungerande intern DNS-upplösning,
- tydliga förväntningar på latens, tillgänglighet och trafikprofiler,
- Kontrollera licens-, produkt- och trafikgränser för den specifika miljön.
För mycket dataintensiva applikationer som stor fillagring, CAD-filer eller massnedladdningar bör du inte bara testa ZTNA Cloud Gateway baserat på registrering. Det som spelar roll är hur verklig användning, latens och datavolym beter sig i vardagen.
Sophos Firewall som ZTNA Cloud Gateway
En Sophos Cloud Gateway kan också ställas in på centralt hanterade Sophos-brandväggsenheter. Detta är intressant om det redan finns en Sophos-brandvägg på platsen och ingen separat gateway-VM ska användas.
Denna variant bör dock inte aktiveras som en sekundär funktion. Följande bör kontrolleras:
- Stöd SFOS-version och central hanteringsstatus.
- ZTNA-licensiering och användarkartläggning.
- Tillgänglighet för interna resurser ur brandväggsperspektiv.
- Inverkan på underhållsfönster, firmwareuppdateringar och brandväggsdrift.
- Loggning och ansvar för störningar. Om brandväggen ändå är den centrala fjärråtkomstnoden kan denna variant vara elegant. Å andra sidan, om du vill att ZTNA ska köras oberoende av brandväggsunderhåll, är en dedikerad gateway-VM eller annan design ibland renare.
Krav
Innan implementeringen bör dessa punkter förtydligas:
- Sophos Central Tenant med ZTNA-licens.
- Synkroniserade användare och grupper.
- Identitetsleverantör, till exempel Microsoft Entra ID.
- Bestäm dig för lokal gateway eller Sophos Cloud Gateway.
- Hypervisor eller Sophos Firewall som stöds, beroende på läge.
- Offentlig DNS för gateway och resurser.
- Wildcard-certifikat eller lämpligt certifikatkoncept.
- Intern DNS-upplösning av målapplikationer.
- Nätverkssegment för gatewayen.
- Brandväggsregler från gatewayen till applikationerna.
- Ägare för drift, loggar, certifikat och efterföljande ändringar.
För certifikat är ett wildcard-certifikat ofta det mest praktiska alternativet. Att erhålla ett jokerteckencertifikat beskrivs i Låt oss kryptera skapa jokerteckencertifikat. Om certifikat hanteras direkt på Sophos-brandväggen passar Hantera Let’s Encrypt-certifikat för Sophos-brandvägg också.
Plattform och dimensionering
För virtuella gateway-maskiner är VMware ESXi och Microsoft Hyper-V de typiska plattformarna. Beroende på läge och Sophos-status kan andra alternativ vara relevanta. Det är avgörande att plattformen är officiellt stödd, uppdaterad och korrekt övervakad.
För små till medelstora installationer är en gateway-VM med 2 vCPU och 4 GB RAM en realistisk utgångspunkt. Men detta ersätter inte verksamhetsplaneringen. De avgörande faktorerna är antalet användare, resurser, trafikprofil, TLS, latens och tillgänglighet.
För produktiva miljöer bör du också planera:
- Finns det ett gateway-kluster?
- Körs gatewayen i sitt eget VLAN?
- Hur säkerhetskopieras eller återställs den virtuella datorn?
- Finns det hypervisorövervakning?
- Vem uppdaterar gatewayen?
- Finns det ett underhållsfönster för omstarter?
Nätverk och subnät
ZTNA Gateway bör användas i sitt eget subnät eller VLAN. Den ska inte bara placeras på ett klient- eller servernätverk. Ett separat segment gör brandväggsregler, loggning, paketfångning och senare felsökning enklare.
Dessa nätverk bör inte användas för gatewayen:
10.42.0.0/1610.43.0.0/1610.108.0.0/16
För en lokal gateway pekar ett offentligt DNS-namn, till exempel ztna.example.com, på brandväggens publika IP. Brandväggen vidarebefordrar port 443 till gatewayen via DNAT. Gatewayen kräver då åtkomst till Internet och åtkomst till VLAN eller servernätverk där de publicerade applikationerna finns.
DNS-posterna är annorlunda för en Sophos Cloud Gateway. Där blir CNAME:er relevanta för domänvalidering, gatewayalias och, beroende på åtkomsttyp, resursalias. De offentliga DNS-posterna bör därför kontrolleras som ett separat steg före lanseringen.
Bestäm innan implementering
Innan du klickar på Add gateway bör dessa frågor besvaras:
- Vilka ansökningar publiceras?: Webbapp, TCP-app och fillagring har olika krav.
- Agentlös eller agentbaserad åtkomst?: DNS, CNAME och användarupplevelse skiljer sig åt.
- On-premise eller molngateway?: Beslutar om DNAT, dataväg och operativt ansvar.
- Vilka användargrupper får åtkomst?: ZTNA trivs med nära association, inte på breda grupper.
- Hur löses DNS internt och externt?: Felaktiga DNS-destinationer är en av de vanligaste felkällorna.
- Vilket certifikat används?: Certifikatfel fungerar som ett ZTNA-fel för användare.
- Vem granskar loggar och ändringar?: Utan en ägare blir ZTNA snabbt svår att stödja.
Ladda ner ZTNA Gateway
I Sophos Central kan filerna för den virtuella maskinen laddas ner under Skydda enheter i huvudmenyn.
Distribuera VM på Hyper-V eller ESXi
För en lokal gateway eller gateway-VM skapas den virtuella maskinen först.
Typiska inställningar:
- Generation 1 för Hyper-V.
- 2 virtuella processorer som startvärde.
- 4 GB RAM som startvärde.
- Nätverk i eget VLAN eller gateway-segment.
- Hyper-V: använd nedladdade
.vhdx-filer. - ESXi: Använd OVA-fil.
Den virtuella datorn ska inte startas förrän ISO-bilden har skapats med gatewayinställningarna. Denna ISO ansluter senare den virtuella datorn till Sophos Central Tenant och gatewayinställningarna.
Gateway-inställningar i Sophos Central
Gatewayen läggs sedan till och konfigureras i Sophos Central.
Viktiga fält:
- Mode: Välj lokal gateway eller Sophos molngateway medvetet.
- Namn: Använd plats, syfte eller värdnamn.
- Plats: Valfritt, men användbart med flera gateways.
- FQDN: För den lokala gatewayen, det offentliga DNS-namnet som pekar på brandväggen eller gatewayens IP.
- Domän: Domän som matchar certifikatet och resurserna.
- Plattformstyp: VMware ESXi, Hyper-V, AWS eller stödd Sophos brandväggsvariant beroende på läge.
- Identitetsleverantör: Välj tidigare inställd identitetsleverantör.
- Gateway Instance Deployment mode: Enarm för enkla DNAT-scenarier, tvåarm för separat WAN/LAN-design.
- IP-adress: Föredrar statisk eller reserverad IP-adress för produktiva gateways.
- Certifikat: Använd jokertecken eller lämpligt gatewaycertifikat.
Enarm är ofta enklare eftersom ett gränssnitt används för inkommande och utgående trafik. Tvåarmar separerar WAN- och LAN-sidorna, men kräver två gränssnitt och en tydligare nätverksdesign.
Efter att ha sparat skapar Sophos Central en ISO-bild med gatewayinformationen. Denna ISO tilldelas den virtuella datorn som start-ISO.
Beroende på värdprestanda och miljö kan den första uppstarten och registreringen hos Sophos Central ta lite tid. Så snart gatewayen svarar kan den accepteras i Central.
Kontrollera efter start
Efter registrering är gatewayen inte automatiskt redo för produktion. Endast dessa tester visar om designen fungerar:
- Gateway-status: Gateway är online i Sophos Central och visar en rimlig version.
- Offentlig DNS: Gateway FQDN eller CNAME pekar på den förväntade destinationen.
- Certifikat: Webbläsaren och ZTNA-klienten litar på certifikatet.
- Intern DNS-upplösning: Gateway kan korrekt lösa interna resurser.
- Brandväggsregler: Gateway når bara de applikationer och portar den behöver.
- DNAT på plats: Port 443 träffar den förväntade NAT- och brandväggsregeln.
- Testanvändare: En pilotgrupp kan uppnå exakt de planerade resurserna.
- Loggar: Gateway-, central- och brandväggsloggar visar spårbara händelser.
Om ZTNA introduceras som ett alternativ till VPN bör en pilot inte testas med bara en exempelwebbplats. Verkliga målapplikationer är bättre: intern webbportal, RDP/SSH-hopp, specialistapplikation eller filåtkomst, beroende på den planerade användningen.
Typiska fel
- Offentlig DNS visar falskt: Användare kan inte nå gatewayen. A/CNAME, TTL, kontrollera extern upplösning.
- Intern DNS-upplösning saknas: Inloggning fungerar, resurs öppnas inte. Kontrollera Privat DNS, Resource FQDN eller Destination IP.
- Certifikatet passar inte: Webbläsare eller klientvarning. Kontrollera jokertecken, SAN, kedja och domän.
- DNAT saknas från den lokala gatewayen: Gateway förblir otillgänglig utifrån. Kontrollera NAT-regel, port 443, WAN IP och loggvisare.
- Gateway får inte nå applikationen: Resursen förblir offline eller timeout. Kontrollera brandväggsregler från gatewaysegment till destination.
- Ändringar av DHCP-adress: ZTNA misslyckas efter omstart. Använd reserverad eller statisk IP-adress.
- Användargruppen för bred: För många resurser synliga. Fördela grupper, policyer och resurser närmare.
- Cloud Gateway med felaktig PoP: märkbar latens. Välj en närvaropunkt nära datacentret.
För regel- och NAT-analys på Sophos Firewall Testa brandväggsregler med Log Viewer, Policy Test och Packet Capture och Forstå NAT på Sophos Firewall hjälp.
Operationell checklista
- Gateway-läge dokumenterat.
- Testade offentliga DNS och privata DNS.
- Certifikat giltigt och förnybart.
- Gateway verkade i sitt eget segment.
- DNAT är endast inställt för den lokala gatewayen.
- Gateway-regler för interna resurser är strikt begränsade.
- Pilotanvändare och pilotresurser definierade.
- Loggar, ägare och supportprocess förtydligas.
- Gatewayuppdateringar och underhållsfönster planerade.
- Demonteringsplan på plats om Pilot inte fungerar.