Konfigurera Sophos DNS Protection med Sophos Firewall

Sophos DNS Protection kontrollerar DNS-frågor via en molntjänst och hanterar policies och rapporter i Sophos Fusion (tidigare Sophos Central). Tjänsten kan blockera skadliga domäner, phishing, Command-and-Control-mål och oönskade kategorier innan en klient upprättar den egentliga anslutningen.

Med Sophos Firewall är den tydligaste standardlösningen oftast att klienterna använder brandväggen som DNS-resolver, brandväggen vidarebefordrar offentliga frågor till DNS Protection och interna domäner skickas via DNS Request Routes till interna DNS-servrar.

DNS Protection ersätter inte Web Protection, Threat Feeds eller NDR och Active Threat Response. Det kompletterar dessa kontroller på DNS-nivå.

Den här guiden är medvetet inriktad på Sophos Firewall: Fusion-värden, DNS-vidarebefordran, Request Routes, DHCP, NAT, godkännande och rollback. Guiden för nätverkskonfiguration beskriver leverantörsoberoende arkitektur och tillstånd; Locations-guiden täcker hela livscykeln.

Beslut och målarkitektur

DNS är en grundläggande funktion. Om resolvern är långsam, instabil eller för restriktiv upplever användarna snabbt problemet som ett allmänt nätverksavbrott. DNS Protection bör därför bara användas när mervärdet från Fusion-policies, kategorier, loggar eller skydd för roamingklienter motiverar den extra driften.

Ur Avanets perspektiv är snabba, redundanta resolvrar tillsammans med väl underhållna Threat Feeds den mest pragmatiska lösningen för många traditionella brandväggsinstallationer. DNS Protection passar särskilt när:

• DNS-frågor ska vara synliga i Sophos Fusion.
• olika platser behöver olika DNS-policies.
• kategorier ska blockeras redan vid namnuppslagningen.
• klienter inte får använda godtyckliga offentliga resolvrar.
• hanterade Windows-endpoints ska skyddas även utanför företagsnätverket.

Den rekommenderade brandväggsvägen ser ut så här:

1. Sophos Fusion känner platsen som en Location.
2. Sophos Fusion tillhandahåller två IP-adresser för DNS Protection.
3. Sophos Firewall använder båda adresserna som DNS Forwarder.
4. DNS Request Routes skickar interna zoner till interna DNS-servrar.
5. DHCP delar ut brandväggen som resolver till klienterna.
6. En valfri NAT-regel tvingar klassisk DNS-trafik till denna väg.
7. Sophos Fusion loggar och utvärderar offentliga DNS-frågor.

Två metoder måste skiljas åt:

• Traditional DNS over IPv4: för brandväggar, routrar och lokala resolvrar. Sophos kopplar frågor till Location utifrån den offentliga käll-IP-adressen eller ett DDNS-FQDN.
• Secure DNS: DNS over HTTPS (DoH) för kompatibla enheter. Sophos Endpoint kan hantera denna väg på Windows-endpoints som stöds; Windows och macOS kan också konfigureras manuellt för Secure DNS.

En anpassad Location kan stödja båda metoderna. För vidarebefordran via brandväggen måste Traditional DNS och den offentliga IP-adressen eller FQDN konfigureras.

Håll isär de fyra DNS-vägarna

Vid felsökning måste man veta var en fråga behandlas:

• DNS Protection-tjänsten: molnresolvern bedömer offentliga frågor enligt Filtering Policy för identifierad Location. Rapporterna finns i Sophos Fusion, inte i brandväggens Log Viewer.
• Brandväggen som resolver: klienten frågar en interface-IP på brandväggen via UDP eller TCP 53. Den lokala DNS-tjänsten väljer mellan en DNS Request Route och forwarders under Network > DNS. Under Administration > Device access måste DNS tillåtas för källzonen. En brandväggsregel kan inte tillåta denna lokala tjänst.
• DNS-transit: om klienten frågar en offentlig resolver-IP direkt vidarebefordrar brandväggen bara trafik. En brandväggsregel gäller, men inte DNS Request Routes. Regelloggen bevisar därför transport, inte behandling i DNS Protection.
• Endpoint DNS Protection: Sophos Endpoint fångar upp stödda Windows-frågor och skickar dem via HTTPS till Secure DNS Location. En NAT-regel för port 53 och brandväggens Request Routes ingår inte i denna väg. Endast undantagna domäner, eller valfri NXDOMAIN-retry, använder lokal DNS-upplösning.

I rekommenderad design använder klienterna brandväggens resolver. Direkt transit till DNS Protection-IP-adresser är inte likvärdig när interna zoner kräver Request Routes.

Före rollout måste licens, offentliga utgående adresser, interna DNS-zoner, DHCP-servrar och ansvariga för policies och undantag vara klarlagda. Xstream Protection täcker fristående DNS Protection för brandväggen. Workspace Protection täcker DNS Protection för endpoints; Sophos Endpoint måste vara installerat. Båda licenserna inkluderar DoH.

För att DNS Protection ska visas som en produkt i Sophos Fusion måste den Xstream-licensierade brandväggen vara kopplad till samma Fusion-konto. Kontrollera licensen under Administration > Licensing på brandväggen eller på sidan Firewall Licensing i Sophos Fusion. Sophos beskriver tre metoder: registrering under installationen, claim av serienumret under Firewall Licensing eller aktivering av Sophos Fusion-hantering i WebAdmin.

Licensbeslut och Fusion-behörigheter hör till de befintliga processerna för Sophos Fusion-licensiering och administrativa roller. Brandväggsansvarig behöver åtkomst till DNS Protection och godkända tenantvärden, men ska inte utöka roller som en del av ändringen.

Den fördefinierade Location Default kan användas för Secure DNS och tilldelas policies, men kan inte redigeras eller tas bort. Högst 50 Locations och 100 offentliga IPv4-/FQDN-poster per Location är tillåtna. Locations bör därför skapas per plats och internetutgång, inte per VLAN.

Konfigurera DNS Protection

1. Skapa en Location i Sophos Fusion

My Products > DNS Protection > Locations

1. Välj Add och ange ett unikt namn i Name; använd gärna Description för internetutgång och ansvarig.
2. Aktivera Traditional DNS over IPv4 under Connection method.
3. Ange offentlig WAN-IP eller stabilt DDNS-FQDN under IPv4 addresses or FQDNs. Bekräfta varje värde med Enter eller Tab.
4. Ta med alla använda utgångsadresser vid Multi-WAN. Automatiskt identifierade adresser uppdateras inte automatiskt efter en ändring.
5. Välj Save.

Privata IP-adresser är ogiltiga. Sophos måste känna igen den offentliga käll-IP-adress via vilken frågan når tjänsten. För dynamiska adresser kontrollerar Sophos DDNS-namnet regelbundet, men ett byte kan ändå orsaka ett kort avbrott. I Cloudflare måste DDNS-posten vara inställd på DNS only och får inte gå via proxyn.

Vid CGNAT eller en delad leverantörs-IP kopplas adressen till det kundkonto som registrerar den först. Ett FQDN löser inte problemet om det pekar på samma delade IP; en unik offentlig IP-adress krävs.

2. Hämta IP-adresserna för DNS Protection

My Products > DNS Protection > Installers

Under Installers, bredvid IP addresses, finns två IP-adresser för DNS Protection. Använd Copy för att kopiera båda värdena från den egna Fusion-klientorganisationen och använd dem sedan som DNS 1 och DNS 2. En extern resolver som extra fallback kan kringgå skyddet och synligheten.

IP-adresserna är tillgängliga även när Secure DNS är aktiverat. För brandväggsvägen är det avgörande att Traditional DNS också är konfigurerat i Location med den offentliga utgående adressen.

På samma sida kan du använda Copy bredvid URL för att kopiera testadressen. Om DNS Protections välkomstmeddelande visas när adressen öppnas i webbläsaren är resolvervägen korrekt konfigurerad. För senare felsökning är https://dns.access.sophos.com särskilt relevant: om bara detta namn inte kan slås upp eller om webbläsaren visar ett fel i stället för välkomstmeddelandet tyder det på en DNS-läcka eller omdirigering från leverantören.

3. Konfigurera brandväggen som DNS Forwarder

Network > DNS

1. Välj Static DNS.
2. Fyll i DNS 1 och DNS 2 med de två Fusion-adresserna.
3. Lämna DNS 3 tomt om det inte finns ett medvetet dokumenterat specialfall.
4. Välj även Static DNS under IPv6 och ange inga IPv6-DNS-servrar.
5. Aktivera Choose IPv4 DNS server over IPv6.
6. Välj Apply.

Tjänsten använder IPv4 men kan även slå upp AAAA-poster och därmed IPv6-mål. Vid SD-WAN, failover eller Policy Routing måste den faktiska utgående vägen motsvara en offentlig adress som har registrerats i Location.

Från SFOS 21.5 visar DNS Protection status widget i Control center anslutningsstatus. Sophos Assistant finns också för guidad konfiguration och felsökning. Widgeten är en snabb driftindikator; för godkännande av hela vägen ger en lyckad öppning av testadressen och DNS Protection-rapporterna starkare bevis.

4. Vidarebefordra interna domäner

Network > DNS
DNS request route > Add

DNS Protection slår inte upp interna zoner. Därför krävs DNS Request Routes för Active Directory, interna applikationer och omvända uppslagningar.

Exempel:

• Host/domain name: firma.local eller corp.example.com
• Target servers: interna domänkontrollanter eller DNS-servrar, i önskad ordning; varje route stöder högst åtta IP-adresser

corp.example.com är en dokumentationsdomän och ska ersättas med den zon som faktiskt är auktoritativ internt. Dirigera inte hela example.com om bara en underzon är intern. Om cacheuppslagningen för en matchande route misslyckas frågar brandväggen inte även offentliga forwarders eller rootservrar. Target Servers ordning och nåbarhet ingår därför i tillgänglighetsdesignen.

Hela förloppet beskrivs i Konfigurera DNS Request Routes på Sophos Firewall. Internt använda, offentligt registrerade domäner bör dessutom tillåtas i en domänlista om en kategori som Parked Domains blockerar dem.

5. Låt klienter använda brandväggen via DHCP

Network > DHCP

1. Redigera DHCP-servern under Server och anteckna adressen för vald Interface.
2. Avmarkera Use device’s DNS settings under DNS server.
3. Ange brandväggens interna DHCP-interfaceadress som Primary DNS.
4. Spara, förnya testklientens lease och kontrollera faktisk resolver.

Sophos visar som exempel brandväggens IP som Primary DNS och en DNS Protection-IP som Secondary DNS. Klienter behandlar dock inte nödvändigtvis den andra posten som en ren reservserver. Direkta frågor till DNS Protection kringgår brandväggens DNS Request Routes. I nätverk med Active Directory eller interna zoner bör redundans därför lösas i resolvervägen, inte med en godtycklig andra DNS-server på klienten.

6. Förhindra direkt kringgående av DNS

Kontrollera först under Administration > Device access att DNS är aktiverat för varje berörd källzon. Därefter kan en valfri DNAT-regel omdirigera klassisk DNS-trafik till brandväggen:

Rules and policies > NAT rules > IPv4 > Add NAT rule > New NAT rule

• Rule name: exempelvis redirect-client-dns-to-firewall
• Rule position: Top
• Original source: berörda interna nätverk
• Original destination: utgående värdgrupp eller Internet IPv4
• Original service: DNS
• Translated destination: brandväggens interna IP
• Translated source / Translated service: Original
• Inbound interfaces: endast gränssnitt som motsvarar de interna källorna, aldrig WAN

Internet IPv4 har ett brett omfång och passar endast när alla klassiska externa DNS-mål verkligen ska omdirigeras. Begränsa källnäten och Inbound Interfaces så mycket som möjligt. Interna DNS-servrar och specialenheter behöver dokumenterade undantag före denna regel. Regeln omfattar endast DNS via UDP/TCP 53. DoH och DoT kräver separata kontroller i webbläsare, MDM, endpoint eller Web Policy. Testa intern namnuppslagning, VPN och gästnät före aktivering. Regelmekaniken förklaras mer ingående i Förstå NAT på Sophos Firewall.

Policies, endpoints och blockeringssidor

Filtering Policy och domänlistor

En Filtering Policy tilldelas en eller flera Locations under DNS Protection > Policies > Filtering policies. Endast en Filtering Policy kan vara aktiv per Location. Utöver kategorier kan domänlistor och alternativ som Safe Search definieras.

Den här artikeln verifierar endast att brandväggsvägen når rätt Location och därmed förväntad policy. Skapande, undantag, Safe Search, pilot och rollback beskrivs i Konfigurera Filtering Policies för Sophos DNS Protection.

Domänlistor bör ha syfte, Owner och granskningsdatum. En Allow list åsidosätter normala kategoribeslut, men inte en SophosLabs-klassificering som Threat eller Security Risk. En tillåten domän kan dessutom förbli blockerad om dess CNAME-mål tillhör en blockerad kategori.

Följande beslut är särskilt viktiga för kategorierna:

• Infrastructure: tillåt normalt Content delivery, CRL och OCSP, eftersom uppdateringar och certifikatkontroller kan vara beroende av dem.
• Threats and liabilities: blockera vanligtvis kategorier som Phishing, Malware, Newly Registered Websites eller Anonymizers och hantera False Positives målinriktat.
• Data loss: bedöm molnlagring och webbmejl utifrån DLP- och efterlevnadskrav.
• Uncategorized: blockera inte blint; nya legitima eller interna tjänster kan tillfälligt sakna kategori.
• Produktivitet, Social Media och bandbredd: besluta utifrån nätverk och verksamhetsbehov, inte som en generell säkerhetsregel.

Endpoint DNS Protection

Endpoint DNS Protection Policy är avsedd för hanterade Windows-endpoints som ska skyddas även utanför företagsnätverket. Sophos Endpoint fångar DNS-frågorna och skickar dem via HTTPS till Secure-DNS-Location. Tillhörande Filtering Policy bestämmer den faktiska filtreringen.

Guiden för Endpoint DNS Protection hanterar konfiguration, interna Domain Exclusions och tilldelning. Brandväggens NAT, Request Routes och DHCP ersätter inte denna endpointväg.

Policyn stöder för närvarande varken Windows Server eller macOS. För macOS finns en separat manuell Secure DNS-profil; Linux, mobila enheter och specialenheter behöver också en egen nätverks-, VPN- eller MDM-lösning. Kontrollera aktuella krav för Endpoint-paketet i Sophos Fusion före rollout, eftersom de kan ändras med kort varsel.

Interna zoner hanteras uttryckligen som Domain Exclusions i Endpoint Policy. Det är mer tillförlitligt än ett nytt försök efter NXDOMAIN och undviker onödiga externa frågor. DNS Protection Root Certificate kan distribueras automatiskt till endpoints som stöds.

Root Certificate och blockeringssida

För HTTPS-blockeringssidor måste klienterna lita på DNS Protection Root Certificate. Det är inte samma certifikat som brandväggens CA för TLS Inspection; distributionen beskrivs i Distribuera Sophos Firewall CA-certifikat för TLS Inspection.

För kontroll, distribution, rotation och borttagning, följ Distribuera Sophos DNS Protection-rotcertifikatet.

Certifikatet och konfigurationstestet finns under DNS Protection > Installers. Dessutom måste blockpage.dnsprotection.sophos.com kunna nås.

I Web Proxy Mode kan Pharming Protection störa blockeringssidan. Innan skyddsfunktioner inaktiveras globalt bör blockeringssidans domän tillåtas via en riktad HTTP/HTTPS-brandväggsregel utan Web Filter och anges som Do not decrypt i en TLS-regel.

Pilot, rollout och godkännande

Aktivera först DNS Protection i ett litet pilotnät. Dokumentera interna zoner, omvända uppslagningar och kritiska tjänster, konfigurera DNS Request Routes och förbered en tydlig rollback till tidigare resolvrar. Servernät behöver ett separat testfönster eftersom licenskontroll, uppdateringar, CRL/OCSP, backup eller klusterkommunikation kan vara DNS-beroende.

Före bred rollout måste följande kontroller lyckas. Klientkommandona har inte körts här i en SFOS 22-testmiljö; de är skrivskyddade diagnoskommandon. Fusions konfigurationstest och rapporter ger produktbeviset:

• en offentlig domän slås upp via avsedd resolver.
• den interna AD-domänen och omvänd uppslagning fungerar via DNS Request Routes.
• konfigurationstestet under Installers visar förväntad bekräftelse.
• en ofarlig domän som avsiktligt blockeras av en testpolicy blockeras och kopplas till rätt Location.
• under DNS Protection > Logs & Reports visar DNS usage by source Location efter fördröjningen och, för endpointdata, även användare och enhet.
• gästnätet använder planerad DNS-väg men inga interna DNS-servrar.
• VPN-klienten får lämpliga resolvrar och DNS-suffix.
• Browser DoH, Private Relay eller lokala profiler kringgår inte kontrollen oväntat.
• rollback till tidigare resolver är testad eller tydligt dokumenterad.

Testkommandon för klienter

Windows:

ipconfig /all
nslookup example.com
nslookup example.com <firewall-ip>
Resolve-DnsName example.com

macOS:

scutil --dns
dig example.com
dig @<firewall-ip> example.com

Linux med systemd-resolved och installerat dig:

resolvectl status
dig example.com
dig @<firewall-ip> example.com

Ersätt <firewall-ip> med Sophos Firewalls interna gränssnittsadress. Om den uttryckliga frågan till brandväggen fungerar men den normala frågan inte gör det, ligger orsaken oftast i DHCP, VPN, Browser DoH eller en lokal DNS-konfiguration. Kommandona visar vilken klientresolver som används och dess svar, men bevisar inte i sig vilken upstream brandväggen använder.

Testa en intern zon:

dig @<firewall-ip> interner-host.corp.example.com

Frågan måste nå den interna DNS-servern via rätt DNS Request Route.

Troubleshooting

Location visas inte i Sophos Fusion

Kontrollera offentlig WAN-IP, DDNS-FQDN och faktisk Multi-WAN-utgång. En käll-IP som inte är konfigurerad kan avvisas av DNS Protection-tjänsten. För dynamiska adresser ska du kontrollera att FQDN externt pekar på aktuell IP; Cloudflare-poster måste vara inställda på DNS only.

Under My Environment > Alerts visas ogiltiga FQDN och IP-konflikter. Vid CGNAT eller delade proxy-/VPN-utgångar vinner den Location som registrerades först. Ett annat FQDN på samma IP ändrar inte kopplingen.

DNS-trafik saknas trots korrekt Location

Detta fel omfattar även No queries received from locations i dashboarden och DNS Protection: Connectivity Error i Control center. Öppna först https://dns.access.sophos.com. Om välkomstmeddelandet inte visas testar du båda tenantadresserna under Installers via UDP och TCP 53 och kontrollerar faktisk WAN-utgång.

Om frågor når ett annat mål eller en annan resolver svarar kan routern eller internetleverantören omdirigera DNS. Ett Standard- eller Extended-test på https://www.dnsleaktest.com/ hjälper till att avgränsa problemet: med DNS Protection innehåller värdena i kolumnen Hostname mönstret gw-<Nummer><Region>.dnsprotection.sophos.com; som ISP visas Amazon eller ett motsvarande namn. Om testet endast visar andra resolvrar bör leverantören kontrollera DNS-omdirigering. Om Sophos-resolvrar och externa resolvrar visas blandat ska du kontrollera DNS-inställningarna för brandväggen, den interna DNS-servern och klienterna samt parallella IPv6-resolvrar. https://ipleak.net/ kan användas som motkontroll.

Behåll endast de två tenantadresserna som forwarders, kontrollera routing, NAT och Packet Capture och lös leverantörens omdirigering med ISP:n. En tredje offentlig resolver är bara ett oskyddat kringgående.

Enskilda klienter använder en annan resolver

Kontrollera DHCPv4, DHCPv6, Router Advertisements, VPN-profil och statiska klientvärden tillsammans. En extra IPv6-DNS-server kan leda frågor förbi DNS Protection. DNS Protection använder IPv4 men slår upp AAAA-poster, så IPv6-mål kräver ingen separat IPv6-resolver.

Interna namn fungerar inte längre

Kontrollera DNS Request Routes, interna DNS-servrar, omvända zoner, sökdomäner och klientsuffix. Kontrollera också att klienten använder brandväggen eller avsedd intern resolver och inte direkt en DNS Protection-IP.

En intern eller legitim domän blockeras

Kontrollera kategorisering, domänlista och CNAME-mål. Ett snävt undantag är bättre än att öppna en hel kategori. SophosLabs-klassificeringarna Threat och Security Risk kan inte åsidosättas med en Allow domain list.

Loggarna förblir tomma

Dashboard och rapporter ligger ungefär 15 till 25 minuter efter. Ändrade Location- eller policynamn kan ta 30 minuter till fyra timmar. Kontrollera först därefter DHCP, klient-DNS, brandväggs-DNS, NAT-omdirigering, alternativa resolvrar, VPN-profiler och Location-tilldelning.

Börja under DNS Protection > Logs & Reports med DNS usage by source och filtrera på Location, Domain, Status eller Source IP. För direkt vidarebefordrad DNS kan en regel med Log firewall traffic visa om UDP/TCP 53 passerade brandväggen. För brandväggens resolver är Administration > Device access avgörande; en brandväggsregel bevisar inte att den lokala tjänsten tilläts eller nekades.

Filteroperatorer, exportgränser, fördröjningar och Live Discover dokumenteras i Analysera DNS Protection-rapporter och Live Discover. Vid felsökning av brandväggen ska resolvervägen bevisas först; djupare rapportfrågor kommer därefter.

Med EDR, XDR eller MDR kan Threat Analysis Center > Live Discover dessutom analysera DNS Protection-data som Domain, Policy Action, Location och Source IP. Användar- och enhetsfält finns för endpointdata i standardrapporterna, inte i Live Discovers dokumenterade DNS-schema för brandväggen.

Blockeringssidan visas inte

Kontrollera DNS Protection Root Certificate, DNS-vägen och åtkomsten till blockpage.dnsprotection.sophos.com. Kontrollera även Pharming Protection, HTTP/HTTPS-regeln och TLS-undantaget Do not decrypt i Web Proxy Mode. VPN, Browser DoH och Apple Private Relay kan också leda testet förbi DNS Protection.

Skapa ett FQDN-objekt för blockpage.dnsprotection.sophos.com för det snäva brandväggsundantaget. En Allow-regel tillåter HTTP/HTTPS från berörda interna zoner och nätverk till WAN-zonen, med objektet som mål och utan Web Filter. En motsvarande TLS-regel använder samma urvalskriterier med Do not decrypt. Inaktivera inte Pharming Protection eller TLS Inspection globalt.

DoH eller Private DNS kringgår kontrollen

En NAT-omdirigering för port 53 omfattar inte DoH eller DoT. Policies för webbläsare, operativsystem och MDM måste kontrollera sådana resolvrar. Secure DNS i DNS Protection använder DoH; ett separat DNS Protection-läge via DoT är inte dokumenterat.

På Apple-enheter kan även iCloud Private Relay kringgå den avsedda DNS-vägen. Om exempelvis iPhones saknar internetåtkomst medan andra enheter på samma plats fungerar ska du först inaktivera Limit IP Address Tracking för den berörda testvägen och testa igen. Gör en ändring för hela organisationen först efter detta begränsade test och efter samordning av integritetskraven.

VPN-klienter beter sig annorlunda än LAN-klienter

Kontrollera tilldelade DNS-servrar, DNS-suffix, Split DNS, Full eller Split Tunnel och lokala resolvrar. DNS Protection kan fungera på kontoret men ändå kringgås vid fjärråtkomst. Det grundläggande VPN-valet förklaras i Sophos Connect eller SSL VPN: vilken fjärråtkomstlösning passar?.

Drift

DNS Protection är inte ett engångsbyte av DNS-server. Kontrollera regelbundet:

• Locations, offentliga utgående adresser och DDNS-upplösning.
• DHCP-inställningar och interna DNS Request Routes.
• policies, domänlistor, Owner och granskningsdatum.
• vanligaste blockerade domäner och dokumenterade False Positives.
• nya platser, gästnät, VPN-vägar och endpointplattformar.
• certifikatdistribution och åtkomst till blockeringssidans domän.
• rapporter efter ändringar och definierad rollbackväg.

Den som inte vill hantera dessa punkter löpande får ofta bättre resultat med robusta resolvrar och riktade skyddskontroller. DNS Protection är värdefullt där policies, rapportering och endpointskydd faktiskt används och övervakas.

Säker återställning

Stäng först av DNS-omdirigeringen för platsvägen så att klienterna inte fortsätter att tvingas till brandväggen under återställningen. Återställ sedan tidigare resolvrar under Network > DHCP, förnya testklientens lease och kontrollera offentliga och interna namn. Återställ tidigare läge eller servrar under Network > DNS först när denna väg fungerar. Låt Request Routes vara kvar inledningsvis; de hindrar inte återställningen och underlättar en kontrollerad återstart. Ta bort Fusion Location först när inga nödvändiga nät eller policies längre är tilldelade.

Återställ Endpoint DNS Protection separat: ta bort den berörda tilldelningen under DNS Protection > Policies > Endpoint policies eller stäng av Use Sophos DNS Protection. Kontrollera sedan på pilotenheten att de resolvrar som konfigurerats av systemet eller applikationen används igen. Root Certificate behöver inte tas bort i samma underhållsfönster; ta bort det senare via samma hanterade distributionskanal som användes vid installationen.