Bezpieczne zarządzanie Locations w Sophos DNS Protection

Location informuje Sophos DNS Protection, do której placówki, sieci lub grupy urządzeń należy zapytanie DNS. Dopiero to przypisanie umożliwia stosowanie Filtering Policies zależnych od lokalizacji i tworzenie miarodajnych raportów. Aby zapewnić stabilne działanie, Location powinna odzwierciedlać wyjście do Internetu, a nie każdą wewnętrzną sieć VLAN.

Pełny proces rozpoczyna się w My Products > DNS Protection > Locations: należy wybrać metodę połączenia, utworzyć Location, sprawdzić przypisanie na stronie Policies, przetestować rzeczywistą ścieżkę DNS, a dopiero potem usunąć stare adresy IP lub Locations. Default location jest przy tym niezmiennym punktem wyjścia dla Secure DNS, natomiast własne Locations reprezentują placówki, regiony lub odrębne grupy Policy.

Wybór między Default a własną Location

Predefiniowana Default location korzysta z Secure DNS i działa bez zarejestrowanego publicznego adresu placówki. Można ją przypisać zarówno do Endpoint policy, jak i Filtering policy. Jej szczegóły można wyświetlić w My Products > DNS Protection > Locations > Default, ale nie można jej edytować ani usunąć.

Własna Location jest przydatna, jeśli zachodzi co najmniej jeden z poniższych warunków:

• Firewall, router lub lokalny resolver DNS wysyła tradycyjne zapytania DNS.
• Placówki lub grupy urządzeń wymagają różnych Filtering Policies.
• Raporty mają rozdzielać zapytania DNS według regionu lub wyjścia do Internetu.
• Urządzenia Endpoint wymagają własnego przypisania Secure DNS zamiast Default.

DNS Protection zezwala na maksymalnie 50 Locations. Własna Location może korzystać z Secure DNS, Traditional DNS over IPv4 albo obu metod. Dla każdej Location można zarejestrować maksymalnie 100 publicznych adresów IPv4 lub nazw FQDN.

Wybór odpowiedniej metody połączenia

Secure DNS

Secure DNS przesyła DNS przez HTTPS. Ta metoda jest odpowiednia dla zgodnych urządzeń i jest wymagana w przypadku Sophos Endpoint z DNS Protection. Podczas zapisywania Central generuje indywidualny DNS over HTTPS URL. Sophos Endpoint automatycznie konfiguruje zarządzane urządzenia; w przypadku ręcznej konfiguracji urządzenia ten adres URL jest wymagany.

W przypadku tego wdrożenia należy użyć i skopiować dokładnie dwa adresy IPv4 usługi DNS Protection wyświetlane przez Central.

Traditional DNS over IPv4

Traditional DNS over IPv4 wysyła niezaszyfrowane zapytania DNS do resolverów DNS Protection. Ta metoda jest odpowiednia dla firewalli, routerów i lokalnych serwerów DNS. DNS Protection rozpoznaje Location na podstawie publicznego źródłowego adresu IP. Dlatego należy zarejestrować publiczny adres WAN, publiczny zakres lub FQDN wskazujący na ten adres — nigdy wewnętrzny adres RFC 1918.

Pełna konfiguracja firewalla wraz z forwarderami, strefami wewnętrznymi i DHCP znajduje się w osobnym przewodniku dotyczącym Sophos DNS Protection z Sophos Firewall. Sama Location nie zmienia jeszcze ścieżki DNS w sieci.

Obie metody

Oba przełączniki mogą być aktywne w tej samej własnej Location. Jest to przydatne, gdy ten sam kontekst Policy obejmuje zarówno zarządzane Endpointy korzystające z DoH, jak i resolver placówki korzystający z tradycyjnego DNS. Najpierw należy świadomie zdecydować, czy obie te ścieżki rzeczywiście powinny podlegać temu samemu filtrowaniu i raportowaniu.

Wymagania wstępne i plan adresacji

Przed utworzeniem należy zanotować:

• unikatową nazwę, krótki opis i osobę odpowiedzialną technicznie,
• wymaganą metodę połączenia,
• wszystkie publiczne adresy wyjściowe używane przez Multi-WAN, SD-WAN i Failover,
• prawidłowo utrzymywany FQDN DDNS dla dynamicznego adresu publicznego,
• docelową Filtering policy oraz, w stosownych przypadkach, Endpoint policy,
• bezpośrednio podłączone urządzenie testowe dla każdej ścieżki DNS.

Default jest nazwą zastrzeżoną. Odpowiednim przykładem jest ZH-HQ-Egress; opis może zawierać operatora, łącza WAN i osobę odpowiedzialną. Nazwa placówki powinna pozostać niezmienna nawet po zmianie operatora.

Do wprowadzania zmian w DNS Protection wymagana jest odpowiednia rola administracyjna w Sophos Fusion. Dostęp tylko do odczytu jest odpowiedni do kontroli, ale nie do tworzenia, edytowania ani usuwania. Ręczne wprowadzenie publicznego adresu IP lub FQDN nie stanowi potwierdzenia uprawnienia do korzystania z usługi.

Samodzielne, czyli sieciowe korzystanie z DNS wymaga co najmniej jednego prawidłowego firewalla połączonego z Central i objętego ochroną Xstream Protection. Zarządzane Endpoint DNS jest natomiast funkcją Workspace; sama ochrona Xstream nie jest do tego wystarczająca. Add known IPs rozpoznaje wyłącznie publiczne adresy licencjonowanych Sophos Firewalls z Xstream Protection. Secure DNS wymaga urządzenia obsługującego DNS przez HTTPS; Sophos Endpoint wymaga w przypadku DNS Protection właśnie tej metody połączenia.

Tworzenie własnej Location

1. Otwórz My Products > DNS Protection > Locations > Add location. Na liście Locations przycisk Add prowadzi do tego okna dialogowego.
2. Wprowadź unikatową nazwę w polu Location name, a przeznaczenie w polu Description.
3. W sekcji Connection method włącz Secure DNS, Traditional DNS over IPv4 lub obie opcje.
4. W przypadku Secure DNS zanotuj wyświetlone adresy IPv4. DNS over HTTPS URL zostanie wygenerowany dopiero po wybraniu Save.
5. W przypadku Traditional DNS over IPv4 dodaj wartości publiczne w polu IPv4 addresses or FQDNs. Każdy wpis zatwierdź klawiszem Enter lub Tab. Podczas wklejania wielu wartości należy oddzielić je znakami nowego wiersza.
6. Wybierz Save.
7. W przypadku Secure DNS skopiuj wygenerowany DNS over HTTPS URL i zapisz go w bezpiecznym miejscu przed wybraniem Close.

Dodawanie wykrytych adresów

Po wybraniu Add known IPs Central wyświetla sugestie:

• Your Current Location to adres, z którego pochodzi bieżąca sesja Central. Podczas sesji VPN jest to publiczny adres serwera VPN, który może nie być poszukiwanym adresem placówki.
• Your Firewalls pokazuje adres, za pośrednictwem którego licencjonowany Sophos Firewall łączy się z Central. Automatycznie wykrywane są wyłącznie firewalle z Xstream Protection.

Wykryta wartość jest jedynie sugestią. DNS Protection nie aktualizuje jej automatycznie po późniejszej zmianie adresu. W przypadku Multi-WAN niewykryte adresy wyjściowe należy dodać ręcznie.

IP, FQDN, Multi-WAN i DDNS

W przypadku stałego łącza publiczny adres IPv4 jest zwykle najjednoznaczniejszym wyborem. W konfiguracji Multi-WAN należy zarejestrować wszystkie adresy, przez które zapytania DNS mogą faktycznie wychodzić; alternatywnie można użyć odpowiedniego zakresu publicznego. Jeśli brakuje adresu Failover, po przełączeniu łącza DNS Protection nie będzie działać dla tej Location.

W przypadku adresu dynamicznego należy wprowadzić FQDN zewnętrznej usługi DDNS. Klient DDNS musi niezawodnie aktualizować rekord. Jeśli używany jest w tym celu Sophos Firewall, przewodnik Konfigurowanie i sprawdzanie Dynamic DNS na Sophos Firewall opisuje konfigurację w Network > Dynamic DNS > Add. DNS Protection sprawdza zmiany adresu co minutę, a następnie potrzebuje ośmiu sekund na aktualizację pamięci podręcznej. Podczas aktualizacji po stronie operatora, usługi DDNS i pamięci podręcznej rozpoznawanie nazw może zostać na krótko przerwane.

Obsługiwane są usługi DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS i Cloudflare. W Cloudflare ustawienie Proxy status musi mieć wartość DNS only; rekord z włączonym proxy zwraca adresy Cloudflare zamiast publicznego adresu IP wyjścia.

CGNAT i konflikty adresów

Traditional DNS wymaga unikatowego publicznego źródłowego adresu IP. W przypadku CGNAT oraz współdzielonych adresów wyjściowych operatora, serwera proxy lub VPN ten sam adres IP może występować na kilku kontach klientów. DNS Protection przyznaje pierwszeństwo użytkownikowi, który jako pierwszy utworzył Location. Inny FQDN nie pomoże, jeśli wskazuje na ten sam współdzielony adres IP.

Niezawodnym rozwiązaniem jest uzyskanie od operatora unikatowego adresu publicznego albo zastosowanie Secure DNS na zgodnych urządzeniach. Adresy prywatne, takie jak 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16, nie identyfikują wyjścia do Internetu i nie powinny być dodawane do Location.

Pełne przypisywanie Policy

Sama Location umożliwia wprawdzie przypisanie przychodzących zapytań DNS, ale nie definiuje jeszcze wymaganego filtrowania.

• W My Products > DNS Protection > Policies > Filtering policies należy przenieść Location z Available do Assigned to this policy. Do Location może być przypisana tylko jedna Filtering policy.
• W Endpoint policy należy przypisać Location do wybranych urządzeń z systemem Windows. Musi ona korzystać z Secure DNS; dopuszczalna jest również Default location.

Ścieżka Endpoint, wewnętrzne Domain Exclusions i komponent Agent zostały omówione w osobnym przewodniku dotyczącym Endpoint. Przypisanie Endpoint nie zastępuje Filtering policy: pierwsze określa, które urządzenia korzystają z Location, a drugie określa sposób obsługi domen i kategorii.

Edytowanie Location

Przed każdą zmianą należy najpierw udokumentować nazwę, metody, listę IP/FQDN, wykorzystanie DoH i oba przypisania Policy. Następnie otworzyć własną Location w My Products > DNS Protection > Locations, dostosować wartości i zapisać je przyciskiem Save.

Bezpieczna migracja wyjścia przebiega w następującej kolejności:

1. Dodaj nowy adres publiczny obok starego adresu.
2. Poczekaj, aż nowa ścieżka internetowa stanie się aktywna.
3. Sprawdź rozpoznawanie DNS i zastosowanie Policy przez nową ścieżkę.
4. Dopiero potem usuń stary adres.

Przechodząc z Traditional DNS na Secure DNS, najpierw należy skonfigurować i zweryfikować ścieżkę DoH na grupie pilotażowej. Traditional DNS pozostaje aktywny do czasu pomyślnego zakończenia testu. Pozwala to uniknąć niesprawdzonego przełączenia i umożliwia szybki powrót do dotychczasowej ścieżki.

Weryfikacja po utworzeniu lub zmianie

1. W My Products > DNS Protection > Locations sprawdź, czy wartości Location, Description oraz wyświetlana liczba w kolumnie IP addresses/FQDNs są prawidłowe.
2. Otwórz Location i sprawdź w jej szczegółach, czy skonfigurowano zamierzoną Connection method oraz oczekiwane wartości IP/FQDN.
3. W sekcji Policies sprawdź, czy Location jest przypisana do zamierzonej Filtering policy oraz, w stosownych przypadkach, Endpoint policy.
4. Rozwiąż niewątpliwie dozwoloną domenę oraz domenę testową celowo blokowaną przez przypisaną Policy, korzystając dokładnie z odpowiedniej ścieżki DNS. Uwzględnij pamięć podręczną i wartość TTL DNS.
5. Sprawdź na Dashboardzie lub w Reports, czy zapytanie pojawia się w oczekiwanej Location.

Samo pomyślne rozpoznanie nazwy nie potwierdza ani właściwej Policy, ani właściwej Location. Dopiero połączenie pozytywnego testu, testu blokowania i pasującego wpisu w raporcie potwierdza całą ścieżkę. Jeśli brakuje zapytania, należy najpierw porównać rzeczywisty publiczny źródłowy adres IP z wartościami IP addresses/FQDNs; w przypadku nieprawidłowego FQDN lub konfliktu IP należy następnie sprawdzić My Environment > Alerts.

Rozwiązywanie problemów według objawów

Location nie akceptuje adresu

Wpisy statyczne i nazwy hostów są obsługiwane wyłącznie w przypadku IPv4. Adres prywatny lub IPv6 nie jest prawidłowym wyjściem placówki. Należy wprowadzić publiczny adres WAN albo FQDN wskazujący na ten adres i zatwierdzić każdą wartość klawiszem Enter lub Tab.

Rozpoznawanie przestaje działać lub Location nie pojawia się w Reports

Porównaj rzeczywiste wyjście z zapisaną listą IP/FQDN. W przypadku Multi-WAN aktywny może być niezarejestrowany adres Failover. Dla FQDN należy najpierw sprawdzić, czy wskazuje on na prawidłowy publiczny adres IPv4. Central zgłasza nieprawidłowe FQDN i konflikty IP w My Environment > Alerts.

Konflikt IP lub CGNAT

Jeśli ten sam publiczny adres IP należy już do innego klienta, pierwszeństwo zachowuje Location utworzona jako pierwsza. Alias wskazujący na ten sam adres IP niczego nie zmienia. Należy zamówić u operatora unikatowy publiczny adres IPv4 albo zastosować Secure DNS na odpowiednich urządzeniach.

Awaria DDNS po zmianie adresu

Sprawdź, czy rekord DDNS zwraca już nowy adres publiczny. Następnie uwzględnij co najmniej cykl aktualizacji DNS Protection oraz aktualizację pamięci podręcznej. W Cloudflare sprawdź ustawienie DNS only. Stary adres IP należy usunąć dopiero wtedy, gdy nowa wartość i rzeczywiste wyjście będą zgodne.

Policy nie działa

Sprawdź, do której Location faktycznie przypisano zapytanie i do jakiej Filtering policy należy ta Location. Dla każdej Location obowiązuje tylko jedna Filtering policy. Po zmianie Policy rekord DNS znajdujący się już w pamięci podręcznej może działać do czasu wygaśnięcia jego TTL; dlatego należy przetestować ponownie z nową nazwą testową lub po wygaśnięciu pamięci podręcznej.

Inne resolvery omijają DNS Protection

Jeśli klienci otrzymują dodatkowe tradycyjne lub IPv6 serwery DNS, zapytania mogą omijać DNS Protection. Do rozpoznawania nazw publicznych należy udostępniać wyłącznie zaplanowaną ścieżkę DNS Protection. DNS Protection działa w oparciu o IPv4, ale może również rozpoznawać rekordy AAAA; oddzielny resolver IPv6 nie jest do tego potrzebny.

Eksploatacja i cykl życia

Locations należy sprawdzać po zmianie operatora, WAN, DDNS lub Policy, a także regularnie podczas eksploatacji. Na liście należy porównać wartości Location, Description i liczbę w kolumnie IP addresses/FQDNs z udokumentowanym stanem docelowym. Connection method sprawdza się w szczegółach Location, a przypisanie na stronie Policies. Automatycznie sugerowane adresy nie są stale synchronizowane: jeśli wcześniej wykryty adres IP ulegnie zmianie, należy dostosować Location lub utrzymywaną nazwę DDNS i ponownie przeprowadzić weryfikację.

W przypadku czynności operacyjnych miarodajne są aktualne strony pomocy. Informacje o wersjach umieszczają w czasie zmiany takie jak automatycznie sugerowane adresy IP, funkcja kopiowania adresów IP i nazw FQDN lub wyświetlanie Locations przypisanych w Policies; nie zastępują jednak aktualnej instrukcji konfiguracji. Według stanu na 24 września 2026 r. aktualne strony pomocy i informacje o wersjach nie zawierają konkretnej daty wycofania DNS Protection z eksploatacji.

Bezpieczne usuwanie własnej Location

Default location nie może zostać usunięta. W przypadku własnej Location należy zachować następującą kolejność:

1. Zapisz nazwę, opis, włączone metody połączenia, wartości IP/FQDN, przypisania Policy i istniejący adres URL DoH. Udokumentuj ponadto wszystkie firewalle, resolvery i ręcznie skonfigurowane urządzenia korzystające z Location.
2. Jeśli ścieżka DNS jest nadal potrzebna, utwórz i skonfiguruj zastępczą Location. Może ona działać równolegle ze starą Location tylko wtedy, gdy korzysta z własnej, jednoznacznie routowalnej tożsamości lub nowo udostępnionej ścieżki Secure DNS.
3. Jeśli używana jest zastępcza Location, przypisz ją do odpowiednich Filtering i Endpoint Policies. Następnie najpierw przełącz na zastępczą Location kontrolowaną ścieżkę pilotażową, na przykład urządzenia pilotażowe, resolver lub — o ile jest to możliwe operacyjnie — firewall.
4. W przypadku zastępczej Location rozwiąż przez ścieżkę pilotażową dozwoloną domenę oraz domenę blokowaną przez przypisaną Policy. Sprawdź w Reports, czy oba zapytania są przypisane do zastępczej Location. Dopiero po pomyślnej weryfikacji przełącz pozostałe firewalle, resolvery i ręcznie skonfigurowane urządzenia. Jeśli ścieżka DNS jest wycofywana bez zastępstwa, zakończ zamiast tego jej używanie we wszystkich udokumentowanych systemach. Następnie usuń starą Location z dotychczasowych Policies i sprawdź, czy nie jest już używana.
5. Dopiero teraz wybierz starą Location w My Products > DNS Protection > Locations, a następnie Delete.
6. W przypadku zastępczej Location ponownie sprawdź przez nową ścieżkę dozwolone i blokowane rozpoznawanie oraz przypisanie w Reports. W przypadku wycofania bez zastępstwa sprawdź, czy pozostałe ścieżki DNS działają zgodnie z założeniami.

Jeśli zastępcza Location dla Traditional DNS ma korzystać z tej samej tożsamości publicznej i dlatego nie może jednoznacznie istnieć obok starej Location, należy zatrzymać się przed wybraniem Delete. Planowane przełączenie i ryzyko konfliktu trzeba udokumentować; usunięcie można wykonać dopiero w ramach świadomie zatwierdzonego przełączenia. W takim przypadku zastępcza Location wyraźnie nie jest uznawana za zweryfikowaną równolegle.

Ponowne utworzenie z zapisanymi nazwą, opisem, metodami, wartościami IP/FQDN i przypisaniami Policy jest jedynie najlepszą możliwą próbą odtworzenia, a nie gwarantowanym powrotem do poprzedniego stanu. W przypadku spornej publicznej tożsamości Traditional DNS nie przywraca ono w szczególności w niezawodny sposób pierwszeństwa Location utworzonej jako pierwsza. W przypadku Secure DNS ponowne utworzenie generuje nowy DNS over HTTPS URL, który należy ponownie wdrożyć na wszystkich ręcznie skonfigurowanych urządzeniach. W stosownych przypadkach należy ponownie połączyć firewalle i resolvery ze ścieżką tradycyjną. Następnie ponownie przetestować dozwolone i blokowane rozpoznawanie oraz Reports.