Split dns cisco настройка

Обновлено: 05.07.2024

А можно ли как-нибудь настраивать параметры DNS кэша? Ну там количество записей в кэеше или время жизни записи?

>А можно ли как-нибудь настраивать параметры DNS кэша? Ну там количество записей
>в кэеше или время жизни записи?
ВОпрос.. зачем на Циске ДНС-сервер.

>ВОпрос.. зачем на Циске ДНС-сервер.

Странный ВОпрос.
За тем же, зачем на ней DHCP или VPN или файевол или маршртуизатор.
Твой вопрос звучит как "чем циска лучше компютера"
Я например с удовольствием бы выкинул бы DNS сервер с UNIX машины и перевел бы его на циску
потому что считаю что безопасность при этом сильно повыситься а затраты на администрирование снизится.

>>ВОпрос.. зачем на Циске ДНС-сервер.
>
>Странный ВОпрос.
>За тем же, зачем на ней DHCP или VPN или файевол или
>маршртуизатор.
>Твой вопрос звучит как "чем циска лучше компютера"
>Я например с удовольствием бы выкинул бы DNS сервер с UNIX машины
>и перевел бы его на циску
>потому что считаю что безопасность при этом сильно повыситься а затраты на
>администрирование снизится.
На самом деле даже в самой циске никогда не приводят примеров работы dns-сервера на оборудовании циско, у них даже всегда в курсах присутствует выделенный dns-сервер.

>На самом деле даже в самой циске никогда не приводят примеров работы
>dns-сервера на оборудовании циско, у них даже всегда в курсах присутствует
>выделенный dns-сервер.
И теперь мне стало понятно почему :)

>>ВОпрос.. зачем на Циске ДНС-сервер.
>
>Странный ВОпрос.
>За тем же, зачем на ней DHCP или VPN или файевол или
>маршртуизатор.
>Твой вопрос звучит как "чем циска лучше компютера"
>Я например с удовольствием бы выкинул бы DNS сервер с UNIX машины
>и перевел бы его на циску
>потому что считаю что безопасность при этом сильно повыситься а затраты на
>администрирование снизится.
Затраты снизяться. если Вы имеете ввиду кеширующий ДНС-сервер.. то спору нет.. Но нагрузка на проц??
а кроме того. транфер зон. МХ,CNAME,PTR записи.. где на Циске будет Вам полноценный ДНСсервер? ))

> Не показывайте свою некомпетентность или лень. Вас не спрашивают - ЗАЧЕМ? Вас
> спрашивают - КАК?
Молоток. Респект.

>> Не показывайте свою некомпетентность или лень. Вас не спрашивают - ЗАЧЕМ? Вас
>> спрашивают - КАК?
> Молоток. Респект.
Хорошо, что на мои вопросы по Астериску и воайпи все спешат показать свою компетентность.

Не, ребята не в цисковских процах проблема, а в карявых руках админа. Проц нагружается от того, что он сам пытается всё резолвить через root сервера. Циска это может, но не должна, по скольку не расчитана на такую работу. Этим должен заниматься сервер провайдера. Настройте вашу циску так, что бы все dns резолвились на провайдера.

а если я сам провайдер?
> расчитана на такую работу. Этим должен заниматься сервер провайдера. Настройте вашу
> циску так, что бы все dns резолвились на провайдера.

Тогда покупайте соответствующее железо. Линейка small-buizness при правильной настройке на отлично выполняет свои функции для более чем 500 компов (на данный момент). Однако, если вы региональный провайдер, я вас умоляю, не цепляйте 20 тонную фуру к запарожу, брите линейку enterprise.
> а если я сам провайдер?
>> расчитана на такую работу. Этим должен заниматься сервер провайдера. Настройте вашу
>> циску так, что бы все dns резолвились на провайдера.

> Не, ребята не в цисковских процах проблема, а в карявых руках админа.
> Проц нагружается от того, что он сам пытается всё резолвить через
> root сервера. Циска это может, но не должна, по скольку не
> расчитана на такую работу. Этим должен заниматься сервер провайдера. Настройте вашу
> циску так, что бы все dns резолвились на провайдера.
Я оставил свои DNS-зоны на циске, а разрешение имен, с которыми циска не справлялась, сделал через службу dns-сервера на windows server DMZ-сегмента.
Не в тему, но эта служба windows тоже странно написана. Обход списка форвардеров для каждого разрешения начинается с первого и если первый форвардер в списке не доступен, то начинается жопа. Пришлось написать сценарий, который периодически запускается планировщиком, ранжирует форвардеров по скорости ответа и сортирует их в списке службы DNS-сервера.

Самое познавательное в этой истории что тема открыта в 2008, когда, наверное, не все здесь отписавшиеся уже знали что такое cisco ))
и спустя 5 лет ничего не изменилось я смотрю )))
> Я оставил свои DNS-зоны на циске, а разрешение имен, с которыми циска
> не справлялась, сделал через службу dns-сервера на windows server DMZ-сегмента.

Cisco router можно настроить в качестве кеширующего DNS сервера. Это удобно в небольших офисах, где нет серверов Windows и AD.
Общий вид команд выглядит следующим образом:

ip domain lookup - включает трансляцию имён в ip адреса основанную на dns. Этот параметр включен по умолчанию. Часто его выключают чтобы маршрутизатор не "зависал" при вводе ошибочной команды, но для нашей цели его необходимо включить.
ip name-server - этот параметр задаёт адрес одного или нескольких серверов имён (dns). Приоритет определяется сверху вниз.
ip domain name - задаёт имя домена по умолчанию для пользователей Cisco IOS software для разрешения "неопознаных" доменных имён (имена без суффикса.
ip dns server - включаем собственно кеширующий DNS сервер на циске

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

Проверка:
show ip dns view

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

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

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

4BALL
SW0
Int fa0/1
Description Servers
Switchport access vlan 100
Switchport mode access
Int fa0/11
Description IT
Switchport access vlan 101
Switchport mode access
Int fa0/12
Description IT
Switchport access vlan 101
Switchport mode access
Int fa0/2
Description Servers
Switchport access vlan 100
Switchport mode access

4BALL
SW2
Int fa0/1
Description Manager
Switchport access vlan 102
Switchport mode access
Int fa0/2
Description Manager
Switchport access vlan 102
Switchport mode access

SW3
Int fa0/1
Description Manager
Switchport access vlan 102
Switchport mode access
Int fa0/2
Description Manager
Switchport access vlan 102
Switchport mode access

2BALL
SW1
Gig0/1
Description Management
Switchport trunk allowed vlan 1,100-102,252
Switchport mode trunk
Gig0/2
Description Management
Switchport trunk allowed vlan 1,100-102,252
Switchport mode trunk (gig0/2 прописать 2 раза)

2BALL
SW2
Gig0/1
Description Management
Switchport trunk allowed vlan 100-102
Switchport mode trunk
Gig0/2
Description Management
Switchport trunk allowed vlan 100-102
Switchport mode trunk

2BALL
SW3
Gig0/1
Description Management
Switchport trunk allowed vlan 100-102
Switchport mode trunk
Gig0/2
Description Management
Switchport trunk allowed vlan 100-102
Switchport mode trunk

6BALL
SW1
Vtp domain YktSkills
Vtp password ykt2015
Vtp version 2
Vtp mode client

6BALL
SW2, SW3
Vtp password ykt2015
Vtp version 2
Vtp mode client

3BALL
SW0
Vtp domain YktSkills
Vtp password ykt2015
Vtp version 2

3BALL (можно не писать)
Server0, Server1, Server2
Default Gateway 172.18.0.1

8BALL
Server2/вкладка DNS/ создаем
R0/address 10.10.0.1 (жмем add)
SW0/address 10.10.0.2
SW1/address 10.10.0.3
SW2/address 10.10.0.4
SW3/address 10.10.0.5
Dns/address 172.18.0.254
ftp/address 172.18.0.252
web/address 172.18.0.253

1BALL (можно пропустить)
PC6 переключить на DHCP

4BALL
SW0, SW1, SW2, SW3
Spanning-tree mode rapid-pvst

2BALL
R0
Int fa0/0.100
Description Servers
Encapsulation dot1Q 100
Ip address 172.18.0.20 255.255.255.0

2BALL
Int fa0/0.101
Description IT
Encapsulation dot1Q 101
Ip address 172.18.0.21 255.255.255.0

2BALL
Int fa0/0.102
Description Manager
Encapsulation dot1Q 102
Ip address 172.18.2.24 255.255.255.0

1BALL
Int fa0/0.252
Description Manager
Encapsulation dot1Q 252
Ip address 10.10.1.8 255.255.255.0

2BALL
PC6
IP 10.10.0.6
MASK 255.255.0.0
Def Get 10.10.0.1

5BALL
R0
Ip dhcp pool Manager
Network 172.18.2.0 255.255.255.0
Default-router 172.18.2.1

Ip dhcp pool IT
Network 172.18.1.0 255.255.255.0
Default-router 172.18.1.1

2BALL
R0
Ip dhcp pool IT
Network 172.18.1.0 255.255.255.0
Default-router 172.18.1.1
Ip dhcp excluded-address 172.18.1.1

Ip dhcp pool Manager
Network 172.18.2.0 255.255.255.0
Default-router 172.18.2.1
Ip dhcp excluded-address 172.18.2.1

В этом документе приведен пример конфигурации для исправления системы доменных имен (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.

Привет 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.

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

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