Konfigurowanie tras żądań DNS na Sophos Firewall

Za pomocą tras żądań DNS można na Sophos Firewall określić, który serwer DNS ma być używany dla określonych domen lub sieci. Jest to szczególnie przydatne, gdy firewall korzysta z publicznych serwerów DNS, ale wewnętrzne nazwy muszą być rozwiązywane przez wewnętrzny serwer DNS.

Typowe przykłady to domeny Active Directory, aplikacje wewnętrzne, odwrotne wyszukiwania lub środowiska VPN.

Gdy używana jest Sophos DNS Protection z Sophos Firewall, trasy żądań DNS stają się jeszcze ważniejsze. Publiczne domeny są wtedy kierowane do usługi DNS Protection, ale domeny wewnętrzne nadal do lokalnego serwera DNS lub kontrolera domeny. Bez tego rozdzielenia wewnętrzne aplikacje, logowania AD lub odwrotne wyszukiwania mogą nagle wyglądać jak problemy z siecią.

Orientacja i projekt

DNS Request Routes mają sens tylko wtedy, gdy oczekiwane zachowanie DNS i odpowiedzialne serwery DNS są jasno zdefiniowane.

Trasa żądania DNS, serwer DNS czy opcja DHCP?

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

• Globalne serwery DNS: Standardowe rozwiązywanie nazw przez firewall Internet-DNS, ogólne rozwiązywanie FQDN, aktualizacje i usługi w chmurze.
• Trasa żądania DNS: wysyłanie określonej domeny lub strefy odwrotnej do zdefiniowanego serwera DNS Active Directory, domeny wewnętrzne, DNS lokalizacji, Split DNS.
• Opcja DHCP: rozdzielanie serwerów DNS lub domen wyszukiwania do klientów Klienci powinni bezpośrednio używać określonego serwera DNS.

Trasa żądania DNS nie zmienia automatycznie konfiguracji DNS wszystkich klientów. Trasa kontroluje, dokąd Sophos Firewall sam lub klienci, którzy używają firewalla jako forwardera DNS, przekierowują określone zapytania DNS. Jeśli klienci mają bezpośrednio używać wewnętrznego serwera DNS, bardziej odpowiednia jest opcja DHCP na Sophos Firewall.

Jakie podejście do DNS jest odpowiednie?

Przed utworzeniem trasy żądania DNS powinno być jasne, który resolver jest używany w danej sieci. Trasa pomaga tylko wtedy, gdy Sophos Firewall widzi zapytanie.

• Klienci pytają Sophos Firewall: Firewall przekierowuje publiczne domeny globalnie, a wewnętrzne domeny przez trasę żądania DNS małe i średnie lokalizacje, DNS Protection, sieci gości/klientów.
• Klienci pytają bezpośrednio wewnętrzne serwery DNS: Kontroler domeny lub serwer DNS rozwiązuje wewnętrznie i przekierowuje zewnętrznie klasyczne sieci Active Directory z Windows-DNS jako centralnym resolverem.
• Klienci VPN pytają firewall: Firewall używa tras żądań dla wewnętrznych domen Zdalny dostęp z prostą ścieżką DNS przez firewall.
• Klienci VPN pytają bezpośrednio wewnętrzne serwery DNS: DNS działa przez VPN do kontrolera domeny lub serwera DNS większe środowiska AD, gdy klienci mają używać tej samej logiki DNS co w LAN.

W mieszanych środowiskach bardzo pomocna jest krótka szkic DNS: sieć klientów, przypisany serwer DNS, domena wyszukiwania, wewnętrzne strefy DNS, trasy żądań DNS i ścieżka routingu do serwera docelowego. Bez tego przeglądu często pracuje się nad trasą żądania, mimo że klient nie używa firewalla jako resolvera DNS.

Kiedy potrzebne są trasy żądań DNS?

Trasy żądań DNS są przydatne, gdy:

• trzeba rozwiązać wewnętrzne nazwy hostów, takie jak server01.firma.local
• odwrotne wyszukiwania dla wewnętrznych sieci IP mają działać
• użytkownicy VPN mają używać wewnętrznych nazw
• wiele lokalizacji ma własne strefy DNS
• firewall sam musi osiągnąć wewnętrzne systemy przez FQDN
• publiczne serwery DNS nie znają wewnętrznych nazw

Bez trasy żądania DNS firewall pyta globalnie skonfigurowany serwer DNS. Jeśli wewnętrzna domena nie jest tam znana, rozwiązywanie nazw kończy się niepowodzeniem.

Szczególnie ważna jest ta różnica przy zdalnym dostępie. Jeśli klienci VPN używają firewalla jako serwera DNS, trasa żądania DNS może zapewnić, że wewnętrzne domeny trafią do odpowiedniego kontrolera domeny lub serwera DNS. Jeśli klienci VPN otrzymują bezpośrednio wewnętrzne serwery DNS, należy dodatkowo sprawdzić, czy routing, zasady firewalla i sufiksy DNS na kliencie są poprawne.

Wymagania

• Dostęp do WebAdmin Sophos Firewall
• Wewnętrzny serwer DNS jest osiągalny
• Domena lub sieć jest znana
• Zasady firewalla pozwalają na ruch DNS do serwera docelowego
• Przy połączeniach lokalizacyjnych: routing do serwera DNS działa
• Dotknięty klient używa albo firewalla jako serwera DNS, albo świadomie otrzymuje inny serwer DNS

⚠️ Problemy z DNS często wyglądają jak problemy z routingiem, VPN lub aplikacjami. Przed większymi zmianami należy sprawdzić, czy serwer docelowy jest osiągalny przez IP i czy tylko rozwiązywanie nazw kończy się niepowodzeniem.

Konfiguracja DNS Request Route

Route określa, które serwery DNS są odpytywane dla konkretnej domeny lub strefy reverse.

Tworzenie trasy żądania DNS dla domeny

Trasa domeny zapewnia, że zapytania dla określonej domeny są wysyłane do zdefiniowanego serwera DNS.

Przykład:

• Nazwa hosta/domeny: firma.local
• Serwer DNS: 10.10.10.10

Procedura:

1. Zaloguj się do Sophos Firewall.
2. Otwórz Network.
3. Wybierz DNS.
4. Przejdź do sekcji DNS request route.
5. Dodaj nową trasę żądania DNS.
6. W polu Host/domain name wpisz wewnętrzną domenę, na przykład firma.local.
7. W polu Target servers wybierz wewnętrzny serwer DNS lub utwórz go jako host za pomocą Create.
8. Zapisz.

Po tym firewall będzie pytał o tę domenę wskazany serwer DNS.

Używanie wielu serwerów docelowych

W sekcji Target servers można dodać więcej niż jeden serwer DNS. Jest to przydatne, gdy istnieje wiele wewnętrznych serwerów DNS lub gdy DNS ma być redundantnie osiągalny przez połączenie lokalizacyjne.

Możliwe serwery docelowe:

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

Kolejność ma znaczenie. Firewall pyta wybrane hosty w kolejności, w jakiej są na liście. Dla każdej trasy żądania DNS można podać do ośmiu adresów IP. Więcej serwerów docelowych nie oznacza automatycznie lepszej redundancji, jeśli serwery mają różne stany stref, różne przekierowania lub różną osiągalność przez VPN.

Przy wielu serwerach docelowych nie tylko należy wpisać redundancję, ale także sprawdzić odpowiedzialność. Jeśli pierwszy serwer DNS zna strefę, ale dostarcza przestarzałe wpisy, trasa żądania będzie technicznie działać, ale merytorycznie nadal zwróci błędne odpowiedzi.

Split DNS dla VPN i lokalizacji

Split DNS oznacza, że ta sama nazwa jest rozwiązywana różnie w zależności od lokalizacji lub sieci. Wewnętrzny portal może na przykład wskazywać na prywatny adres IP wewnętrznie, podczas gdy ta sama nazwa zewnętrznie wskazuje na publiczny adres lub w ogóle nie jest rozwiązywana.

Na Sophos Firewall kluczowe są trzy punkty:

1. Odpowiednia trasa żądania DNS dla wewnętrznej domeny.
2. Zasada firewalla, która pozwala na DNS z firewalla lub klienta do wewnętrznego serwera DNS.
3. Ścieżka routingu do serwera DNS, szczególnie przy Site-to-Site VPN, SSL VPN lub Sophos Connect.

Dla środowisk zdalnego dostępu należy dodatkowo sprawdzić, jakie serwery DNS i domeny wyszukiwania otrzymuje klient. Dla Sophos Connect pasuje Konfigurowanie Sophos Connect na Sophos Firewall. Dla klasycznych konfiguracji SSL-VPN pasuje Konfigurowanie zdalnego dostępu SSL VPN na Sophos Firewall.

Odwrotne DNS dla wewnętrznych sieci

Trasa żądania odwrotnego DNS przekierowuje zapytania PTR dla wewnętrznej sieci IP do serwera DNS, który zna odpowiednią strefę odwrotnego wyszukiwania. Pomaga to, gdy logi, raporty lub usługi mają z adresu IP ponownie zrobić nazwę hosta.

Przykład:

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

Dla odwrotnych wyszukiwań również tworzy się trasę żądania DNS w sekcji Network > DNS > DNS request route. W polu Host/domain name wpisuje się jednak nie normalną domenę, ale strefę odwrotną.

Przykład dla 172.16.16.0/24:

16.16.172.in-addr.arpa

Kolejność oktetów jest odwrócona. Z sieci 172.16.16.0/24 powstaje 16.16.172.in-addr.arpa.

Dla większych sieci strefa odwrotna może być szersza. Przykład: Dla 172.16.0.0/16 byłoby to 16.172.in-addr.arpa. Kluczowe jest, jak strefa odwrotnego wyszukiwania została utworzona na wewnętrznym serwerze DNS.

Jeśli na wewnętrznym serwerze DNS nie istnieje strefa PTR lub rekordy PTR, trasa żądania również nie pomoże. Firewall może tylko wysłać zapytanie do właściwego serwera DNS, ale nie tworzy wpisów odwrotnego DNS na serwerze DNS.

W środowiskach IPv6 z prefiksem dostawcy również należy wcześnie pomyśleć o DNS. Jak klienci otrzymują swój adres IPv6 i jaką rolę odgrywają Router Advertisement i DHCPv6, opisano w Konfigurowanie delegacji prefiksu IPv6 na Sophos Firewall.

Testy i eksploatacja

Zmiany DNS należy zawsze weryfikować z poziomu firewalla oraz z rzeczywistych klientów.

Testy i walidacja

Po konfiguracji należy przetestować rozwiązywanie nazw:

• Czy firewall może rozwiązać wewnętrzną nazwę?
• Czy rozwiązywanie działa z VPN lub stref użytkowników?
• Czy serwer DNS jest osiągalny przez Ping lub TCP/UDP 53?
• Czy są wpisy w logu DNS lub firewalla?

Jeśli rozwiązywanie nie działa, najpierw należy sprawdzić:

• Czy domena jest poprawnie napisana?
• Czy klient naprawdę używa Sophos Firewall lub właściwego serwera DNS?
• Czy zasada firewalla blokuje DNS?
• Czy brakuje trasy do serwera DNS?
• Czy serwer DNS odpowiada na zapytania z firewalla?

Sensowny test oddziela osiągalność IP od rozwiązywania DNS:

1. Testuj system docelowy przez IP, na przykład Ping, port TCP lub aplikację.
2. Osiągnij serwer DNS sam przez IP.
3. Rozwiąż nazwę przez oczekiwane źródło DNS.
4. Dopiero potem przetestuj aplikację przez nazwę.

Jeśli dostęp przez IP działa, ale przez nazwę nie, problem leży w trasie żądania DNS, sufiksie DNS, kliencie DNS lub odwrotnym wyszukiwaniu. Jeśli dostęp przez IP już się nie udaje, najpierw należy sprawdzić routing, zasady firewalla, NAT lub VPN. Do tego rozróżnienia pomagają Testowanie zasady firewalla za pomocą Log Viewer, Policy Test i Packet Capture i Sprawdzanie przyczyn, gdy zasada Sophos Firewall nie działa.

Polecenia testowe dla firewalla i klientów

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

dnslookup server01.firma.local
dnslookup example.com

Na klientach należy dodatkowo sprawdzić, który resolver jest naprawdę 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 wewnętrzny adres interfejsu Sophos Firewall w danej sieci. Jeśli zapytanie do firewalla działa, ale normalne zapytanie klienta nie, problem zazwyczaj leży w DHCP, profilu VPN, sufiksie DNS, lokalnym resolverze lub zachowaniu DNS przeglądarki/systemu. Jeśli również zapytanie do firewalla się nie udaje, kolejnymi punktami do sprawdzenia są trasa żądania, serwer docelowy, routing lub zasada firewalla.

Zdefiniuj test pozytywny i negatywny

DNS Request Route jest poprawnie przetestowana dopiero wtedy, gdy działa nie tylko oczekiwana nazwa wewnętrzna, ale sprawdzono też przykład przeciwny. W przeciwnym razie nie wiadomo, czy trasa trafia dokładnie w wewnętrzną strefę, czy DNS jest przekierowywany zbyt szeroko.

Zwykle wystarczy krótki plan testów:

• Test pozytywny: wewnętrzna nazwa ze strefy docelowej rozwiązuje się na oczekiwany prywatny adres IP, na przykład server01.ad.firma.local.
• Test negatywny: nieobjęta domena publiczna nadal korzysta z przewidzianej ścieżki domyślnej, na przykład globalnego DNS, DNS Protection albo wewnętrznego forwardera.
• Test klienta: wykonaj test z objętego VLAN, profilu VPN lub lokalizacji, nie tylko bezpośrednio na firewallu.
• Sprawdzenie logów: firewall log, DNS log lub Packet Capture pokazuje, że zapytanie dociera do oczekiwanego resolvera.
• Regresja: powtórz ten sam test po zmianie VPN, DHCP, DNS Protection lub routingu lokalizacji.

Ten mały test negatywny zapobiega typowym skutkom ubocznym: domeny publiczne są rozwiązywane wewnętrznie, DNS Protection jest omijany, Split-DNS działa tylko z niektórych sieci albo klient VPN nadal używa starego resolvera.

Kontrola operacyjna

Trasy żądań DNS powinny być możliwie specyficzne. Trasa dla dokładnej wewnętrznej domeny jest lepsza niż zbyt szeroka konfiguracja. Dla większych środowisk warto stworzyć małą tabelę z domeną, serwerem DNS, lokalizacją i celem, aby późniejsze zmiany były śledzone.

Praktyczna dokumentacja:

• Domena lub strefa odwrotna: ad.firma.local
• Serwery docelowe: 10.10.10.10, 10.10.10.11
• Cel: DNS Active Directory dla głównej lokalizacji.
• Dotknięte sieci: LAN, Admin-VPN, lokalizacja Zurych.
• Zależności: Site-to-Site VPN, kontroler domeny, zasada firewalla DNS.
• Test: server01.ad.firma.local rozwiązuje się na oczekiwany wewnętrzny adres IP.
• Test negatywny: na przykład example.com nadal korzysta z przewidzianej ścieżki domyślnej.

Troubleshooting

Jeśli brakuje oczekiwanego efektu, należy krok po kroku sprawdzić logi, rule matching i zachowanie policy.

Typowe błędy

• Wewnętrzna nazwa się nie rozwiązuje: błędna domena, na przykład firma.local zamiast ad.firma.local Sprawdź domenę w trasie żądania i domenę wyszukiwania klienta.
• Klient VPN nie rozwiązuje wewnętrznych nazw: Klient nie używa firewalla lub niewłaściwego serwera DNS Sprawdź ustawienia DNS VPN, DNS klienta i zasady firewalla.
• Firewall nie może osiągnąć serwera DNS: Brak trasy, VPN lub zasady firewalla Sprawdź Ping, Packet Capture i Route Lookup.
• Odwrotne wyszukiwanie nie działa: Brak strefy PTR lub rekordów PTR Sprawdź strefę odwrotnego wyszukiwania na wewnętrznym serwerze DNS.
• Pojedyncze lokalizacje dostarczają błędne odpowiedzi: błędny serwer docelowy lub przestarzałe dane strefy Sprawdź kolejność serwerów docelowych i replikację DNS.
• Publiczne nazwy są nagle rozwiązywane wewnętrznie: Trasa żądania jest zbyt szeroka Użyj bardziej specyficznej domeny i unikaj myślenia o wildcardach.

W środowiskach VPN należy dodatkowo sprawdzić, czy klienci VPN otrzymują właściwe serwery DNS i domeny wyszukiwania.

FAQ