Configurare le rotte delle richieste DNS su Sophos Firewall

Con le rotte delle richieste DNS è possibile specificare su Sophos Firewall quale server DNS utilizzare per determinati domini o reti. Questo è particolarmente utile quando il firewall utilizza server DNS pubblici, ma i nomi interni devono essere risolti tramite un server DNS interno.

Esempi tipici sono domini Active Directory, applicazioni interne, reverse lookup o ambienti VPN.

Quando si utilizza Sophos DNS Protection con Sophos Firewall, le rotte delle richieste DNS diventano ancora più importanti. I domini pubblici vengono inviati al servizio DNS Protection, mentre i domini interni continuano a essere risolti dal server DNS locale o dal Domain Controller. Senza questa separazione, le applicazioni interne, le autenticazioni AD o i reverse lookup possono sembrare problemi di rete.

Orientamento e design

Le DNS Request Routes hanno senso solo quando il comportamento DNS desiderato e i server DNS responsabili sono definiti chiaramente.

Rotta delle richieste DNS, server DNS o opzione DHCP?

Le rotte delle richieste DNS sono spesso confuse con server DNS globali o opzioni DHCP. Le funzioni risolvono problemi diversi.

Server DNS globali: Risoluzione standard del firewall DNS Internet, risoluzione FQDN generale, aggiornamenti e servizi cloud.
Rotta delle richieste DNS: inviare un dominio specifico o una zona di reverse a un server DNS definito Active Directory, domini interni, DNS di sede, Split DNS.
Opzione DHCP: distribuire server DNS o dominio di ricerca ai client i client devono utilizzare direttamente un server DNS specifico.

Una rotta delle richieste DNS non modifica automaticamente la configurazione DNS di tutti i client. La rotta controlla dove la Sophos Firewall stessa o i client che utilizzano il firewall come DNS forwarder inoltrano determinate richieste DNS. Se i client devono utilizzare direttamente un server DNS interno, è più adatta un’opzione DHCP su Sophos Firewall.

Quale design DNS è adatto?

Prima di creare una rotta delle richieste DNS, è importante sapere quale resolver viene utilizzato nella rete specifica. La rotta è utile solo se la Sophos Firewall vede la richiesta.

I client interrogano la Sophos Firewall: Il firewall inoltra i domini pubblici globalmente e i domini interni tramite rotta delle richieste DNS sedi piccole e medie, DNS Protection, reti guest/client.
I client interrogano direttamente i server DNS interni: Il Domain Controller o il server DNS risolvono internamente e inoltrano esternamente reti classiche Active Directory con Windows DNS come resolver centrale.
I client VPN interrogano il firewall: Il firewall utilizza le rotte delle richieste per i domini interni Accesso remoto con percorso DNS semplice tramite il firewall.
I client VPN interrogano direttamente i server DNS interni: Il DNS passa tramite VPN al Domain Controller o al server DNS ambienti AD più grandi, quando i client devono utilizzare la stessa logica DNS del LAN.

In ambienti misti, uno schema DNS breve è molto utile: rete client, server DNS assegnato, dominio di ricerca, zone DNS interne, rotte delle richieste DNS e percorso di routing al server di destinazione. Senza questa panoramica, spesso si lavora sulla rotta delle richieste anche se il client non utilizza affatto il firewall come resolver DNS.

Quando sono necessarie le rotte delle richieste DNS?

Le rotte delle richieste DNS sono utili quando:

devono essere risolti nomi host interni come server01.firma.local
devono funzionare i reverse lookup per reti IP interne
gli utenti VPN devono utilizzare nomi interni
più sedi hanno proprie zone DNS
il firewall stesso deve raggiungere sistemi interni tramite FQDN
i server DNS pubblici non conoscono nomi interni

Senza una rotta delle richieste DNS, il firewall interroga il server DNS configurato globalmente. Se il dominio interno non è noto lì, la risoluzione fallisce.

Questa differenza è particolarmente importante per l’accesso remoto. Se i client VPN utilizzano il firewall come server DNS, una rotta delle richieste DNS può garantire che i domini interni finiscano comunque nel giusto Domain Controller o server DNS. Se invece i client VPN ricevono direttamente server DNS interni, è necessario verificare anche che il routing, le regole del firewall e i suffissi DNS sul client siano corretti.

Prerequisiti

Accesso al WebAdmin di Sophos Firewall
Il server DNS interno è raggiungibile
Il dominio o la rete è noto
Le regole del firewall consentono il traffico DNS al server di destinazione
In caso di collegamento tra sedi: il routing al server DNS funziona
Il client interessato utilizza il firewall come server DNS o riceve consapevolmente un altro server DNS

⚠️ I problemi DNS spesso sembrano problemi di routing, VPN o applicazioni. Prima di apportare modifiche significative, è consigliabile verificare se il server di destinazione è raggiungibile tramite IP e se solo la risoluzione dei nomi fallisce.

Configurare una DNS Request Route

La route definisce quali server DNS vengono interrogati per un dominio o una zona reverse specifica.

Creare una rotta delle richieste DNS per un dominio

Una rotta di dominio garantisce che le richieste per un dominio specifico vengano inviate a un server DNS definito.

Esempio:

Nome host/dominio: firma.local
Server DNS: 10.10.10.10

Procedura:

Accedere a Sophos Firewall.
Aprire Network.
Selezionare DNS.
Passare alla sezione DNS request route.
Aggiungere una nuova rotta delle richieste DNS.
In Host/domain name inserire il dominio interno, ad esempio firma.local.
In Target servers selezionare il server DNS interno o crearlo come host tramite Create.
Salvare.

Dopo di che, il firewall interrogherà il server DNS specificato per questo dominio.

Sophos Firewall - Aggiungi rotta richiesta DNS con server DNS interno — Sophos Firewall - Network > DNS > Aggiungi rotta richiesta DNS

Utilizzare più server di destinazione

In Target servers è possibile aggiungere più di un server DNS. Questo è utile se ci sono più server DNS interni o se il DNS deve essere raggiungibile in modo ridondante tramite una connessione tra sedi.

Possibili server di destinazione:

server DNS interni nella rete locale
server DNS dall’altra parte di una connessione VPN
server DNS in un’altra sede
server DNS pubblici, se un dominio specifico deve essere risolto esternamente

L’ordine è rilevante. Il firewall interroga gli host selezionati nell’ordine in cui appaiono nella lista. Per ogni rotta delle richieste DNS possono essere memorizzati fino a otto indirizzi IP. Tuttavia, più server di destinazione non significano automaticamente una migliore ridondanza, se i server hanno stati di zona diversi, inoltri diversi o raggiungibilità diversa tramite VPN.

Sophos Firewall - Panoramica di una rotta delle richieste DNS per avanet.local — Sophos Firewall - Network > DNS > Rotta delle richieste DNS

Con più server di destinazione, non solo si dovrebbe inserire la ridondanza, ma anche verificare la responsabilità. Se il primo server DNS conosce la zona ma fornisce voci obsolete, la rotta delle richieste funzionerà tecnicamente ma fornirà comunque risposte errate dal punto di vista funzionale.

Split DNS per VPN e sedi

Lo Split DNS significa che lo stesso nome viene risolto in modo diverso a seconda della sede o della rete. Un portale interno può, ad esempio, puntare a un IP privato internamente, mentre lo stesso nome esternamente punta a un indirizzo pubblico o non viene risolto affatto.

Su Sophos Firewall, tre punti sono cruciali:

La rotta delle richieste DNS appropriata per il dominio interno.
Una regola del firewall che consente il DNS dal firewall o dal client al server DNS interno.
Un percorso di routing al server DNS, specialmente in caso di VPN site-to-site, SSL VPN o Sophos Connect.

Per ambienti di accesso remoto, è inoltre necessario verificare quali server DNS e domini di ricerca riceve il client. Per Sophos Connect, si adatta Configurare Sophos Connect su Sophos Firewall. Per configurazioni SSL VPN classiche, si adatta Configurare l’accesso remoto SSL VPN su Sophos Firewall.

Reverse DNS per reti interne

Una rotta delle richieste DNS inversa inoltra le richieste PTR per una rete IP interna al server DNS che conosce la zona di reverse lookup appropriata. Questo è utile quando log, report o servizi devono trasformare un indirizzo IP in un nome host.

Esempio:

Rete: 172.16.16.0/24
Server DNS: 172.16.16.10
Zona inversa: 16.16.172.in-addr.arpa

Per i reverse lookup, si crea anche una rotta delle richieste DNS sotto Network > DNS > DNS request route. In Host/domain name non si inserisce il dominio normale, ma la zona inversa.

Esempio per 172.16.16.0/24:

16.16.172.in-addr.arpa

L’ordine degli ottetti è invertito. Dalla rete 172.16.16.0/24 diventa 16.16.172.in-addr.arpa.

Per reti più grandi, la zona inversa può essere più ampia. Esempio: Per 172.16.0.0/16 sarebbe 16.172.in-addr.arpa. È fondamentale come è stata creata la zona di reverse lookup sul server DNS interno.

Se sul server DNS interno non esiste una zona PTR o record PTR, la rotta delle richieste non aiuta. Il firewall può solo inviare la richiesta al server DNS corretto, ma non genera voci DNS inverse sul server DNS.

In ambienti IPv6 con prefisso del provider, è importante considerare anche il DNS in anticipo. Come i client ottengono il loro indirizzo IPv6 e quale ruolo giocano Router Advertisement e DHCPv6 è spiegato in Configurare la delega del prefisso IPv6 su Sophos Firewall.

Test e operatività

Le modifiche DNS devono sempre essere verificate dalla firewall e da client reali.

Test e validazione

Dopo la configurazione, è consigliabile testare la risoluzione dei nomi:

Il firewall può risolvere il nome interno?
La risoluzione funziona dalle zone VPN o utente?
Il server DNS è raggiungibile tramite Ping o TCP/UDP 53?
Ci sono voci nel log DNS o del firewall?

Se la risoluzione non funziona, è consigliabile verificare prima:

Il dominio è scritto correttamente?
Il client utilizza davvero Sophos Firewall o il server DNS corretto?
Una regola del firewall blocca il DNS?
Manca una rotta al server DNS?
Il server DNS risponde alle richieste dal firewall?

Un test sensato separa la raggiungibilità IP e la risoluzione DNS:

Testare il sistema di destinazione tramite IP, ad esempio Ping, porta TCP o applicazione.
Raggiungere il server DNS stesso tramite IP.
Risolvere il nome tramite la fonte DNS prevista.
Solo successivamente testare l’applicazione tramite il nome.

Se l’accesso tramite IP funziona, ma tramite nome no, il focus è su rotta delle richieste DNS, suffisso DNS, DNS client o reverse lookup. Se l’accesso tramite IP fallisce già, è consigliabile verificare prima routing, regola del firewall, NAT o VPN. Per questa delimitazione, aiutano Testare la regola del firewall con Log Viewer, Policy Test e Packet Capture e Verificare le cause per cui la regola di Sophos Firewall non si applica.

Comandi di test per firewall e client

Su Sophos Firewall, la Device Console può aiutare a testare il DNS dal punto di vista del firewall:

dnslookup server01.firma.local
dnslookup example.com

Sui client, è consigliabile verificare anche quale resolver viene effettivamente utilizzato.

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> rappresenta l’indirizzo dell’interfaccia interna di Sophos Firewall nella rete specifica. Se la richiesta contro il firewall funziona, ma la normale richiesta del client no, il problema è solitamente DHCP, profilo VPN, suffisso DNS, resolver locale o comportamento DNS del browser/sistema. Se anche la richiesta contro il firewall fallisce, i prossimi punti di controllo sono rotta delle richieste, server di destinazione, routing o regola del firewall.

Definire test positivi e negativi

Una DNS Request Route è testata correttamente solo quando funziona il nome interno desiderato e viene verificato anche un controesempio. Altrimenti non è chiaro se la route intercetta esattamente la zona interna o se il DNS viene reindirizzato in modo troppo ampio.

Di solito basta un breve piano di test:

Test positivo: un nome interno della zona di destinazione risolve l’IP privata attesa, ad esempio server01.ad.firma.local.
Test negativo: un dominio pubblico non coinvolto continua a usare il percorso standard previsto, ad esempio DNS globale, DNS Protection o forwarder interno.
Test client: eseguire il test dal VLAN, profilo VPN o sito interessato, non solo direttamente sulla firewall.
Controllo log: firewall log, DNS log o Packet Capture mostrano che la query raggiunge il resolver previsto.
Regression: ripetere lo stesso test dopo modifiche a VPN, DHCP, DNS Protection o routing del sito.

Questo piccolo test negativo evita effetti collaterali tipici: domini pubblici risposti internamente, DNS Protection aggirata, Split-DNS funzionante solo da alcune reti o client VPN che usa ancora un vecchio resolver.

Controllo operativo

Le rotte delle richieste DNS dovrebbero essere il più specifiche possibile. Una rotta per il dominio interno esatto è migliore di una configurazione troppo ampia. Per ambienti più grandi, vale la pena mantenere una piccola tabella con dominio, server DNS, sede e scopo, in modo che le modifiche successive siano tracciabili.

Documentazione pratica:

Dominio o zona inversa: ad.firma.local
Server di destinazione: 10.10.10.10, 10.10.10.11
Scopo: DNS Active Directory per sede principale.
Reti interessate: LAN, Admin-VPN, sede di Zurigo.
Dipendenze: VPN site-to-site, Domain Controller, regola del firewall DNS.
Test: server01.ad.firma.local si risolve sull’IP interno previsto.
Test negativo: ad esempio, example.com continua a usare il percorso standard previsto.

Troubleshooting

Se il risultato atteso manca, si controllano passo per passo logging, rule matching e comportamento delle policy.

Errori tipici

Il nome interno non si risolve: dominio errato, ad esempio firma.local invece di ad.firma.local Verificare il dominio nella rotta delle richieste e il dominio di ricerca del client.
Il client VPN non risolve i nomi interni: Il client non utilizza il firewall o il server DNS errato Verificare le impostazioni DNS VPN, DNS client e regola del firewall.
Il firewall non può raggiungere il server DNS: Manca una rotta, VPN o regola del firewall Verificare Ping, Packet Capture e Route Lookup.
Il reverse lookup non funziona: Mancano zona PTR o record PTR Verificare la zona di reverse lookup sul server DNS interno.
Singole sedi forniscono risposte errate: Server di destinazione errato o dati di zona obsoleti Verificare l’ordine dei server di destinazione e la replica DNS.
I nomi pubblici vengono improvvisamente risolti internamente: La rotta delle richieste è troppo ampia Utilizzare un dominio più specifico ed evitare il pensiero wildcard.

In ambienti VPN, è consigliabile verificare anche se i client VPN ricevono i server DNS e i domini di ricerca corretti.

FAQ

Quando è necessaria una rotta delle richieste DNS su Sophos Firewall?

Una rotta delle richieste DNS è utile quando determinati domini o zone inverse non devono essere risolti tramite i server DNS globali del firewall, ma tramite server DNS interni. Casi tipici sono Active Directory, applicazioni interne, VPN e collegamenti tra sedi.

Una rotta delle richieste DNS sostituisce le opzioni DHCP-DNS?

No. Una rotta delle richieste DNS controlla l’inoltro di specifiche richieste DNS. Le opzioni DHCP distribuiscono invece server DNS o domini di ricerca ai client. A seconda del design, entrambe le funzioni vengono combinate.

Perché il DNS non funziona tramite VPN anche se esiste la rotta delle richieste?

In tal caso, il client VPN potrebbe non utilizzare la fonte DNS prevista, non avere un dominio di ricerca appropriato, non raggiungere il server DNS o essere bloccato da routing e regole del firewall. È consigliabile verificare separatamente se l’accesso tramite IP funziona e se la richiesta DNS arriva davvero al server corretto.

Sono necessarie le rotte delle richieste DNS per i reverse lookup?

Sì, se le richieste PTR per reti interne devono andare a un server DNS interno. Per questo, la zona in-addr.arpa appropriata viene inserita come nome host/dominio. Tuttavia, la zona deve essere presente sul server DNS interno.

Sono necessarie le rotte delle richieste DNS con Sophos DNS Protection?

Sì, se i client o il firewall devono risolvere domini interni. DNS Protection non conosce le zone AD locali, i domini delle applicazioni interne e le zone inverse. Queste richieste dovrebbero essere inviate tramite rotta delle richieste DNS a server DNS interni.

Perché il firewall non vede la richiesta DNS?

Di solito, il client non utilizza Sophos Firewall come server DNS. In tal caso, le rotte delle richieste DNS sul firewall non aiutano direttamente. È consigliabile verificare le opzioni DHCP, il profilo VPN, le impostazioni DNS manuali del client, i forwarder DNS interni e i resolver alternativi.