Функционал инспектирования DNS doctoring позволяет устройству безопасности ASA перезаписывать (rewrite) DNS A-записи и PTR-записи.
DNS Rewrite выполняет две функции:
- Транслирует публичные адреса в DNS ответах в приватные адреса, когда DNS клиент находиться на приватном интерфейсе
- Транслирует приватный адрес в публичный адрес, когда DNS клиент находиться на публичном интерфейсе
В типичном DNS обмене, клиент посылает URL или имя хоста на сервер DNS, для того, чтобы определить IP адрес искомого хоста. DNS сервер принимает запрос, ищет соответственные IP адрес – hostname для данного хоста и затем предоставляет клиенту A-запись , содержащую IP адрес искомого хоста. Во многих ситуациях данная процедура работает достаточно хорошо, однако могут возникнуть проблемы. Например, могут происходить разного рода неожиданности, когда клиент и хост, которого клиент пытается достичь, находятся в приватной сети за NAT, а DNS сервер используемый клиентом находиться во внешней сети.
Функционал DNS doctoring работает только, если у вас включено инспектирование протокола DNS
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
!
service-policy global_policy global
Рассмотрим топологию на рисунке. ASA подключена тремя интерфейсами к трем сегментам: внутренний inside, внешний outside и сегмент серверов DMZ
DNS Сервер, который используют клиенты на сегментах inside и outside расположен во внешней сети outside. Для Web сервера 192.168.1.91 определена статическая трансляция в публичный адрес 136.1.121.91 и заведена DNS запись вида web.lab.local – 136.1.121.91. Внешние хосты без проблем могут резолвить web-сервер по имени и получить к нему доступ.

Но и клиенты на локальной сети 10.0.0.0/24 также хотят получить доступ к web-серверу, используя его URL web.lab.local. DNS сервис для клиентов также обеспечивается внешним DNS сервером 136.1.121.100. Поскольку DNS сервер расположен в публичной сети, он не знает приватного IP адреса Web-сервера 192.168.1.91. Взамен он знает только его публичный адрес 136.1.121.91
Исходная конфигурация ASA:
hostname ASAv1
!
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 136.1.121.21 255.255.255.0
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.0.0.21 255.255.255.0
!
interface GigabitEthernet0/2
nameif dmz
security-level 50
ip address 192.168.1.21 255.255.255.0
!
object network LAN
subnet 10.0.0.0 255.255.255.0
nat (inside,outside) dynamic interface
!
object network DMZ_WEBHOST
host 192.168.1.91
nat (dmz,outside) static 136.1.121.91
!
access-list ACL_OUTSIDE extended permit ip any any
access-group ACL_OUTSIDE in interface outside
!
route outside 0.0.0.0 0.0.0.0 136.1.121.2
Проблема: Клиент на inside не может получить доступ к Web-серверу.
Без DNS Doctoring или иного решения применимого в данной ситуации, если клиент посылает DNS запрос для получения IP адреса по имени web.lab.local , он не сможет получить доступ к web-серверу. Это происходит из-за того, что клиент получает A-запись содержащую публичный транслированный адрес 136.1.121.91 web-сервера. Когда клиент пытается получить доступ на данный адрес, ASA дропает пакеты.

Посмотрим на дамп трафика снятого с inside и outside интерфейсов ASA:
1. Клиент посылает DNS запрос к серверу 136.1.121.100
2. ASA выполняет PAT над IP адресами в пакете и запрос перенаправляется к DNS серверу. IP адрес источника в пакете был транслирован в IP адрес внешнего интерфейса ASA
3. DNS сервер ответил транслированным адресом Web-сервера 136.1.121.91
4. ASA выполнила процедуру реверсной трансляции над адресом назначения пакета содержащего DNS ответ и перенаправлила его клиенту. Клиент получил DNS ответ, содержащий транслированный адрес web-сервера 136.1.121.91
5. В этой точке клиент пытается обратиться в web-серверу по адресу TCP 136.1.121.91:80. ASA создает TCP соединение для этой коммуникации. Однако, поскольку она не разрешает прохождение трафика от inside в строну outside и в строну dmz, клиент получает timeout . ASA пишет в логах
%ASA-6-302013: Built outbound TCP connection 298 for outside:136.1.121.91/80 (136.1.121.91/80) to inside:10.0.0.201/1292 (136.1.121.21/1292)
%ASA-6-302014: Teardown TCP connection 298 for outside:136.1.121.91/80 to inside:10.0.0.201/1292 duration 0:00:30 bytes 0 SYN Timeout
Решение: требуется ключевой параметр dns в правилах NAT
DNS Doctoring с ключом dns
DNS Doctoring с ключевым словом dns в правилах NAT дает возможность устройству ASA перехватывать и перезаписывать содержимое ответов от DNS сервера в строну клиента. ASA может изменять A-записи в DNS ответах таким образом, чтобы клиент мог подсоединяться к web-серверу. Добавим ключевое слово dns в правило NAT
!
object network DMZ_WEBHOST
nat (dmz,outside) static 136.1.121.91 dns
!
В такой ситуации ASA перезаписывает A-запись таким образом, чтобы направить клиента сразу на адрес 192.168.1.91 вместо адреса 136.1.121.91.
Снова снимем дамп трафика с интерфейсов inside и outside ASA
1. Клиент посылает DNS запрос к серверу 136.1.121.100
2. Выполняется PAT над IP адресами в пакете и запрос перенаправляется к DNS серверу. IP адрес источника в пакете был транслирован в IP адрес внешнего интерфейса ASA
3. DNS сервер ответил транслированным адресом Web-сервера 136.1.121.91
4 ASA выполнила процедуру реверсной трансляции над адресом назначения пакета содержащего DNS ответ и перенаправила его клиенту. Так как теперь включен DNS Doctoring, то ASA перезаписала поле Address A-записи в DNS ответе на реальный адрес web-сервера 192.168.1.91.
Клиент получил DNS ответ, содержащий правильный адрес web-сервера 192.168.1.91

И соединение теперь проходит успешно.
Конечная конфигурация NAT на ASA будет выглядеть следующим образом
object network LAN
subnet 10.0.0.0 255.255.255.0
nat (inside,outside) dynamic interface
!
object network DMZ_WEBHOST
host 192.168.1.91
nat (dmz,outside) static 136.1.121.91 dns
Альтернативное решение: Destination NAT
Альтернативой технологии DNS Doctoring может выступить Destination NAT. Использование этого типа NAT требует, чтобы между публичным адресом web-сервера на интерфейсе inside и реальным адресом web-сервера на интерфейсе dmz была создана статическая трансляция.
Destination NAT не изменяет содержимое A-записи которая возвращается клиенту от DNS сервера. Взамен, клиент может использовать публичный адрес 136.1.121.91, который возвращается DNS сервером для того, чтобы подсоединиться к Web-серверу.
Следующая статическая трансляция позволяет ASA транслировать адрес назначения в IP пакете из 136.1.121.91 в 192.168.1.91
!
object network DMZ_WEBHOST_INSIDE
host 192.168.1.91
nat (dmz,inside) static 136.1.121.91
!
Теперь клиент имеет доступ к web-серверу по его публичному адресу 136.1.121.91

Если попробуем установить TCP соединение, то оно установиться и таблица соединений show conn покажет следующее:

TCP cоединение установлено между интерфейсами dmz и inside. В скобочках вывода show conn показан реальный адрес хоста и ASA напишет в лог
%ASA-6-302013: Built outbound TCP connection 745 for dmz:192.168.1.91/80 (136.1.121.91/80) to inside:10.0.0.201/1718 (10.0.0.201/1718)
Однако используя такой подход, мы теряем доступ по реальному адресу web-сервера 192.168.1.91. Если мы попробуем обратиться на адрес 192.168.1.91, то доступ будет неудачным, а ASA напишет следующий лог
%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src inside:10.0.0.201 dst dmz:192.168.1.91 (type 8, code 0) denied due to NAT reverse path failure
Это связано с тем, что NAT правила всегда проверяются для прямого и обратного трафика. Трафик от 10.0.0.201 до 192.168.1.91 не транслируется, так как он не попадает под правило статической трансляции, в то время как обратный трафик от сервера 192.168.1.91 в строну клиента 10.0.0.201, должен транслироваться в соответствие с правилом static NAT.
Но решение есть. Нам поможет Twice NAT. Чтобы клиенты могли дополнительно обращаться к web-серверу по его реальному адресу, можно сконфигурировать например Dynamic Policy NAT который будет транслировать IP адрес источника пакета в адрес интерфейса DMZ только при доступе к сети 192.168.1.0/24
object network DMZ_NET
subnet 192.168.1.0 255.255.255.0
!
nat (inside,dmz) source dynamic LAN interface destination static DMZ_NET DMZ_NET
Теперь внутренние клиенты могут обращаться к web-серверу как по его реальному адресу, так и по публичному. При этом, в случае обращения по публичному адресу, адрес клиента не транслируется, а в случае обращения по реальному адресу, адрес клиента транслируется в адрес dmz интерфейса ASA.
Если же адрес клиента требуется не транслировать ни в коем случае, то правила Dynamic Policy NAT нужно переделать на Static Identity NAT
object network DMZ_NET
subnet 192.168.1.0 255.255.255.0
!
nat (inside,dmz) source static LAN LAN destination static DMZ_NET DMZ_NET
Так тоже будет работать.
Конечная конфигурация NAT на ASA может выглядеть следующим образом:
object network LAN
subnet 10.0.0.0 255.255.255.0
nat (inside,outside) dynamic interface
!
object network DMZ_NET
subnet 192.168.1.0 255.255.255.0
!
object network DMZ_WEBHOST
host 192.168.1.91
nat (dmz,outside) static 136.1.121.91
!
object network DMZ_WEBHOST_INSIDE
host 192.168.1.91
nat (dmz,inside) static 136.1.121.91
!
nat (inside,dmz) source static LAN LAN destination static DMZ_NET DMZ_NET
Вопрос: При данной конфигурации, от какого IP адреса будут появляется пакеты во внутренней сети, если с web-сервера попытаться установить соединение на машину клиента 10.0.0.201?
DNS Doctoring и PAT
А что делать, если мы хотим опубликовать только один сервис или группу сервисов, таких как TCP 80 и TCP 25, а не сервер целиком? Например, следующая конфигурация публикует на одном глобальном IP адресе два сервиса (WWW и SMTP) с разными реальными адресами.
!
object network DMZ_WEBHOST
host 192.168.1.91
nat (dmz,outside) static 136.1.121.91 service tcp 80 80
!
object network DMZ_EMAILHOST
host 192.168.1.81
nat (dmz,outside) static 136.1.121.91 service tcp 25 25
!
В такой конфигурации с PAT, DNS Doctoring не поддерживается и опция dns отсутствует. Так как внутри A-записей протокола DNS отсутствуют порты, то ASA не знает в какой реальный адрес 192.168.1.91 или 192.168.1.81 нужно транслировать внешний адрес 136.1.121.91 в DNS ответах от сервера.
Поэтому для доступа внутренних клиентов по публичным адресам сервисов, которые возвращаются DNS сервером, используйте альтернативный метод с Destination NAT, описанный выше.