Asa настройка dns client

Обновлено: 02.07.2024

Конструкция ip host name1 192.168.0.11 работает подобно файлу hosts в windows.
Проверка:

DNS server для своих
Предыдущий конфиг приводит к тому, что роутер будет отвечать на все запросы DNS: как изнутри так и снаружи.
Для того, чтобы DNS сервер отвечал только на внутренние запросы у нас есть два пути:

DNS server для своих: ACL
Приведём здесь стандартный ACL, который в том числе запрещает доступ к нашему DNS через внешний интерфейс, и при этом разрешает DNS-запросы наружу:

ip access-list extended outside_acl_in
remark --- Add anti-spoofing entries. !--- Deny special-use address sources. !--- Refer to RFC 3330 for add
deny ip 127.0.0.0 0.255.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 224.0.0.0 31.255.255.255 any
deny ip host 255.255.255.255 any
remark --- The deny statement should not be configured !--- on Dynamic Host Configuration Protocol (DHCP) r
deny ip host 0.0.0.0 any
remark --- Filter RFC 1918 space.
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
remark --- Explicitly permit return traffic. !--- Allow specific ICMP types.
permit icmp any any echo
permit icmp any any echo-reply
permit icmp any any unreachable
permit icmp any any time-exceeded
deny icmp any any
remark --- These are outgoing DNS queries.
permit udp any eq domain any gt 1023
remark --- Permit older DNS queries and replies to primary DNS server.
permit udp any eq domain any eq domain
remark --- Permit legitimate business traffic.
permit tcp any any established
permit udp any range 1 1023 any gt 1023
remark --- Deny all other DNS traffic.
deny udp any any eq domain
deny tcp any any eq domain
remark --- Allow IPSec VPN traffic.
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
permit ahp any any
permit gre any any
remark --- These are Internet-sourced connections to !--- publicly accessible servers.
permit tcp any any eq 22
remark --- Explicitly deny all other traffic.
deny ip any any
interface Port-channel1.81
ip access-group outside_acl_in in

DNS server для своих: Split DNS
В данном случае мы можем использовать функционал Split DNS:

ip domain lookup
ip domain timeout 2
ip domain name office.local
ip name-server 8.8.8.8
ip name-server 8.8.4.4
ip dns server

ip dns view no_dns_service_view
no domain lookup
no dns forwarding

ip dns view default
domain timeout 2
dns forwarder 8.8.8.8

ip dns view-list no_dns_service_list
view no_dns_service_view 1

interface Port-channel1.81
ip dns view-group no_dns_service_list

Просмотр и удаление кеша DNS (DNS cache)

Источник:
Split DNS
Cisco router в качестве DNS server
Настройка Cisco ASA в качестве пересылки DNS сервера на прошивке выше или равной 8.3
ASA DNS Server

В этом документе приведен пример конфигурации для исправления системы доменных имен (DNS) на устройстве адаптивной безопасности серии ASA 5500 или устройстве безопасности серии PIX 500 с помощью утверждений статической таблицы преобразования сетевых адресов (NAT). Исправление DNS позволяет устройству безопасности перезаписывать A-записи DNS.

Перезапись DNS выполняет две функции:

Преобразует публичный адрес (маршрутизируемый или сопоставляемый адрес) в отклик DNS на частный адрес (реальный адрес), когда клиент DNS находится на частном интерфейсе.

Преобразует частный адрес в публичный адрес, когда клиент DNS находится на публичном интерфейсе.

Примечание. Конфигурация в этом документе содержит два интерфейса NAT: внутренний и внешний. Пример исправления DNS со статикой и тремя интерфейсами NAT (внутренним, внешним и dmz) см. в разделе PIX/ASA: Пример исправления DNS с помощью статической команды и трех интерфейсов NAT.

Предварительные условия

Требования

Чтобы выполнить исправление DNS, на устройстве безопасности должна быть включена проверка DNS. Проверка DNS по умолчанию включена. Если она была отключена, обратитесь к параграфу Настройка проверки DNS далее в этом разделе, чтобы снова включить ее. Когда проверка DNS включена, устройство безопасности выполняет следующие задачи:

Преобразует запись DNS на основании конфигурации, выполненной с помощью команд static и nat (перезапись DNS). Преобразование применяется только к А-записи в отклике DNS. Поэтому обратные поиски, запрашивающие запись PTR, не затрагиваются перезаписью DNS.

Примечание. Перезапись DNS несовместима с преобразованием адресов портов (PAT), так как к каждой А-записи применимы несколько правил PAT и использование правила PAT неоднозначно.

Примечание. Если выполнить команду inspect dns без парметра maximum-length, размер пакета DNS не проверяется.

Задает длину доменного имени в 255 байт и длину метки в 63 байта.

Проверяет наличие петли указателя сжатия.

Используемые компоненты

Сведения, содержащиеся в данном документе, относятся к устройству безопасности серии ASA 5500, версия 7.2(1).

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в данном документе, были запущены с конфигурацией по умолчанию. При работе в действующей сети необходимо понимать последствия выполнения любой команды.

Родственные продукты

Эта конфигурация также может быть использована с устройством безопасности серии Cisco PIX 500 версии 6.2 или более поздней.

Примечание. Конфигурация диспетчера устройств адаптивной безопасности Cisco (ASDM) применима только к версии 7.x.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Общие сведения

При обычном обмене DNS клиент отправляет URL или имя узла на DNS-сервер, чтобы определить IP-адрес этого узла. DNS-сервер получает запрос, ищет сопоставление имя — IP-адрес для данного узла и предоставляет А-запись с IP-адресом клиенту. Хотя эта процедура хорошо работает во многих ситуациях, могут возникать и проблемы. Проблемы могут возникнуть, когда клиент и узел, который клиент пытается достичь, находятся в одной частной сети за NAT, а DNS-сервер, используемый клиентом, находится в другой публичной сети.

Сценарий: Два интерфейса NAT (внутренний, внешний)

Топология

Проблема: Клиент не может получить доступ к серверу WWW

Вот как выглядит конфигурация в ASDM, когда исправление DNS не включено:

Вот захват пакета событий, когда исправление DNS не включено:

Клиент отправляет запрос DNS.

ASA выполняет PAT для DNS-запроса и запрос пересылается. Заметьте, что исходный адрес пакета изменился на внешний интерфейс ASA.

На этом этапе клиент пытается обратиться к серверу WWW по адресу 172.20.1.10. ASA создает запись соединения для этого обмена данными. Однако, так как ASA не разрешает прохождение трафика с внутреннего интерфейса на внешний и обратно, соединение простаивает. Записи журнала ASA выглядят следующим образом:

Решение: Ключевое слово "dns"

Исправление DNS с помощью ключевого слова "dns"

Чтобы настроить исправление DNS в ASDM, выполните следующие действия:

Перейдите в Configuration > NAT и выберите статическое правило NAT для изменения. Нажмите Edit.

Нажмите NAT Options. .

Установите флажок Translate DNS replies that match the translation rule.

Вот захват пакета событий, когда исправление DNS включено:

Клиент отправляет запрос DNS.

На этом этапе клиент пытается обратиться к серверу WWW по адресу 192.168.100.10. Соединение устанавливается. Трафик не перехватывается в ASA, так как клиент и сервер находятся в одной подсети.

Окончательная конфигурация с ключевым словом "dns"

Это окончательная конфигурация ASA для выполнения исправления DNS с ключевым словом dns и двумя интерфейсами NAT.

Окончательная конфигурация ASA 7.2(1)

Альтернативное решение: Прикрепление

Прикрепление со статическим NAT

Внимание: Прикрепление со статическим NAT предусматривает отправку всего трафика между клиентом и сервером WWW через устройство безопасности. Тщательно оцените ожидаемый объем трафика и возможности устройства безопасности, прежде чем применять это решение.

Прикрепление — это процесс, который отправляет трафик обратно на тот интерфейс, с которого он поступил. Эта функция была добавлена в ПО устройств безопасности версии 7.0. Для версий ниже 7.2(1) по крайней мере одна ветвь прикрепленного трафика (входящая или исходящая) обязательно должна быть зашифрована. Начиная с версии 7.2(1) это требование не действует. При использовании версии 7.2(1) обе ветви трафика могут быть незашифрованы.

Прикрепление в сочетании с утверждением NAT static можно использовать для достижения того же эффекта, что и исправление DNS. Этот метод не изменяет содержимое А-записи DNS, которая возвращается от DNS-сервера клиенту. Вместо этого, при использовании прикрепления, например в сценарии, рассматриваемом в этом документе, клиент может использовать для соединения адрес 172.20.1.10, возвращенный DNS-сервером.

Вот как выглядит соответствующая часть конфигурации при использовании прикрепления и статического NAT для достижения эффекта исправления DNS. Команды, выделенные полужирным шрифтом, объясняются более подробно в конце этих выходных данных:

same-security-traffic—Эта команда позволяет трафику того же уровня безопасности проходить через устройство безопасности. Ключевые слова permit intra-interface позволяют трафику одного уровня безопасности поступать и исходить с одного и того же интерфейса, таким образом включая прикрепление.

Примечание. Дополнительные сведения о прикреплении и о команде same-security-traffic см. в разделе трафик одного уровня безопасности.

global (inside) 1 interface—Весь трафик, проходящий через устройство безопасности, должен пройти через NAT. Эта команда использует адрес внутреннего интерфейса устройства безопасности, чтобы позволить трафику, поступающему на внутренний интерфейс, пройти через PAT, как бы прикрепляя его снаружи внутреннего интерфейса.

Чтобы настроить прикрепление со статическим NAT в ASDM, выполните следующие действия:

Перейдите на Configuration > Interfaces.

В нижней части окна установите флажок Enable traffic between two or more hosts connected to the same interface.

Перейдите на Configuration > NAT и выберите Add > Add Static NAT Rule. .

Введите данные конфигурации для нового статического преобразования.

В этом случае внутренний интерфейс выбирается так, чтобы разрешить узлам на внутреннем интерфейсе обращаться к серверу WWW через сопоставленный адрес 172.20.1.10.

Нажмите OK, чтобы покинуть окно "Add Static NAT Rule" (Добавление статического правила NAT).

Выберите существующее динамическое преобразование PAT и нажмите Edit.

Выберите inside из выпадающего меню Interface (Интерфейс).

Нажмите Add.

Выберите переключатель Port Address Translation (PAT) using IP address of the interface. Нажмите Add.

Вот последовательность событий, которые происходят, когда настроено прикрепление. Предположим, что клиент уже запросил DNS-сервер и получил ответ в виде адреса 172.20.1.10 для сервера WWW:

Клиент пытается обратиться к серверу WWW по адресу 172.20.1.10.

Устройство безопасности принимает запрос и определяет, что сервер WWW находится по адресу 192.168.100.10.

Устройство безопасности создает динамическое преобразование PAT для клиента. Источником клиентского трафика теперь является внутренний интерфейс устройства безопасности: 192.168.100.1.

Устройство безопасности создает TCP-соединение между клиентом и сервером WWW через себя. Обратите внимание на сопоставленные адреса узлов в скобках.

Команда show xlate на устройстве безопасности проверяет, что клиентский трафик преобразуется через устройство безопасности.

Команда show conn на устройстве безопасности проверяет, что соединение между устройством безопасности и сервером WWW установлено от имени клиента. Обратите внимание на реальный адрес клиента в скобках.

Окончательная конфигурация с прикреплением и статическим NAT

Это окончательная конфигурация ASA, которая использует прикрепление и статический NAT для достижения эффекта исправления DNS с двумя интерфейсами NAT.

Окончательная конфигурация ASA 7.2(1)

Настройка проверки DNS

Чтобы включить проверку DNS (если она была отключена ранее), выполните следующие действия. В этом примере проверка DNS добавляется в глобальную политику проверки по умолчанию, которая применяется глобально командой service-policy, как при начале работы ASA с конфигурацией по умолчанию. Дополнительные сведения о служебных политиках и проверке см. в разделе Использование модульной системы политик.

Создайте карту политик проверки для DNS.

Из режима настройки карты политик войдите в режим настройки параметров, чтобы задать параметры для механизма проверки.

Выйдите из режима настройки параметров карты политик и из режима настройки карты политик.

Подтвердите создание карты политик проверки.

Войдите в режим настройки карты политик для global_policy.

В режиме настройки карты политик задайте карту класса уровней 3/4 по умолчанию, inspection_default.

В режиме настройки класса карты политик укажите, что DNS должен проверяться с помощью карты политик проверки, созданной на шагах 1-3.

Выйдите из режима настройки класса карты политик и из режима настройки карты политик.

Убедитесь, что карта политик global_policy настроена как требуется.

Убедитесь, что политика global_policy применяется глобально служебной политикой.

Настройка раздельных DNS

Выполните команду split-dns в режиме настройки групповой политики, чтобы ввести список доменов, разрешающихся через раздельные туннели. Используйте форму no этой команды, чтобы удалить список.

Если списки доменов раздельного туннелирования отсутствуют, пользователи наследуют списки, существующие в групповой политике по умолчанию. Выполните команду split-dns none, чтобы предотвратить наследование списков доменов раздельного туннелирования.

Для разделения записей в списке доменов используйте одиночные пробелы. Число записей не ограничено, но длина всей строки не может превышать 255 символов. Можно использовать только алфавитно-цифровые символы, дефисы (-) и точки (.). Команда no split-dns, при использовании без аргументов, удаляет все текущие значения, включая нулевые значения, созданные при выполнении команды split-dns none.

В этом примере показано, как настроить домены Domain1, Domain2, Domain3 и Domain4, чтобы они разрешались через раздельное туннелирование для групповой политики с именем FirstGroup:

Проверка

Этот раздел позволяет убедиться, что конфигурация работает правильно.

Захват трафика DNS

Одним из методов проверки правильной перезаписи записей DNS устройством безопасности является захват соответствующих пакетов, как рассматривалось в предыдущем примере. Для захвата трафика на ASA выполните следующие действия:

Создайте список доступа для каждого экземпляра захвата, который планируется создать.

ACL должен задавать трафик, который планируется захватывать. В этом примере создаются два ACL.

ACL для трафика на внешнем интерфейсе:

ACL для трафика на внутреннем интерфейсе:

Создайте экземпляры захвата:

Вот как должны выглядеть примеры захватов после прохождения DNS-трафика:

(Необязательно) Скопируйте захваты на сервер TFTP в формате pcap для анализа в другом приложении.

Приложения, которые могут анализировать формат pcap, могут показывать дополнительные данные, например имя и IP-адрес в А-записях DNS.

Устранение неполадок

В этом разделе описывается процесс устранения неполадок конфигурации.

Перезапись DNS не выполняется

Убедитесь, что на сутройстве безопасности настроена проверка DNS. См. раздел Настройка проверки DNS.

Создание преобразования не выполняется

Сброс отклика UDP DNS

Чтобы решить эту проблему, увеличьте длину пакета DNS в диапазоне 512-65535.

В этом документе мы опишем простую конфигурацию для выполнения инспектирования DNS на ASA (Domain Name System (DNS) doctoring), которое используется в Object NAT / Auto NAT. Также можно проверить работу на The Emulated Virtual Environment for Network

Функционал инспектирования DNS doctoring позволяет устройству безопасности ASA перезаписывать (rewrite) DNS A-записи и PTR-записи.
DNS Rewrite выполняет две функции:

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

Функционал DNS doctoring работает только, если у вас включено инспектирование протокола DNS

Рассмотрим топологию на рисунке. 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:

Проблема: Клиент на 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 пишет в логах

Решение: требуется ключевой параметр dns в правилах NAT

DNS Doctoring с ключом dns

Снова снимем дамп трафика с интерфейсов 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 будет выглядеть следующим образом

Альтернативное решение: 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

Теперь клиент имеет доступ к web-серверу по его публичному адресу 136.1.121.91

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

TCP cоединение установлено между интерфейсами dmz и inside. В скобочках вывода show conn показан реальный адрес хоста и ASA напишет в лог

Однако используя такой подход, мы теряем доступ по реальному адресу web-сервера 192.168.1.91. Если мы попробуем обратиться на адрес 192.168.1.91, то доступ будет неудачным, а ASA напишет следующий лог

Это связано с тем, что 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

Теперь внутренние клиенты могут обращаться к web-серверу как по его реальному адресу, так и по публичному. При этом, в случае обращения по публичному адресу, адрес клиента не транслируется, а в случае обращения по реальному адресу, адрес клиента транслируется в адрес dmz интерфейса ASA.

Если же адрес клиента требуется не транслировать ни в коем случае, то правила Dynamic Policy NAT нужно переделать на Static Identity NAT

Так тоже будет работать.

Конечная конфигурация NAT на ASA может выглядеть следующим образом:

Вопрос: При данной конфигурации, от какого IP адреса будут появляется пакеты во внутренней сети, если с web-сервера попытаться установить соединение на машину клиента 10.0.0.201?

DNS Doctoring и PAT

А что делать, если мы хотим опубликовать только один сервис или группу сервисов, таких как TCP 80 и TCP 25, а не сервер целиком? Например, следующая конфигурация публикует на одном глобальном IP адресе два сервиса (WWW и SMTP) с разными реальными адресами.

В такой конфигурации с PAT, DNS Doctoring не поддерживается и опция dns отсутствует . Так как внутри A-записей протокола DNS отсутствуют порты, то ASA не знает в какой реальный адрес 192.168.1.91 или 192.168.1.81 нужно транслировать внешний адрес 136.1.121.91 в DNS ответах от сервера.

Поэтому для доступа внутренних клиентов по публичным адресам сервисов, которые возвращаются DNS сервером, используйте альтернативный метод с Destination NAT, описанный выше.скачать dle 10.6фильмы бесплатно

Привет habr! В данной заметке хотел бы обсудить тему пересечения адресных пространств при предоставлении доступа удалённым пользователям. Буду рассматривать удалённый доступ средствами VPN-клиента Cisco AnyConnect. В качестве VPN-концентратора рассмотрим Cisco ASA. Примеры, описываемые в этой статье, были сконфигурированы на ASA5505 с версией программного обеспечения 9.1(6)6. Используемая версия клиента Anyconnect – 4.1. В качестве подключаемых по VPN клиентских устройств использовались персональные компьютеры с ОС Windows 7 и 8.1.

У многих сотрудников, желающих работать удалённо, для подключения к Интернет дома используются SOHO-маршрутизаторы, и очень часто маршрутизаторы установлены с заводскими настройками. А, как известно, в подавляющем большинстве случаев заводские настройки предполагают LAN-подсеть 192.168.0.0/24 или 192.168.1.0/24. Как показывает практика, вероятность наличия в центральном офисе (далее ЦО) компании сетей 192.168.0.0/24 и 192.168.1.0/24 велика. Получается пересечение адресных пространств. В данной заметке рассмотрю три варианта настроек подключений к ЦО через AnyConnect, выделю плюсы и минусы каждого варианта и опишу, как будет работать доступ в случае пересечении адресных пространств.

Первый вариант – самый простой. Заключается в отказе от Split tunneling (как мы помним Split tunneling позволяет указать, какой трафик нужно заворачивать в туннель, а какой не нужно). В данном случае абсолютно весь трафик заворачивается в VPN туннель. Данное поведение настраивается директивой split-tunnel-policy tunnelall в групповой политике VPN-подключения. При отключенном Split tunneling во время установления соединения из таблицы маршрутизации подключаемого устройства исчезает маршрут в локальную сеть и появляется новый маршрут по умолчанию с лучшей метрикой. Ниже примеры вывода route print windows-компьютера до установленного VPN-соединения и после подключения:

При этом, выход в Интернет для подключаемого устройства мы можем организовать только через Интернет-канал офиса, к которому пользователь и подключился. Заметим, при настроенном выходе в Интернет через ЦО, канал будет утилизироваться трафиком удалённого пользователя вдвое больше.

Для настройки Интернет доступа для удалённых подключений на Cisco ASA достаточно соблюсти два нюанса. Первый нюанс – корректно настроить dynamic nat|pat для пула адресов, выдаваемых AnyConnect. Пример настройки nat:

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

Простота настройки;
Единое поведение для всех удалённых пользователей вне зависимости от сетевых настроек подключаемого устройства.

Необходимость настройки Интернет доступа для подключаемых пользователей через Интернет канал ЦО, и, как следствие, двойная утилизация канала ЦО Интернет-трафиком удалённого пользователя;
Подключаемое устройство теряет доступ к собственной локальной сети. Например, сетевой принтер или сетевое хранилище в локальной сети становятся недоступны для пользователя во время сессии AnyConnect.

Второй вариант – использование политик Split tunneling. Политики Split tunneling бывают двух видов: Split Include и Split Exclude. В первом случае необходимо указать, какие сети нужно туннелировать, во втором – наоборот, указывается, какие сети не нужно заворачивать в туннель.

По нашему опыту Split Include используется наиболее часто. В этом случае необходимо настроить список доступа, который будет определять, какие именно сети нужно туннелировать. Пример настройки:

В случае пересечения адресных пространств удалённый пользователь попросту теряет доступ к своей локальной сети. То есть, если у пользователя локальная сеть 192.168.0.0/24 или 192.168.1.0/24, трафик к хостам данных сетей будет заворачиваться в туннель. При этом, Интернет-доступ для удалённого пользователя останется через локального Интернет-провайдера. По нашему опыту данная настройка устраивает пользователей в большинстве случаев.

Split Tunneling вида Split Exclude, наоборот, позволяет удалённым пользователям сохранить доступ к собственной локальной сети в любом случае. Безусловно, в случае пересечения адресных пространств доступ в конфликтную сеть ЦО работать не будет. Ниже приведём пример настройки Split Exclude. В список доступа в этом случае будем включать сети, которые не нужно туннелировать. В примере мы не будем туннелировать диапазоны публичных адресов (это обеспечит выход в Интернет с использованием локального Интернет-провайдера), а также не будем туннелировать сеть вида 0.0.0.0/255.255.255.255, описывающую в настройках ASA локальную сеть клиента. Запись сети 0.0.0.0/255.255.255.255 помогает достичь универсальности: не зависимо от того, какая именно сеть у пользователя является локальной, доступ к ней всегда будет работать.

Однако, для того, чтобы доступ пользователя в собственную локальную сеть работал, нужно не забыть ещё один нюанс. В настройках клиента Anyconnect в явном виде должна быть указана опция Allow local (LAN) access:

Эту опцию можно выставлять централизованно в настройках профиля клиента Anyconnect на Cisco ASA:

Выход в Интернет можно настроить через локального провайдера. Здесь же хочется оговориться: для обеспечения максимального уровня безопасности рекомендуется организовывать выход в Интернет удалённых пользователей всё же через корпоративные шлюзы, мсэ и web-прокси серверы. Но на практике, данным требованием многие пренебрегают;
Для пользователей, у которых нет пересечения адресных пространств с ЦО, доступ в локальную сеть работает без проблем.

Для пользователей, у которых происходит пересечение адресных пространств с ЦО, теряется доступ в локальную сеть. Split Exclude помогает избежать потери доступа в локальную сеть, но в этом случае будет утерян доступ в конфликтную сеть ЦО.

Предположим, наша задача организовать доступ таким образом, чтобы даже у пользователей, имеющих пересечение адресного пространства, всегда работал доступ как в конфликтную сеть ЦО, так и в собственную локальную сеть. Для этого нам потребуется транслировать конфликтную сеть ЦО в другую сеть для удалённых пользователей. Например, конфликтная сеть 192.168.1.0/24. Настроим трансляцию всей сети 192.168.1.0/24 в некоторую другую сеть 192.168.25.0/24. Тогда удалённые пользователи, желающие подключиться к хосту в ЦО с адресом, например, 192.168.1.10, должны будут использовать для подключения транслированный адрес 192.168.25.10. На ASA описываемую конструкцию можно настроить с помощью правил twice NAT следующим образом:

Конечно, работать с IP адресами для конечных пользователей не удобно. Тем более в описываемом случае придётся помнить, что чтобы попасть на хост 192.168.1.10, нужно использовать адрес 192.168.25.10 (то есть приходится запоминать уже два IP-адреса). На помощь приходит DNS и функция DNS doctoring на ASA. DNS doctoring позволяет изменять IP-адрес в DNS-ответах в соответствии с правилами NAT. Пример работы DNS Doctoring представлен на рисунке ниже:

Замечание 1: для использования функции DNS doctoring на ASA должны быть включена инспекция DNS:

Замечание 2: для использования функции DNS doctoring подключаемый по VPN клиент должен использовать внутренний корпоративный DNS-сервер (находящийся за ASA).

На ASA при настройке DNS doctoring есть нюанс. DNS doctoring не всегда можно настроить в правиле Twice NAT. Опция dns в правиле NAT становится не доступна, как только после source static появляется директива destination static:

Данное поведение задокументировано на сайте Cisco.

Если мы не будем использовать destination static, конфликтная сеть ЦО 192.168.1.0/24 будет транслироваться в новую сеть 192.168.25.0/24 всегда, а не только для удалённых сотрудников. Это поведение не приемлемо. Чтобы этого не происходило, мы должны поставить правило трансляции конфликтной сети в конец правил NAT. При этом вышестоящие правила трансляции, касающиеся конфликтной сети, мы должны модернизировать таким образом, чтобы правила срабатывали всегда, кроме случая обмена данными с удалёнными пользователями. В данном случае порядок правил NAT имеет решающее значение, поэтому, очень кратко напомню порядок правил NAT для ASA версии IOS 8.3 и выше. Правила NAT выполняются в порядке трёх секций:

Секция 1. Twice NAT в порядке конфигурации

Static
Dynamic
- Cначала, где меньше IP адресов для трансляции
- Сначала младшие номера IP
- По алфавиту (по названию Obj gr)

Приведу пример. Для организации выхода в Интернет из конфликтной сети ЦО, как правило, требуется наличие соответствующего правила dynamic nat|pat. Если dynamic nat|pat настроено с помощью Network Object Nat, придётся модифицировать настройку к виду Twice NAT. Это необходимо, чтобы иметь возможность добавить в правило директиву destination static (получаем так называемый Policy NAT). Правило dynamic pat нужно поставить выше правила nat для удалённых пользователей. Это можно сделать разными способами: указать позицию правил в явном виде в секции 1, перенести правило nat для удалённых пользователей в секцию 3 after auto и т.д. Пример настройки:

Если мы используем Split tunneling вида Split Include, не забываем в соответствующем списке доступа указать именно транслированную сеть net-25:

Все преимущества использования Split Tunneling присущи третьему варианту;
Для пользователей, у которых происходит пересечение адресных пространств с ЦО появляется возможность получить доступ в конфликтную сеть ЦО, сохраняя при этом доступ к собственной локальной сети.

Сложность конфигурирования. При использовании DNS doctoring необходимо модифицировать правила трансляции адресов, касающиеся конфликтных сетей.

без Split Tunneling;
с использованием Split Tunneling двух видов: Split Include и Split Exclude;
с использованием Split Tunneling совместно с правилами NAT и опцией DNS doctoring.

Жду Ваши комментарии. Может быть, кто-то сможет поделиться своим опытом или другим способом решения проблемы пересечения адресных пространств.

Читайте также: