Skonfiguruj trasy żądań DNS na Sophos Firewall

Za pomocą DNS Request Routes można określić w Sophos Firewall, który serwer DNS powinien być używany dla określonych domen lub stref odwrotnych. Jest to szczególnie przydatne, jeśli zapora korzysta z publicznych serwerów DNS, ale nazwy wewnętrzne muszą być rozpoznawane przez wewnętrzny serwer DNS.

Typowymi przykładami są domeny Active Directory, aplikacje wewnętrzne, wyszukiwania wsteczne lub środowiska VPN.

Gdy Sophos DNS Protection jest używany z Sophos Firewall, trasy żądań DNS stają się jeszcze ważniejsze. Domeny publiczne trafiają następnie do usługi ochrony DNS, ale domeny wewnętrzne w dalszym ciągu trafiają do lokalnego serwera lub kontrolera domeny DNS. Bez tego oddzielenia aplikacje wewnętrzne, logowania do usługi AD lub wyszukiwania wsteczne mogą nagle wydawać się problemami z siecią.

Orientacja i projektowanie

DNS Trasy żądań działają niezawodnie tylko wtedy, gdy jest jasne, który mechanizm rozpoznawania nazw widzi które żądanie. Dlatego należy najpierw rozróżnić projekt DNS, klienta DNS, strefy wewnętrzne i ścieżkę routingu.

DNS Żądanie trasy, DNS Serwer czy opcja DHCP?

DNS Trasy żądań są często mylone z globalnymi serwerami DNS lub opcjami DHCP. Funkcje rozwiązują różne problemy.

• Globalne serwery DNS: Domyślna rozdzielczość zapory sieciowej dla Internetu DNS, ogólna rozdzielczość FQDN, aktualizacje i usługi w chmurze.
• DNS Trasa żądania: przekierowuje określone domeny lub strefy zwrotne do zdefiniowanych serwerów DNS. Typowe są Active Directory, domeny wewnętrzne, lokalizacja DNS i podział DNS.
• DHCP Opcja: dystrybuuje serwery DNS lub domeny wyszukiwania wśród klientów. Jest to istotne, jeśli klienci mają używać bezpośrednio określonego serwera DNS.

Zatem trasa żądania DNS nie zmienia automatycznie konfiguracji DNS wszystkich klientów. Trasa kontroluje, gdzie Sophos Firewall sami lub klienci korzystający z zapory sieciowej jako spedytorzy DNS przesyłają określone żądania DNS. Jeśli klienci mają bezpośrednio korzystać z wewnętrznego serwera DNS, bardziej odpowiednia jest opcja DHCP na Sophos Firewall.

Ważna jest również różnica względem DNS Host Entry: DNS Host Entry odpowiada na konkretną nazwę hosta bezpośrednio adresem IP na firewallu. DNS Request Route przekazuje natomiast domenę lub strefę do innego serwera DNS. W przypadku Active Directory i dynamicznych stref wewnętrznych Request Route jest prawie zawsze czystsza niż wiele pojedynczych wpisów hosta.

Który projekt DNS pasuje?

Przed utworzeniem trasy żądania DNS powinno być jasne, który mechanizm rozpoznawania nazw jest używany w danej sieci. Trasa pomaga tylko wtedy, gdy Sophos Firewall również widzi żądanie.

• Klienci pytają Sophos Firewall: Zapora przekazuje domeny publiczne globalnie i domeny wewnętrzne poprzez trasę żądań DNS. Działa to dobrze w małych i średnich lokalizacjach, DNS Protection, a także w sieciach gościnnych lub klienckich.
• Klienci pytają bezpośrednio wewnętrzne serwery DNS: Kontrolery domeny lub serwery DNS rozwiązują wewnętrznie i przekazują zewnętrznie. Jest to odpowiednie dla klasycznych sieci Active Directory z systemem Windows DNS jako centralnym programem rozpoznawania nazw.
• Klienci VPN pytają zaporę sieciową: Zapora wykorzystuje trasy żądań dla domen wewnętrznych. Jest to odpowiednie w przypadku zdalnego dostępu za pomocą prostej ścieżki DNS przez zaporę ogniową.
• Klienci VPN pytają bezpośrednio wewnętrzne serwery DNS: DNS działa przez VPN do kontrolera domeny lub serwera DNS. Jest to odpowiednie dla większych środowisk AD, gdy klienci powinni używać tej samej logiki DNS, co w LAN.

W środowiskach mieszanych bardzo pomocny jest krótki szkic DNS: sieć kliencka, przypisany serwer DNS, domena wyszukiwania, wewnętrzne strefy DNS, trasy żądań DNS i ścieżka routingu do serwera docelowego. Bez tego przeglądu trasa żądania jest często opracowywana później, nawet jeśli klient nie używa zapory sieciowej jako modułu tłumaczącego DNS.

Aby trasy żądań DNS działały dla klientów, Sophos Firewall musi znajdować się w ścieżce zapytania jako serwer DNS. Może to mieć miejsce bezpośrednio, gdy klienci otrzymują adres IP interfejsu zapory ogniowej jako serwery DNS lub pośrednio, gdy wewnętrzny moduł rozpoznawania nazw celowo przekierowuje do zapory. Jeśli klienci bezpośrednio żądają kontrolera domeny, zapora nie postrzega tego żądania DNS jako mechanizmu rozpoznawania nazw i nie może go przekierować trasą żądania.

Kiedy potrzebne są trasy żądań DNS?

DNS Trasy żądań są przydatne, jeśli:

• należy rozwiązać wewnętrzne nazwy hostów, takie jak server01.firma.local
• Wyszukiwanie wsteczne wewnętrznych sieci IP powinno działać
• Użytkownicy VPN powinni używać nazw wewnętrznych
• wiele lokalizacji ma własne strefy DNS
• sama zapora sieciowa musi dotrzeć do systemów wewnętrznych poprzez FQDN
• publiczne serwery DNS nie znają nazw wewnętrznych

Bez trasy żądania DNS zapora wysyła zapytanie do globalnie skonfigurowanego serwera DNS. Jeśli domena wewnętrzna nie jest tam znana, rozwiązanie nie powiedzie się.

Ta różnica jest szczególnie ważna w przypadku dostępu zdalnego. Jeśli klienci VPN używają zapory sieciowej jako serwera DNS, trasa żądań DNS może zapewnić, że domeny wewnętrzne nadal trafią do właściwego kontrolera domeny lub serwera DNS. Jeśli natomiast klienci VPN otrzymują bezpośrednio wewnętrzne serwery DNS, należy również sprawdzić, czy na kliencie są poprawne routing, reguły zapory sieciowej i sufiksy DNS.

Wymagania wstępne

• Dostęp do WebAdmin Sophos Firewall
• Sophos Firewall jest poprawnie skonfigurowany jako resolver DNS lub forwarder DNS w Network > DNS > DNS configuration
• Wewnętrzny serwer DNS jest osiągalny
• Znana jest domena lub sieć
• Reguły zapory zezwalają na ruch DNS do serwera docelowego
• Dla sieci lokacji: Routing do serwera DNS działa
• Klient, którego dotyczy problem, albo używa zapory sieciowej jako serwera DNS, albo celowo uzyskuje inny serwer DNS

⚠️ Problemy z DNS często przypominają problemy z routingiem, VPN lub aplikacją. Przed wprowadzeniem większych zmian należy sprawdzić, czy z serwerem docelowym można się połączyć poprzez IP i czy nie zawodzi jedynie rozpoznawanie nazw.

W Network > DNS > DNS configuration należy także sprawdzić, w jaki sposób zapora rozwiązuje normalne żądania DNS. Jeśli używany jest DNS Protection, dostępne są tam adresy IP DNS Protection. Jeśli używane są klasyczne forwardery lub wewnętrzne resolvery, serwery te muszą być dostępne. Za pomocą Test name lookup można sprawdzić bezpośrednio w konfiguracji DNS, czy zapora może zasadniczo rozpoznać nazwę lub adres IP.

DNS Skonfiguruj trasę żądania

Konfiguracja jest technicznie prosta, ale szybko staje się skomplikowana, gdy domeny, strefy odwrotne, klienci VPN i wiele lokalizacji łączą się.

Utworzyć DNS Request Route dla domeny

Trasa domeny zapewnia, że żądania dotyczące określonej domeny są wysyłane do zdefiniowanego serwera DNS.

Przykład:

• Host/domain name: firma.local
• DNS server: 10.10.10.10

Procedura:

1. Zaloguj się do Sophos Firewall.
2. Otwórz Network > DNS.
3. Przejdź do obszaru DNS request route.
4. Wybierz Add.
5. Wprowadź domenę wewnętrzną w Host/domain name, na przykład firma.local.
6. W Target servers wybierz wewnętrzny serwer DNS lub utwórz go jako host za pomocą Create.
7. Zapisz.

Wartość w Host/domain name powinna wyglądać jak FQDN albo nazwa strefy, a nie jak URL, reguła wildcard czy swobodny opis. API Sophos traktuje tę wartość jako pole FQDN o maksymalnej długości 255 znaków. Dla zwykłych tras domen wystarczy na przykład firma.local; dla wyszukiwania wstecznego używa się odpowiedniej strefy in-addr.arpa.

Jeśli na zaporze brakuje trafienia w pamięci podręcznej DNS, pasujące żądanie dla tej domeny nie jest wysyłane do zwykłych usług przesyłania dalej lub serwerów głównych, ale do serwerów docelowych trasy żądania. Jest to celowe: nie należy przypadkowo pytać o strefy wewnętrzne na zewnątrz. Oznacza to jednak również, że niepoprawnie wybrany serwer docelowy poprawnie odpowiada na zapytanie i nadal może być błędny pod względem technicznym.

Użyj wielu serwerów docelowych

Możesz dodać więcej niż jeden serwer DNS w obszarze Serwery docelowe. Ma to sens, jeśli istnieje kilka wewnętrznych serwerów DNS lub jeśli DNS powinno być redundantnie dostępne poprzez połączenie lokalizacyjne.

Możliwe serwery docelowe:

• wewnętrzne serwery DNS w sieci lokalnej
• Serwer DNS po drugiej stronie połączenia VPN
• Serwer DNS w innej lokalizacji
• publiczne serwery DNS, jeśli określona domena ma być celowo rozwiązywana zewnętrznie

Kolejność jest istotna. Zapora wysyła zapytania do wybranych hostów w kolejności, w jakiej pojawiają się na liście. Na jedną trasę żądania DNS można zapisać maksymalnie osiem adresów IP. Jednak większa liczba serwerów docelowych nie oznacza automatycznie lepszej redundancji, jeśli serwery mają różne statusy stref, różne przekierowania lub różną dostępność przez VPN.

Jeśli istnieje kilka serwerów docelowych, należy nie tylko wprowadzić redundancję, ale także sprawdzić odpowiedzialność. Jeśli pierwszy serwer DNS zna strefę, ale podaje nieaktualne wpisy, trasa żądania będzie technicznie działać i nadal będzie zwracać technicznie niepoprawne odpowiedzi.

NXDOMAIN jest poprawną odpowiedzią z perspektywy DNS. Jeśli pierwszy dostępny serwer DNS powie, że nazwa nie istnieje, zapora sieciowa nie wysyła automatycznie zapytania do następnego serwera w nadziei na inną odpowiedź. Dlatego serwery docelowe powinny mieć ten sam status strefy i te same przekierowania dla tej samej trasy żądań.

Podziel DNS dla VPN i lokalizacji

Podziel DNS oznacza, że ta sama nazwa jest rozpoznawana w różny sposób w zależności od lokalizacji lub sieci. Na przykład portal wewnętrzny może wewnętrznie wskazywać prywatny adres IP, podczas gdy ta sama nazwa jest rozpoznawana zewnętrznie na adres publiczny lub wcale.

W Sophos Firewall kluczowe są trzy punkty:

1. Odpowiednia trasa żądania DNS dla domeny wewnętrznej.
2. Reguła zapory sieciowej, która umożliwia DNS zaporę lub klienta do wewnętrznego serwera DNS.
3. Ścieżka routingu do serwera DNS, szczególnie w przypadku VPN typu site-to-site, SSL VPN lub Sophos Connect.

W przypadku środowisk dostępu zdalnego należy także sprawdzić, które serwery DNS i domeny wyszukiwania otrzymuje klient. Dla Sophos Connect pasuje to do Sophos Connect skonfiguruj na Sophos Firewall. W przypadku klasycznych konfiguracji SSL VPN pasuje Sophos Firewall SSL VPN Skonfiguruj dostęp zdalny.

DNS Protection dodaje dodatkową kwestię projektową: Sophos zaleca skonfigurowanie urządzeń sieciowych tak, aby korzystały z zapory jako resolvera DNS. W tym celu adres IP interfejsu zapory jest zwykle dystrybuowany jako serwer DNS przez serwery DHCP zapory. Jeśli urządzenia nadal korzystają z zewnętrznych resolverów, można zaplanować ukierunkowaną regułę NAT dla wychodzącego ruchu DNS do zapory. Należy to robić świadomie, a nie powszechnie, ponieważ twarde przekierowania DNS mogą mieć wpływ na troubleshooting, urządzenia BYOD, DoH/DoT i urządzenia specjalne.

Jeśli sam firewall używa DNS Protection jako forwardera, adresy IP DNS Protection skopiowane z Sophos Central powinny być wpisane w Network > DNS > DNS configuration jako podstawowy i dodatkowy serwer DNS. Inny trzeci serwer DNS lub niezamierzona ścieżka DNS IPv6 może spowodować, że zapytania ominą DNS Protection. Dlatego DNS Request Routes, opcje DNS DHCP, ustawienia DNS IPv6 i opcjonalne reguły NAT DNS należy sprawdzać jako jeden wspólny projekt.

Odwróć DNS dla sieci wewnętrznych

Trasa żądania zwrotnego DNS przekazuje zapytania PTR dla wewnętrznej sieci IP do serwera DNS, który zna odpowiednią strefę wyszukiwania wstecznego. Pomaga to, gdy dzienniki, raporty lub usługi wymagają ponownej konwersji adresu IP na nazwę hosta.

Przykład:

• Sieć: 172.16.16.0/24
• DNS serwer: 172.16.16.10
• Linia odwrotna: 16.16.172.in-addr.arpa

W przypadku wyszukiwania wstecznego tworzysz także trasę żądania DNS w Network > DNS > DNS request route. Jednakże w Host/domain name nie wpisujesz zwykłej domeny, ale raczej strefę odwrotną.

Przykład dla 172.16.16.0/24:

16.16.172.in-addr.arpa

Kolejność oktetów jest odwrócona. Sieć 172.16.16.0/24 staje się 16.16.172.in-addr.arpa. Ważne: w Host/domain name nie wpisuje się notacji CIDR, takiej jak 172.16.16.0/24, lecz strefę DNS. Wartość powinna więc wyglądać jak nazwa domeny lub strefy odwrotnej, a nie jak swobodny opis.

W przypadku większych sieci strefa odwrotna może być szersza. Przykład: Dla 172.16.0.0/16 będzie to 16.172.in-addr.arpa. Kluczowy jest sposób, w jaki utworzono strefę wyszukiwania wstecznego na wewnętrznym serwerze DNS.

Jeśli na wewnętrznym serwerze DNS nie ma strefy PTR ani rekordów PTR, trasa żądania również nie pomaga. Zapora sieciowa może wysłać żądanie tylko do właściwego serwera DNS, ale nie tworzy odwrotnych wpisów DNS na serwerze DNS.

W przypadku środowisk IPv6 z prefiksem dostawcy powinieneś także wcześnie pomyśleć o DNS. Sposób, w jaki klienci otrzymują swój adres IPv6 i jaką rolę odgrywa reklama routera i DHCPv6, opisano w IPv6 Konfigurowanie delegowania prefiksów na Sophos Firewall.

Testowanie i operacje

Po konfiguracji należy oddzielnie przetestować dostępność protokołu IP, rozdzielczość DNS i klienta DNS. Ułatwia to sprawdzenie, czy problem rzeczywiście leży w trasie żądania.

Testowanie i walidacja

Po konfiguracji powinieneś przetestować rozpoznawanie nazw:

• Czy zapora może rozpoznać nazwę wewnętrzną?
• Czy Network > DNS > Test name lookup działa w przypadku nazwy wewnętrznej i publicznej?
• Czy rozpoznawanie działa w przypadku VPN lub stref użytkownika?
• Czy serwer DNS jest osiągalny poprzez polecenie ping lub protokół TCP/UDP 53?
• Czy w dzienniku DNS lub dzienniku zapory znajdują się wpisy?

Jeśli rozdzielczość nie działa, powinieneś najpierw sprawdzić:

• Czy domena została wpisana poprawnie?
• Czy klient naprawdę używa serwera Sophos Firewall lub prawidłowego DNS?
• Czy reguła zapory sieciowej blokuje DNS?
• Brakuje trasy do serwera DNS?
• Czy serwer DNS odpowiada na żądania z zapory ogniowej?

Przydatny test oddzielający dostępność IP od rozdzielczości DNS:

1. Przetestuj system docelowy za pośrednictwem protokołu IP, na przykład polecenia ping, portu TCP lub aplikacji.
2. Dotrzyj do serwera DNS samodzielnie poprzez IP.
3. Rozwiąż nazwy poprzez oczekiwane źródło DNS.
4. Następnie przetestuj aplikację, używając nazwy.

Jeśli dostęp działa według adresu IP, a nie według nazwy, nacisk jest kładziony na trasę żądania DNS, sufiks DNS, klient DNS lub wyszukiwanie wsteczne. Jeśli dostęp przez IP nie powiedzie się, powinieneś najpierw sprawdzić routing, reguły zapory sieciowej, NAT lub VPN. Przetestuj regułę zapory sieciowej za pomocą Log Viewer, test zasad i Packet Capture i reguła Sophos Firewall nie działa: sprawdź przyczyny pomóż w dokonaniu tego rozróżnienia.

Polecenia testowe dla zapory i klientów

Na Sophos Firewall konsola urządzenia może pomóc w testowaniu DNS z perspektywy zapory sieciowej:

dnslookup server01.firma.local
dnslookup example.com

Na klientach powinieneś także sprawdzić, który program tłumaczący jest aktualnie używany.

Windows:

ipconfig /all
nslookup server01.firma.local
nslookup server01.firma.local <firewall-ip>
Resolve-DnsName server01.firma.local

macOS:

scutil --dns
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

Linux:

resolvectl status
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

<firewall-ip> oznacza adres wewnętrznego interfejsu Sophos Firewall w odpowiedniej sieci. Jeśli zapytanie skierowane do zapory sieciowej działa, ale normalne zapytanie klienta nie, problem zwykle dotyczy DHCP, profilu VPN, sufiksu DNS, lokalnego programu rozpoznawania nazw lub zachowania przeglądarki/System-DNS. Jeśli zapytanie skierowane do zapory również zakończy się niepowodzeniem, następnymi punktami kontrolnymi są: Trasa żądania, Serwer docelowy, Routing lub Reguła zapory.

W przypadku klientów z nowoczesnymi przeglądarkami lub agentami końcowymi powinieneś także sprawdzić, czy DNS-over-HTTPS lub lokalny agent bezpieczeństwa omija normalne zapytanie DNS. Wtedy zapora sieciowa może nie zobaczyć klasycznego żądania DNS na UDP/TCP 53, mimo że konfiguracja sieci wygląda na poprawną.

Zdefiniuj test pozytywny i negatywny

Trasa żądania DNS jest uważana za prawidłowo przetestowaną tylko wtedy, gdy nie tylko żądana nazwa wewnętrzna działa, ale także sprawdzono kontrprzykład. W przeciwnym razie nie jest jasne, czy trasa dokładnie trafia w strefę wewnętrzną, czy też DNS nie została przypadkowo przekierowana zbyt szeroko.

Zwykle wystarczy krótki plan testów:

• Pozytywny test: Wewnętrzna nazwa ze strefy docelowej jest tłumaczona na oczekiwany prywatny adres IP, na przykład server01.ad.firma.local.
• Test negatywny: Nienaruszona domena publiczna nadal działa poprzez zamierzoną ścieżkę domyślną, na przykład globalną DNS, DNS Protection lub wewnętrzną usługę przesyłania dalej.
• Test klienta: Test jest uruchamiany z profilu VLAN, którego dotyczy problem, lub lokalizacji VPN, a nie tylko bezpośrednio na zaporze ogniowej.
• Sprawdzanie dziennika: Dziennik zapory sieciowej, dziennik DNS lub Packet Capture pokazują, że żądanie dotarło do oczekiwanego mechanizmu rozpoznawania nazw.
• Regresja: Po zmianie na VPN, DHCP, DNS Protection lub routing lokalizacji, ten sam test jest powtarzany.

Ten mały negatywny test zapobiega typowym skutkom ubocznym: odpowiedzi na domeny publiczne są udzielane wewnętrznie, DNS Protection jest pomijane, podział DNS działa tylko w niektórych sieciach lub klient VPN w dalszym ciągu korzysta ze starego modułu rozpoznawania nazw.

Kontrola działania

DNS Trasy żądań powinny być jak najbardziej szczegółowe. Trasa dla dokładnej domeny wewnętrznej jest lepsza niż konfiguracja, która jest zbyt szeroka. W przypadku większych środowisk warto mieć przy sobie krótką dokumentację zawierającą domenę, serwer DNS, lokalizację i przeznaczenie, aby można było prześledzić późniejsze zmiany.

Dokumentacja praktyczna:

• Domena lub strefa odwrotna: na przykład ad.firma.local.
• Serwery docelowe: na przykład 10.10.10.10 i 10.10.10.11.
• Cel: na przykład Active Directory DNS dla lokalizacji głównej.
• Sieci, których to dotyczy: na przykład LAN, administrator VPN i lokalizacja w Zurychu.
• Zależności: na przykład VPN typu site-to-site, kontroler domeny i reguła zapory sieciowej dla DNS.
• Test: na przykład server01.ad.firma.local zwraca oczekiwany wewnętrzny adres IP.
• Test negatywny: na przykład example.com w dalszym ciągu korzysta z zamierzonej ścieżki domyślnej.

Rozwiązywanie problemów

Jeśli DNS nie działa, nie powinieneś bezpośrednio zmieniać trasy żądania. Często klient używa innego mechanizmu rozpoznawania nazw, reguła zapory blokuje DNS lub na serwerze docelowym nie istnieje strefa odwrotna.

Typowe błędy

• Nazwa wewnętrzna nie jest rozpoznawana: Często domena jest niepoprawna, na przykład firma.local zamiast ad.firma.local. Sprawdź domenę na trasie żądania i przeszukaj domenę klienta.
• Klient VPN nie rozpoznaje nazw wewnętrznych: Klient może nie używać zapory ogniowej lub niewłaściwego serwera DNS. Sprawdź ustawienia VPN DNS, klienta DNS i regułę zapory.
• Zapora sieciowa nie może połączyć się z serwerem DNS: Prawdopodobnie brakuje trasy, VPN lub reguły zapory. Sprawdź ping, Packet Capture i wyszukaj trasę.
• Zapora sieciowa rozpoznaje zewnętrznie, ale nie wewnętrznie: DNS Sprawdź trasę żądania, serwer docelowy i wyszukaj nazwę testu. Następnie użyj Packet Capture w kierunku wewnętrznego serwera DNS.
• Wyszukiwanie wsteczne nie działa: Brak strefy PTR lub rekordów PTR. Sprawdź strefę wyszukiwania wstecznego na wewnętrznym serwerze DNS.
• Poszczególne lokalizacje dają nieprawidłowe odpowiedzi: Prawdopodobny jest nieprawidłowy serwer docelowy lub nieaktualne dane strefy. Sprawdź kolejność serwerów docelowych i replikację DNS.
• Odpowiedź na nazwy publiczne została nagle wewnętrznie udzielona: Trasa żądania jest zbyt szeroka. Użyj bardziej szczegółowej domeny i unikaj myślenia symbolami wieloznacznymi.
• Pierwszy serwer DNS odpowiada NXDOMAIN: Zapora traktuje tę odpowiedź jako prawidłową i nie wysyła automatycznie zapytań do wszystkich dodatkowych serwerów docelowych. Sprawdź status strefy i kolejność serwerów.
• DNS Protection nie działa dla wszystkich klientów: Sprawdź, czy klienci rzeczywiście używają firewalla jako resolvera DNS, czy nie przeszkadzają zewnętrzne resolvery, DoH/DoT, lokalni agenci lub ręczne ustawienia DNS.

W środowiskach VPN powinieneś także sprawdzić, czy klienci VPN otrzymują prawidłowe serwery DNS i domeny wyszukiwania.

Często zadawane pytania