Planowanie i konfiguracja sieci dla Sophos DNS Protection

Sophos DNS Protection może chronić centralny resolver DNS w lokalizacji albo łączyć zgodne urządzenia bezpośrednio przez Secure DNS. Najważniejsza decyzja nie dotyczy więc producenta zapory, lecz miejsca rozwiązywania nazw DNS, sposobu zachowania stref wewnętrznych oraz sposobu rozpoznawania lokalizacji przez Sophos.

Szybka ścieżka: w zarządzanej sieci lokalizacji klienci powinni zazwyczaj nadal korzystać z istniejącego lokalnego resolvera jako serwera DNS. Przekazuje on wyłącznie zapytania publiczne do dwóch adresów IP DNS Protection widocznych w Sophos Fusion (dawniej Sophos Central). Strefy wewnętrzne nadal trafiają do autorytatywnych wewnętrznych serwerów DNS. Secure DNS jest odpowiedni dla zarządzanych urządzeń indywidualnych i użytkowników mobilnych. Obie ścieżki należy najpierw przetestować na małej grupie pilotażowej i nigdy nie dodawać niezabezpieczonego publicznego resolvera jako trzeciej opcji awaryjnej.

Architektura docelowa i zakres odpowiedzialności

Ścieżka sieciowa obejmuje cztery osobne role:

Klient wysyła zapytanie do resolvera wskazanego przez DHCP, VPN, MDM lub konfigurację lokalną.
Lokalny resolver wybiera między strefami wewnętrznymi a nazwami publicznymi.
Zapora, router i NAT określają publiczny źródłowy adres IP oraz faktyczne wyjście ruchu.
DNS Protection przypisuje zapytanie do Location, stosuje jej Policy i zwraca odpowiedź.

W przypadku Secure DNS urządzenie wysyła zapytanie do DNS Protection przez DNS over HTTPS (DoH). Ta ścieżka omija lokalny forwarder DNS. Przekierowanie portu 53, lokalna pamięć podręczna i Conditional Forwarding nie mają na nią wpływu.

W tym artykule opisano architekturę niezależną od producenta i wymagania wobec zapór innych firm. Konfigurację właściwą dla urządzenia opisuje artykuł Konfiguracja Sophos DNS Protection z Sophos Firewall.

Wymagania wstępne, licencja i role

Przed zmianą sieci musi istnieć planowana Location oraz konto z odpowiednimi uprawnieniami dostępu do Sophos Fusion. Najpierw należy sprawdzić uprawnienia licencyjne: samodzielne DNS Protection jest dostępne z Xstream Protection, natomiast Endpoint DNS Protection wymaga Workspace Protection i Secure DNS. Te dwa modele wdrożenia korzystają z różnych ścieżek danych i nie wolno traktować ich zamiennie.

Location należy utworzyć przed wdrożeniem urządzeń. Następnie osoba odpowiedzialna za daną platformę dystrybuuje wartości tenantu zgodnie z odpowiednią instrukcją urządzenia i konfiguruje zależnie od potrzeb system Windows, macOS lub Windows Server. Zarządzane urządzenia z systemem Windows należy przekazać osobie odpowiedzialnej za Endpoint DNS Protection Policy, zamiast utrzymywać profile ręczne. Instalowanie, odnawianie i usuwanie zaufania należy do osobnego procesu dotyczącego DNS Protection Root Certificate, a nie do tej procedury konfiguracji.

Wybór Traditional DNS lub Secure DNS

Local resolver lub Firewall forwarder

Tę ścieżkę należy wybrać, gdy lokalizacja korzysta już z routera, zapory, Windows DNS lub innego Local resolver. Lokalny resolver lub Firewall forwarder wysyła publiczne zapytania do Sophos przy użyciu Traditional DNS over IPv4. DNS Protection rozpoznaje Location na podstawie publicznego źródłowego adresu IPv4 albo nazwy FQDN zapisanej dla tej Location.

Zaletami są centralne pamięci podręczne, wspólna ścieżka dla wielu typów urządzeń i Conditional Forwarding dla stref wewnętrznych. Ograniczeniem jest identyfikacja: za jednym publicznym źródłowym adresem IP DNS Protection widzi lokalizację, ale nie rozpoznaje automatycznie każdego użytkownika ani urządzenia. Zmienny, współdzielony lub nieprawidłowy adres wyjściowy może uniemożliwić przypisanie.

Manual device DNS lub Secure DNS

Manual device DNS polega na wprowadzeniu obu adresów IP DNS Protection bezpośrednio na urządzeniu. Secure DNS używa natomiast DoH przez HTTPS i nadaje się do zarządzanych urządzeń, klientów mobilnych oraz sieci, w których nie można zmienić lokalnego resolvera. Chroni ścieżkę urządzenia także poza biurem. Trzeba jednak jawnie uwzględnić nazwy wewnętrzne, split DNS w VPN i aplikacje z własnym resolverem. Ręczna konfiguracja urządzenia nie jest tym samym co zarządzane wdrożenie Workspace za pomocą Endpoint Policy.

Aby przygotować tę ścieżkę, należy otworzyć lub utworzyć planowaną Location, włączyć Secure DNS i wybrać Save. Sophos Fusion wygeneruje właściwy dla lokalizacji DNS over HTTPS URL. Pełny URL lub wygenerowany profil trzeba przekazać osobie odpowiedzialnej za Windows, macOS albo MDM. W przypadku Sophos Endpoint osoba odpowiedzialna za Endpoint Policy otrzymuje Location i grupę pilotażową, aby wybrać tę Location w Policy. Nie wolno samodzielnie tworzyć adresu URL ani używać adresu z innej Location.

Zalecany wybór

Lokalizacja z Active Directory lub strefami wewnętrznymi: lokalny resolver z Conditional Forwarding; do DNS Protection trafiają tylko zapytania publiczne.
Prosta sieć bez stref wewnętrznych: DHCP może bezpośrednio rozgłaszać dwa adresy DNS Protection, jeśli Location zna publiczny adres IP ruchu wychodzącego.
Zarządzane urządzenia mobilne: Secure DNS uzupełniony o zdefiniowane wyjątki wewnętrzne i testy VPN.
Środowisko mieszane: ścieżka lokalizacji i Secure DNS działają równolegle, ale dla każdej klasy urządzeń należy udokumentować, która ścieżka jest właściwa. Podwójne przechwytywanie utrudnia diagnostykę.

Inwentaryzacja i reguły dostępu sieciowego

Przed zmianą należy zebrać następujące informacje:

dwa adresy IP DNS Protection z obszaru My Products > DNS Protection > Installers we własnym tenancie;
wszystkie publiczne adresy IPv4 ruchu wychodzącego, faktycznie używane podczas normalnej pracy, przełączania awaryjnego WAN, korzystania z SD-WAN, VPN lub centralnych serwerów proxy;
wewnętrzne strefy wyszukiwania do przodu i wstecz, ich autorytatywne resolvery oraz sufiksy wyszukiwania;
wartości DNS skonfigurowane przez DHCP, VPN lub statycznie w każdej sieci;
urządzenia lub aplikacje korzystające z własnego DoH, DoT, VPN albo na stałe wpisanego resolvera;
poprzedni resolver, czas obowiązywania opcji DHCP, osoby odpowiedzialne, okno serwisowe i ścieżkę wycofania zmian.

Na stronie Installers, obok pozycji IP addresses, należy kliknąć Copy i zawsze skopiować oba wyświetlane adresy. Plik Certificate do pobrania należy do osobnego procesu obsługi certyfikatów; aby strony blokowania HTTPS były widoczne, urządzenia muszą ufać temu certyfikatowi DNS Protection Root Certificate. Nie wolno mylić go z certyfikatem CA używanym przez zaporę do inspekcji HTTPS.

W przypadku Traditional DNS oba adresy tenantu muszą być osiągalne przez UDP 53 i TCP 53: z zatwierdzonych lokalnych resolverów w trybie forwardera albo wyłącznie z zatwierdzonych podsieci klienckich lub pilotażowych w trybie klienta bezpośredniego. UDP jest standardową ścieżką; TCP jest potrzebny między innymi w przypadku większych lub obciętych odpowiedzi. DNS Protection jest resolverem opartym na IPv4, ale może rozwiązywać rekordy AAAA, a tym samym cele IPv6. Osobny niezabezpieczony resolver IPv6 nie może omijać zaplanowanej ścieżki.

W przypadku Secure DNS urządzenia wymagają wychodzącego połączenia TCP 443 z celami DoH dostarczonymi przez Sophos. Strony blokowania HTTPS również wymagają TCP 443 i dostępu do blockpage.dnsprotection.sophos.com. Inspekcja TLS nie może niepostrzeżenie przerywać połączenia; konkretny wyjątek należy ściśle ograniczyć do udokumentowanej ścieżki docelowej Sophos.

Regułę portu 53 należy ograniczyć do wyświetlanych w tenancie adresów docelowych, a źródła rozdzielić zgodnie z projektem: planowane lokalne resolvery w trybie forwardera albo zatwierdzone podsieci klienckie lub pilotażowe w trybie klienta bezpośredniego. Reguła przychodząca WAN nie jest potrzebna. Nadrzędny serwer proxy DNS, przekierowanie DNS przez operatora lub przezroczysty portal przechwytujący mogą zmieniać odpowiedzi i muszą zostać wykryte podczas pilotażu.

Planowanie Location, ruchu wychodzącego i redundancji

Traditional DNS działa dopiero wtedy, gdy widoczny publiczny źródłowy adres IP zapytania pasuje do Location w Sophos Fusion. Prywatne adresy RFC 1918 nie służą do tego przypisania. W przypadku dynamicznego ruchu wychodzącego można użyć stabilnej nazwy FQDN usługi DDNS, ale musi ona publicznie wskazywać aktualny adres. Przy CGNAT lub adresie IP współdzielonym z innymi klientami jednoznaczne przypisanie nie jest zapewnione; właściwym rozwiązaniem jest własny publiczny adres IP.

W środowisku multi-WAN należy zinwentaryzować każdy możliwy adres wyjściowy i dodać go do odpowiedniej Location. Następnie trzeba przełączyć ścieżkę w kontrolowany sposób i przetestować obie trasy. Policy Routing nie może wysyłać ruchu DNS przez nieznane wyjście. Jeśli publiczne adresy IP pokrywają się między tenantami, według Sophos pierwszeństwo ma przypisanie utworzone jako pierwsze.

Sophos udostępnia dwa adresy resolverów. Oba należy skonfigurować jako równorzędną parę podstawową/zapasową. Trzeci publiczny resolver nie zapewnia redundancji, lecz tworzy obejście: resolvery nie zawsze korzystają z serwera zapasowego dopiero po całkowitej awarii i mogą równolegle wybierać najszybszy serwer. Rzeczywista odporność na awarie obejmuje także dwa lokalne resolvery, nadmiarową dystrybucję DHCP/VPN oraz przetestowaną ścieżkę przełączania awaryjnego WAN.

Procedura konfiguracji niezależna od producenta

W Sophos Fusion, w obszarze My Products > DNS Protection > Network setup, należy wybrać odpowiednią gałąź: Local resolver, Firewall forwarder, Windows DNS, Manual device DNS albo Secure DNS. Następnie trzeba potwierdzić planowaną Location i metodę połączenia. W przypadku Traditional DNS muszą być znane wszystkie produkcyjne publiczne adresy wyjściowe.
W przypadku Traditional DNS należy skopiować oba adresy resolverów z własnego tenantu w obszarze My Products > DNS Protection > Installers. Nie wolno używać wartości przykładowych ani adresów z innego tenantu.
W przypadku Secure DNS należy utworzyć lub edytować Location, włączyć Secure DNS, wybrać Save i skopiować wygenerowany dla tej lokalizacji DNS over HTTPS URL. Dokładnie ten URL lub wygenerowany profil trzeba przekazać osobie odpowiedzialnej za Windows, macOS albo MDM. Osoba odpowiedzialna za Sophos Endpoint Policy otrzymuje Location i grupę pilotażową, aby wybrać tę Location w Endpoint Policy.
W trybie forwardera należy skonfigurować oba adresy Sophos jako jedyne forwardery zapytań publicznych na lokalnym resolverze lub zaporze innego producenta: jeden jako Primary DNS server, a drugi jako Secondary DNS server. Należy zachować forwardery warunkowe lub strefy stub dla wewnętrznych stref wyszukiwania do przodu i wstecz. Jeśli produkt umożliwia podanie trzeciego serwera DNS, nie wolno dodawać tam obcego publicznego resolvera, ponieważ przełączenie na niego omija ochronę.
Regułę zapory dla ruchu wychodzącego należy rozdzielić zgodnie z projektem: w trybie forwardera zezwolić na UDP/TCP 53 tylko z autoryzowanych lokalnych resolverów do obu adresów Sophos; w trybie klienta bezpośredniego — tylko z zatwierdzonych podsieci pilotażowych lub klienckich do obu adresów. Port 53 należy zablokować dla wszystkich innych źródeł zgodnie z udokumentowanym projektem ochrony przed obejściem.
W przypadku Secure DNS należy zezwolić na TCP 443 tylko z zatwierdzonych urządzeń do wygenerowanego celu DoH i wymaganego celu strony blokowania. Wyjątki od inspekcji TLS należy ściśle ograniczyć.
W trybie forwardera zakresy DHCP i VPN pilota należy skierować do lokalnego resolvera. W trybie klienta bezpośredniego oba adresy Sophos należy rozgłaszać w zatwierdzonej podsieci pilotażowej. Urządzenia ze statyczną konfiguracją trzeba zinwentaryzować osobno.
Osoba odpowiedzialna za Windows, macOS albo MDM powinna wdrożyć wygenerowany adres URL lub profil Secure DNS tylko w grupie pilotażowej. W przypadku Sophos Endpoint osoba odpowiedzialna za Policy wybiera przekazaną Location w Endpoint Policy i przypisuje tę Policy przekazanej grupie pilotażowej. Należy udokumentować Location, Policy, grupę i metodę usunięcia.
Pamięć podręczną i istniejące dzierżawy należy odświeżać wyłącznie w pilocie i w sposób kontrolowany. Globalne czyszczenie pamięci podręcznej generuje niepotrzebne obciążenie i utrudnia porównanie.
Alternatywne ścieżki DNS należy ograniczyć dopiero po pomyślnej walidacji.

Granice ochrony przed obejściem

Klasyczny DNS można ograniczyć, zezwalając na wychodzący ruch UDP/TCP 53 w trybie forwardera tylko autoryzowanym lokalnym resolverom albo w trybie klienta bezpośredniego tylko zatwierdzonym podsieciom klienckim lub pilotażowym. Przekierowanie obcych celów portu 53 do własnego resolvera może pomóc w przypadku urządzeń, którymi trudno zarządzać, ale musi uwzględniać wyjątki dla wewnętrznych serwerów DNS, sieci VPN, sieci gościnnych i urządzeń wymagających konkretnego resolvera. Jeśli klientami można zarządzać, blokowanie jest bardziej przejrzyste niż przekierowanie.

Ta kontrola nie obejmuje DoH na TCP 443, nie obejmuje DoT na TCP 853 ani rozwiązywania nazw wewnątrz obcego tunelu VPN. Nie wolno ogólnie blokować TCP 443. Zasady przeglądarki, systemu operacyjnego, MDM i Endpoint muszą kontrolować niezatwierdzony Secure DNS; znane użycie DoT można obsłużyć precyzyjnie. Apple Private Relay i podobne usługi ochrony prywatności również wymagają osobnej decyzji projektowej.

Jeśli tylko urządzenia iPhone nie mają dostępu do Internetu, mimo że rozwiązywanie nazw działa na innych urządzeniach, należy testowo wyłączyć Limit IP Address Tracking dla danej sieci i sprawdzić ponownie. Tę zmianę trzeba świadomie wprowadzać na urządzeniach pilotażowych, ponieważ dotyczy ona funkcji ochrony prywatności urządzenia.

Ochrona przed obejściem kończy się na granicy administracyjnej. W sieci BYOD lub gościnnej udokumentowana, mniej rygorystyczna Policy jest często bardziej niezawodna niż próba wymuszenia każdego szyfrowanego resolvera bez zarządzania urządzeniami.

Pilotaż, walidacja i odbiór

Należy zacząć od reprezentatywnej sieci VLAN lub kilku urządzeń. Trzeba sprawdzić co najmniej nazwy publiczne, wewnętrzne nazwy FQDN, wyszukiwanie wsteczne, VPN, dostęp gościnny, przełączanie awaryjne WAN i nieszkodliwą blokadę testową.

Przed zmianą należy określić okres obserwacji i jednoznaczne kryteria wycofania. Pilotaż trzeba wycofać, jeśli przestanie działać rozwiązywanie nazw wewnętrznych lub przez VPN, pojawi się niewłaściwa Location albo Policy, połączenie DoH/TLS pozostanie niestabilne lub zostanie zakłócony wymagany cel biznesowy. Wdrożenia nie wolno rozszerzać, dopóki którykolwiek z tych problemów pozostaje nierozwiązany.

nslookup example.com <resolver-ip>
nslookup internal-host.corp.example <resolver-ip>

Po zainstalowaniu narzędzia dig:

dig @<resolver-ip> example.com A
dig @<resolver-ip> example.com AAAA
dig @<resolver-ip> internal-host.corp.example
dig +tcp @<resolver-ip> example.com

<resolver-ip> należy zastąpić lokalnym resolverem albo, przy użyciu bezpośrednim, adresem tenantu. corp.example jest strefą dokumentacyjną i należy ją zastąpić własną strefą wewnętrzną. Test TCP potwierdza, że działa nie tylko UDP.

Następnie trzeba otworzyć w przeglądarce testowy adres URL skopiowany z sekcji Installers > Check your configuration. Komunikat powitalny potwierdza ścieżkę DNS Protection, ale sam nie potwierdza właściwej Policy. Należy też celowo zablokować nieszkodliwą domenę testową i sprawdzić w Sophos Fusion, czy zapytanie, Location i Policy pojawiają się zgodnie z oczekiwaniami. Raportowanie nie musi działać w czasie rzeczywistym, dlatego nie należy stwierdzać awarii natychmiast po jednym zapytaniu.

Warunki odbioru:

oba resolvery Sophos działają osobno przez UDP i TCP;
wewnętrzne strefy wyszukiwania do przodu i wstecz pozostają wewnętrzne;
oczekiwany ruch wychodzący jest przypisany do właściwej Location;
blokowanie i dozwolone cele biznesowe działają;
przełączanie awaryjne WAN, VPN i klienci obsługujący IPv6 nie tworzą ścieżki alternatywnej;
nieautoryzowany DNS na porcie 53 jest blokowany lub przekierowywany zgodnie z projektem;
pilotażowe ręczne wdrożenia Secure DNS dla Windows, macOS i MDM używają dokładnie wygenerowanego adresu URL lub profilu, a pilotażowe wdrożenia Sophos Endpoint mają przypisaną Policy z planowaną Location; oba warianty pojawiają się we właściwej Location i Policy oraz przechodzą testy w biurze, w roamingu, przez VPN, dla domen wewnętrznych i podczas usuwania;
monitoring i przetestowana ścieżka wycofania są udokumentowane.

Eksploatacja i regularne kontrole

Po pilotażu wdrożenie należy prowadzić etapami według lokalizacji lub sieci VLAN. Na każdym etapie trzeba monitorować błędy DNS, zgłoszenia do pomocy technicznej, zablokowane domeny biznesowe i przypisanie ruchu wychodzącego. Serwery ze statyczną konfiguracją oraz urządzenia OT/IoT należy przełączać na końcu i w osobnym oknie serwisowym.

Po zmianach dotyczących WAN, NAT, DHCP, VPN, IPv6 lub lokalnych resolverów należy ponownie sprawdzić ścieżkę DNS. To samo dotyczy zmiany operatora lub nowego publicznego adresu wyjściowego. Trzeba regularnie sprawdzać, czy nadal skonfigurowane są oba resolvery tenantu, strefy wewnętrzne są rozwiązywane lokalnie i żaden dodatkowy serwer DNS nie omija ochrony. Powiadomienia o produkcie w obszarze My Environment > Alerts oraz stan w obszarze My Products > DNS Protection należy uwzględnić w procesie operacyjnym.

Bezpieczne wycofanie zmian lub usługi

Aby wycofać zmianę, należy najpierw wyłączyć nowe reguły blokowania lub przekierowywania DNS. Następnie trzeba wykonać czynności odpowiednie dla wybranego rodzaju wdrożenia:

Tryb forwardera: aktywnie przywrócić udokumentowane poprzednie forwardery na lokalnym resolverze. Następnie sprawdzić rozwiązywanie nazw wewnętrznych i publicznych.
Tryb klienta bezpośredniego: przywrócić udokumentowane wcześniejsze wartości DNS w DHCP, VPN i klientach ze statyczną konfiguracją. Odnowić dzierżawy na urządzeniach testowych, a następnie sprawdzić rozwiązywanie nazw wewnętrznych i publicznych.
Secure DNS: osoba odpowiedzialna za Windows, macOS albo MDM usuwa profil pilotażowy, natomiast osoba odpowiedzialna za Sophos Endpoint Policy usuwa przypisanie grupy pilotażowej. Następnie należy przywrócić poprzedni stan DNS i potwierdzić, że ścieżka DoH nie jest już używana.

Forwardery warunkowe i Location w Sophos Fusion należy początkowo pozostawić, chyba że przyczyną incydentu była sama Location.

Rozwiązywanie problemów według objawu

Nazwy publiczne w ogóle się nie rozwiązują

Najpierw należy jawnie przetestować oba adresy Sophos przez UDP i TCP. Następnie trzeba sprawdzić regułę ruchu wychodzącego, NAT, trasę i widoczny publiczny źródłowy adres IP. Jeśli źródłowy adres IP nie jest przypisany do żadnej Location lub koliduje z innym tenantem, DNS Protection może odrzucać zapytania. W przypadku DDNS należy dodatkowo sprawdzić publiczne rozwiązywanie nazwy FQDN.

Nie działają nazwy wewnętrzne lub Active Directory

Należy sprawdzić, którego resolvera faktycznie używa klient. Następnie trzeba skontrolować forwardery warunkowe, autorytatywne serwery docelowe, strefy wyszukiwania wstecznego, sufiksy wyszukiwania i split DNS w VPN. Bezpośrednio przypisany resolver DNS Protection nie zna stref prywatnych.

Nie działają tylko duże odpowiedzi lub pojedyncze domeny

Należy przetestować TCP 53. Jeśli UDP działa, a dig +tcp nie, zwykle brakuje reguły zezwalającej na TCP albo urządzenie pośrednie odrzuca połączenie. Jeśli dozwolona domena nadal jest blokowana, trzeba również sprawdzić cel CNAME i klasyfikację bezpieczeństwa.

Sophos Fusion nie pokazuje Location lub pokazuje niewłaściwą

Należy ustalić faktyczny ruch wychodzący, a nie opierać się wyłącznie na skonfigurowanym adresie WAN. SD-WAN, centralne bramy NAT, serwery proxy i przełączanie awaryjne mogą zmieniać źródłowy adres IP. Następnie trzeba odczekać wystarczająco długo na raporty i potwierdzić, że test rzeczywiście korzystał z planowanego resolvera, a nie z DoH przeglądarki lub VPN.

W przypadku Location zdefiniowanej za pomocą nazwy FQDN trzeba dodatkowo sprawdzić jej publiczne rozwiązywanie. Dla rekordu DNS w Cloudflare musi obowiązywać ustawienie Proxy status: DNS only; rekord z włączonym proxy nie zwraca rzeczywistego publicznego adresu wyjściowego. Adres prywatny ani adres IPv6 nie jest prawidłowym adresem Location. Jeśli ta sama wartość publiczna jest już przypisana do innego klienta lub nazwa FQDN jest nieprawidłowa, należy poprawić przypisanie przed kontynuowaniem wdrożenia.

Brakuje strony blokowania, choć blokowanie DNS działa

Nie jest to dowód, że domena została dozwolona. Należy sprawdzić dostęp do blockpage.dnsprotection.sophos.com, zaufanie do DNS Protection Root Certificate, Pharming Protection, serwer proxy lub filtr WWW oraz inspekcję TLS. Jeśli zapora odszyfrowuje ścieżkę strony blokowania, dla udokumentowanej ścieżki docelowej Sophos należy zastosować ściśle ograniczoną akcję Do not decrypt. Instalowaniem i usuwaniem certyfikatu trzeba zawsze zarządzać za pomocą procesu właściwego dla danej platformy.

Dozwolona domena nadal jest blokowana

Najpierw należy sprawdzić docelową nazwę CNAME i jej kategorię: dozwolona domena początkowa może nadal wskazywać nazwę blokowaną ze względu na kategorię lub Threat Score. Po zmianie Policy trzeba również odczekać czas TTL DNS i wygaśnięcie lokalnej pamięci podręcznej albo odświeżyć je w kontrolowany sposób. Nie należy przyspieszać wdrożenia za pomocą ogólnych, szerokich wyjątków.

Blokada obejścia nie działa

W dziennikach należy wyszukać wychodzący ruch UDP/TCP 53, TCP 853 i znane połączenia Secure DNS. Następnie trzeba sprawdzić przeglądarkę, system operacyjny, VPN i lokalne oprogramowanie zabezpieczające. Filtr portu 53 nie może wykryć ani zablokować szyfrowanego DNS na porcie 443.

Nazwy DNS są rozwiązywane, ale brakuje Policy i raportów

Najpierw za pomocą ipconfig, nslookup albo — w systemie Linux lub macOS — dig należy sprawdzić, z których resolverów rzeczywiście korzysta urządzenie. Następnie trzeba wykonać test Standard lub Extended na stronie https://www.dnsleaktest.com/. W przypadku korzystania z DNS Protection wszystkie wartości w kolumnie Hostname zawierają wzorzec gw-<numer>.<region>.dnsprotection.sophos.com, a jako dostawca ISP widnieje Amazon lub odpowiadająca mu nazwa. Inne resolvery wskazują na wyciek DNS albo przekierowanie przez operatora.

Jeśli https://dns.access.sophos.com wyświetla błąd przeglądarki zamiast strony powitalnej, a jednocześnie w panelu widnieje komunikat No queries received from locations albo Sophos Firewall zgłasza DNS Protection: Connectivity Error, najpierw należy usunąć przyczynę korzystania z innej ścieżki resolvera. W tym celu trzeba sprawdzić ustawienia DNS routera, DHCP i DHCPv6, statyczne wpisy DNS, przekierowanie przez operatora oraz równoległe resolvery IPv6. Dopiero potem należy analizować Policy lub raportowanie; ta procedura diagnostyczna dotyczy ścieżki sieciowej i nie powinna być stosowana bez weryfikacji do Endpoint DoH.

Powiązane istniejące instrukcje

Konfiguracja Sophos DNS Protection z Sophos Firewall pokazuje konkretną integrację z SFOS.
Endpoint DNS Protection Policy opisuje osobną, zarządzaną ścieżkę Workspace dla urządzeń końcowych.