Сделать домашней|Добавить в избранное
 

CCIENetLab - Подготовка к экзаменам
CCNA, CCNP и CCIE

 

DNS Doctoring на ASA 9.x. Часть II

Автор: Sauron от 4-11-2015, 10:16
В первой части мы рассмотрели как работает функционал модификации DNS A-записей (DNS Doctoring) на ASA в проходящих DNS – пакетах, а также показали на примере альтернативные методы доступа к хостам с помощью Destination NAT, в случае когда DNS Doctoring не работает.

В этой части мы продолжим рассмотрение примеров взаимодействия клиентов с хостами и DNS сервером. В прошлой статье, мы показали примеры Destination NAT, когда клиент и веб-сервер находятся за разными интерфейсами ASA. Давайте посмотрим на пример, когда клиент и веб-сервер находятся за одним и тем же интерфейсом ASA, например, inside, а DNS сервер расположен во внешней сети.

Сетевая диаграмма

DNS Doctoring  на ASA 9.x. Часть II

В данном примере Веб-сервер расположен в той же сети 10.0.0.0/24, что и клиент, а DNS сервис обеспечивается внешним DNS сервером. Веб- сервер опубликован во внешней сети под адресом 136.1.121.91 и именем web.lab.local. Для того, чтобы Веб-сервер был доступен по имени, на DNS сервере прописана A-запись вида

web.lab.local  IN A  136.1.121.91

На ASA настроена статическая трансляция вида

object network LAN_WEBHOST
  host 10.0.0.91
  nat (inside,outside) static  136.1.121.91 service tcp 80 80
!

Так как NAT правило представляет собой Static PAT, то DNS Doctoring не поддерживается и ASA не выполняет модификацию A-записей, получаемых клиентом от DNS сервера.

Для того, чтобы клиент мог получить доступ к web-серверу, необходимо, чтобы между публичным адресом web-сервера на inside и реальным адресом web-сервера на inside была создана трансляция вида Destination NAT.

Допустим, для решения данной проблемы мы написали следующее правило
!
object network WEBHOST_INSIDE
  host 10.0.0.91
  nat (inside,inside) static  136.1.121.91
!
same-security-traffic permit intra-interface
!

Т.е здесь мы создали статическую трансляцию между интерфейсом inside и inside для того, чтобы развернуть трафик обратно в inside после трансляции. А для того, чтобы разрешить трафику покидать тот же самый интерфейс через который он вошел, нам требуется команда same-security-traffic permit intra-interface

На первый взгляд все правильно, но если клиент попробует установить TCP соединение с web-сервером, то оно не установиться и клиент получит timeout.

Рассмотрим traffic-flow между клиентом и Web-сервером.
  1. Клиент 10.0.0.201 посылает DNS Запрос на сервер DNS 136.1.121.100 для того, чтобы получить IP адрес Web-сервера с именем web.lab.local.
  2. Клиент получает DNS-ответ содержащий адрес 136.1.121.91 для имени web.lab.local
  3. Клиент отправляет TCP SYN пакет в строну IP адреса 136.1.121.91
  4. TCP SYN пакет попадает на inside интерфейс ASA, так как ASA является для клиента default gateway.
  5. Далее ASA выполняет реверсную трансляцию над адресом назначения в пакете – IP адрес 136.1.121.91 транслируется в реальный адрес 10.0.0.91 и пакет выбрасывается обратно в inside в строну web-сервера.
  6. Web-сервер получает TCP SYN от клиента и отвечает TCP SYN/ACK со своего реального адреса 10.0.0.91 в сторону реального адреса клиента 10.0.0.201. Так как сервер и клиент находятся в одной сети, пакет от сервера идет напрямую клиенту мимо ASA.
  7. Клиент получает TCP SYN/ACK пакет от реального адреса 10.0.0.91 и дропит его, так как ожидает TCP SYN/ACK от транслированного адреса 136.1.121.91

Проблема со связностью возникает из-за того, что трафик - ассиметричный. Прямой трафик от клиента до сервера проходит через ASA, а обратный нет, поэтому у ASA нет возможности выполнить обратную трансляцию реального IP SRC адреса сервера 10.0.0.91 в транслированный IP SRC адрес 136.1.121.91.

Необходимо сделать так, чтобы трафик от web-сервера до клиента, так же проходил через ASA. Единственный способ этого достичь является двойной NAT (Dual NAT). Нам нужно на ASA транслировать не только адрес назначения 136.1.121.91 в 10.0.0.91, но и адрес источника 10.0.0.201, например, в адрес inside интерфейса ASA. А для этого нужен TwiceNAT.

same-security-traffic permit intra-interface
!
object network MAPPED_WEBHOST
  host 136.1.121.91
!
nat (inside,inside) source dynamic LAN interface destination static MAPPED_WEBHOST  DMZ_WEBHOST
!

Теперь web-сервер будет видеть пакеты от клиента приходящие от IP адреса интерфейса inside ASA и, соответственно, обратный трафик от web-сервера к клиенту будет попадать сначала на ASA, где производиться трансляция реального адреса сервера в его транслированный адрес и транслированный адрес клиента в его реальный адрес.

Результирующая NAT конфигурация ASA:

same-security-traffic permit intra-interface
!
object network LAN
 subnet 10.0.0.0 255.255.255.0
 nat (inside,outside) dynamic interface
!
object network DMZ_WEBHOST
  host 10.0.0.91
  nat (inside,outside) static  136.1.121.91 service tcp 80 80
!
object network MAPPED_WEBHOST
  host 136.1.121.91
!
nat (inside,inside) source dynamic LAN interface destination static MAPPED_WEBHOST  DMZ_WEBHOST
!

В случае использования сервисов, Dynamic Policy NAT трансляцию можно более детализировать, используя Dynamic Policy PAT


same-security-traffic permit intra-interface
!
object network LAN
 subnet 10.0.0.0 255.255.255.0
 nat (inside,outside) dynamic interface
!
object network LAN_WEBHOST
  host 10.0.0.91
  nat (inside,outside) static  136.1.121.91 service tcp 80 80
!
object network MAPPED_WEBHOST
  host 136.1.121.91
!
object service SERVICE_WEB
   service tcp destination eq 80
!
nat (inside,inside) source dynamic LAN interface destination static MAPPED_WEBHOST  DMZ_WEBHOST  SERVICE_WEB SERVICE_WEB


DNS Сервер внутри сети.

Когда DNS сервер находиться внутри сети и обеспечивает DNS –сервис для публикуемых серверов, происходят аналогичные процессы модификации A-записей при работе DNS Doctoring.

Рассмотрим топологию на рисунке.

DNS Doctoring  на ASA 9.x. Часть II

Здесь DNS сервер находиться за тем же интерфейсом ASA, что и внутренние клиенты. Web сервер с реальным адресом 10.0.0.91 публикуется во внешней сети под транслированным адресом 136.1.121.91 и именем web.lab.local.

Для того, чтобы Веб-сервер был доступен по имени, на DNS сервере прописана A-запись вида

web.lab.local  IN A  10.0.0.91

Также, чтобы внешние клиенты могли воспользоваться DNS сервисом, сам DNS сервер требуется опубликовать во внешней сети, под адресом 136.1.121.100

Конфигурация NAT на ASA

object network LAN
 subnet 10.0.0.0 255.255.255.0
 nat (inside,outside) dynamic interface
!
object network LAN_DNS
 host 10.0.0.100
 nat (inside,outside) static 136.1.121.100 dns
!
object network LAN_WEBHOST
 host 10.0.0.91
 nat (inside,outside) static 136.1.121.91 dns

Для статической трансляции между inside и outside включен DNS Doctoring. Это позволяет внешним клиентам получить доступ как к web-серверу, так и к DNS серверу по имени.

  1. Внешний клиент 136.1.124.101 посылает DNS Запрос на сервер DNS 136.1.121.100 для того, чтобы получить IP адрес Web-сервера с именем web.lab.local.
  2. DNS-сервер посылает ответ содержащий IP адрес 10.0.0.91 для web-сервера.
  3. Проходя через ASA, DNS-ответ модифицируется и реальный адрес 10.0.0.91 заменяется на транслированный адрес 136.1.121.91.
  4. Внешний клиент получает DNS-ответ содержащий адрес IP 136.1.121.91 для имени web.lab.local

Здесь также все работает хорошо, ровно до тех пор, пока вам не потребуется опубликовать конкретные сервисы, а не сервер целиком.

Например так:
object network LAN_WEBHOST
  host 10.0.0.91
  nat (inside,outside) static  136.1.121.91 service tcp 80 80
!

В такой конфигурации, DNS Doctoring не поддерживается. Поэтому внешние клиенты будут получать DNS-ответы содержащие реальный адрес web-сервера 10.0.0.91, а не транслированный. В этом случае они не смогут получить доступ к web-серверу, так как TCP пакет от внешнего клиента в строну внутреннего IP 10.0.0.91 до web-сервера не дойдет.

Единственный способ решить данную проблему – это держать в DNS A-записи транслированный адрес для web-сервера, а не реальный.

web.lab.local  IN A  136.1.121.91


В этом случае внешним клиентам отдается правильный транслированный адрес web-сервера в DNS ответах, а для того, чтобы внутренние клиенты могли получить доступ к web-серверу необходимо использовать функционал Destination NAT, описанный в предыдущем разделе.скачать dle 10.6фильмы бесплатно
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Комментарии:

Оставить комментарий
 

CCIENetLab (C)