Меню

Cisco anyconnect не работает dns

Cisco anyconnect не работает dns

Этот документ описывает, как другие operations support system (OSS) обрабатывают запросы системы доменных имен (DNS) и их влиять на разрешении доменного имени с AnyConnect.

Внесенный специалистами службы технической поддержки Cisco.

Каковы различия в способах, которыми другие платформы OSS обрабатывают запросы DNS, и как это влияет на разрешение доменного имени с AnyConnect и разделением или полным туннелированием?

Разделение в сравнении со стандартным DNS

Когда вы используете разделение — включают туннелирование, у вас есть три параметра для dns:

    Разделение DNS Запросы DNS, которые совпадают с доменными именами, настроенными на устройстве адаптивной защиты Cisco (ASA), проходят через туннель, например, к серверам DNS, определенным на ASA, и другие не делают.

Tunnel-all-DNS — только трафик DNS к серверам DNS, определенным на ASA, позволен. Эта установка настроена в групповой политике.

  • Стандартный DNS — все запросы DNS проходят через серверы DNS, определенные ASA и, в случае отрицательного ответа, могли бы также перейти к серверам DNS, настроенным на физическом адаптере.
  • Примечание. Команда split-tunnel-all-dns была сначала внедрена в Версии ASA 8.2 (5). Перед этой версией вы могли только сделать split-dns или стандартного dns.

    Во всех случаях запросы DNS, определенные для прохождения через туннеля, переходят к любым серверам DNS, определенным на ASA. В частности если нет никаких серверов DNS, определенных на ASA, то параметры настройки DNS являются пробелом для туннеля. Это также означает, что, идеально, если вам не определяли split-DNS, тогда все запросы DNS передаются серверу DNS, определенному ASA. Однако в действительности способы поведения, описанные в этом документе, могут быть другими, зависеть от операционной системы.

    Примечание. Избегайте использования NSLookup при тестировании разрешения имен у клиента. Вместо этого положитесь на браузер или используйте эхо-запрос. Это вызвано тем, что NSLookup не полагается на Распознавателя DNS операционной системы (OS), и поэтому, AnyConnect не вызывает DNS, запрашивают через некоторый интерфейс. Это только позволяет его или отклоняет его, согласно конфигурации split-DNS. Чтобы вынудить Распознавателя DNS попробовать приемлемый сервер DNS за тот запрос, важно, чтобы тестирование split-DNS было только выполнено с приложениями, которые полагаются на собственного Распознавателя DNS для разрешения доменного имени. Например, все приложения кроме NSLookup, Выройте, и подобные приложения, которые обрабатывают Разрешение DNS.

    Истинный в сравнении с Split-DNS оптимального уровня

    Выпуск 2.4 AnyConnect поддерживает Нейтрализацию Split-DNS (split-DNS оптимального уровня), который не является истинным split-DNS, найденным в прежнем Клиенте IPSEC. Если запрос совпадает с доменом split-DNS, AnyConnect позволяет запросу быть туннелированным в к ASA. Если сервер не может решить имя хоста, Распознаватель DNS продолжает и передает тот же запрос серверу DNS, сопоставленному с физическим интерфейсом. С другой стороны, если запрос не совпадает любой из доменов split-DNS, AnyConnect не туннелирует он в к ASA. Вместо этого это сборки DNS — ответ так, чтобы Распознаватель DNS переключился и передал запрос серверу DNS, сопоставленному с физическим интерфейсом. Именно поэтому эту функцию не называют split-DNS, но нейтрализацией DNS для разделенного туннелирования. Другими словами, мало того, что AnyConnect гарантирует, который только запрашивает, в котором туннелированы целевые домены split-DNS, это также полагается на поведение Распознавателя DNS клиентской операционной системы для разрешения имени хоста.

    Это повышает проблемы безопасности вследствие потенциальной утечки названия личного домена. Например, когда сервер имени DNS VPN не мог решить запрос DNS, собственный DNS — клиент может передать запрос за названием личного домена к общему серверу DNS в частности.

    Обратитесь к дефекту CSCtn14578, в настоящее время решенный на Microsoft (MS) Windows только, с Версии 3.0.4235. Решение внедряет истинного split-DNS; это строго делает запрос настроенных доменных имен, которые совпадают и позволены серверам DNS VPN. Все другие запросы только позволены другим серверам DNS, таким как настроенные на физическом адаптере (ах).

    “Туннель все” и “Туннель весь DNS”

    Когда разделенное туннелирование отключено (туннель — вся конфигурация), трафик DNS позволен строго через туннель. Точно так же, когда туннель вся Конфигурация DNS, которая передает все Поиски DNS через туннель, настроен в групповой политике, вместе с некоторым типом разделенного туннелирования, трафик DNS позволен строго через туннель.

    Это является непротиворечивым через платформы с этими предупреждениями на MS Windows:

    Когда любой туннеля — все или туннель весь DNS настроен, AnyConnect позволяет трафик DNS строго серверам DNS, настроенным на безопасном шлюзе (был применен к адаптеру VPN). Это — улучшение безопасности, внедренное вместе с ранее упомянутым истинным решением для split-dns.

    Если это оказывается проблематичным в определенных, некоторый сценариях (например, обновление/запросы регистрации DNS должно быть передано серверам DNS не-VPN), двухступенчатое временное решение:

    1. Если текущая конфигурация является туннелем — все: включите разделение — исключают туннелирование, любое поддельный одно разделение хоста — сеть exclude работает, такие как локальный для канала адрес.
    2. Гарантируйте, что туннелируют, весь DNS не настроен в групповой политике.

    Вопрос Производительности DNS, решенный в Версии 3.0.4325 AnyConnect

    Эта специфичная для MS Windows проблема главным образом распространена при этих условиях:

    • Настройка маршрутизатора Дом: это, где DNS и серверам DHCP назначают тот же IP-адрес (AnyConnect создает необходимый маршрут к серверу DHCP);
    • Большое число Доменов DNS находится в групповой политике;
    • Tunnel — вся конфигурация;
    • Разрешение имен, выполненное неквалифицированным именем хоста, которое подразумевает, что преобразователь должен попробовать много суффиксов DNS на всех доступных серверах DNS до одно соответствующее для делавшего запрос имени хоста, предпринято.
    Читайте также:  Не работает sber pay huawei p40

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

    Эта проблема решена в Версии 3.0.4325 (комбинация идентификатора ошибки Cisco CSCtq02141 и CSCtn14578, вместе с введением ранее упомянутого истинного решения для split-dns).

    Однако, если обновление не может быть внедрено, то возможные обходной пути:

      Включите разделение — исключают туннелирование для одного поддельного IP-адреса, который позволяет, что локальный DNS запрашивает течь через физический адаптер. Можно использовать адрес от linklocal подсети 169.254.0.0/16, потому что маловероятно, что любое устройство передает трафик одному из тех IP-адресов по VPN. После включения разделения, исключают, не забывают включать доступ локальной сети на клиентском профиле или у клиента непосредственно, и отключать туннель весь DNS. На ASA изменения конфигурации перечислены здесь:

    На клиентском профиле только необходимо добавить эту линию:

    Можно также включить это на за ну клиентской основе в GUI клиента AnyConnect. Переместитесь к Меню предпочтений AnyConnect, и проверьте Включать опцию доступа локальной сети.

    Используйте полные доменные имена (FQDNs) вместо неполных имен хоста для разрешений имен.

  • Используйте другой IP-адрес для сервера DNS на физическом интерфейсе.
  • Как заключает каждую сделку операционной системы с DNS?

    Существует различие в способе, которым другой DNS маркера OSs ищет когда использующийся с разделенным туннелированием (без split-DNS) для AnyConnect.

    MS Windows

    На MS Windows параметры настройки DNS поинтерфейсны. Это означает, что, если разделенное туннелирование используется, запросы DNS могут переключиться на серверы DNS физического адаптера, если запрос отказал на адаптере VPN-туннеля. Если разделенное туннелирование без split-DNS определено, то и внутреннее и внешнее Разрешение DNS работает, потому что это переключается на внешние серверы DNS.

    Macintosh

    С Macintosh (MAC) параметры настройки DNS являются глобальным. Таким образом, если разделенное туннелирование используется, но split-DNS не используется, для запросов DNS не возможно перейти к серверам DNS за пределами туннеля. Можно только решить внутренне, не внешне. Это задокументировано в идентификаторы ошибок Cisco CSCtf20226 и CSCtz86314. В обоих случаях это временное решение должно решить вопрос:

    • Задайте внешний IP-адрес сервера DNS под групповой политикой и используйте FQDN для запросов Internal DN.
    • Если внешние названия разрешимы через туннель, отключают раздельный DNS путем удаления имен DNS, настроенных в групповой политике под Усовершенствованным> Разделенное туннелирование. Это требует использования FQDN для запросов Internal DN.

    Случай split-DNS был решен в AnyConnect 3.1 с этими предупреждениями:

      Split-DNS должен быть включен для обоих Протоколов «IP» (требует ASA v9.0 или позже).

    Split-DNS должен быть включен для одного Протокола «IP».

    и

      (Если ASA имеет Версию 9.0 или позже: клиентский обходной протокол для другого Протокола «IP», т.е., никакой пул адресов и Клиентский Обходной Протокол включен в групповой политике.
      !— или

  • Если ASA ранее, чем Версия 9.0: никакой пул адресов не настроен для другого Протокола «IP»; это подразумевает, что этот другой Протокол «IP» является IPv6.)
  • Примечание. AnyConnect не изменяет resolv.conf файл, прямой на MAC OS X, а скорее изменяет специфичные для OS X настройки DNS. OS X поддерживает resolv.conf актуальный для обеспечений совместимости. Используйте scutil — команда dns для рассмотрения параметров настройки DNS на OS X.

    iPhone

    IPhone является завершенной противоположностью MAC, и это не то же как MS Windows. Если разделенное туннелирование определено, но split-DNS не определен, то запросы DNS выходят через глобальный определенный сервер DNS. Например, записи домена split-DNS являются обязательными для внутреннего разрешения. Это поведение задокументировано в идентификатор ошибки Cisco CSCtq09624 и установлено в последних 05.02.4038 Версиях для клиента AnyConnect IOS.

    Примечание. Будьте осведомленными запросами DNS iPhone, игнорируют .local домены, задокументированные в идентификатор ошибки Cisco CSCts89292. Инженеры Apple подтверждают, что проблема вызвана функциональностью ОС. Это — разработанное поведение, и Apple подтверждает, что нет никаких, изменяются для него.

    Дополнительные сведения

    • CSCsv34395 — Добавляют поддержку в AnyConnect для того, чтобы проксировать FQDN к серверу DHCP
    • CSCtn14578 — AnyConnect для поддержки истинного раздельного DNS; не нейтрализация
    • CSCtq02141 — проблема DNS AnyConnect, когда DNS ISP находится в той же подсети как Общий IP
    • CSCtn14578 — AnyConnect для поддержки истинного раздельного DNS; не нейтрализация
    • CSCtf20226 — Делают DNS AnyConnect с поведением разделения туннеля для Mac тем же как окна
    • CSCtz86314 — Mac: DNS делает запрос неправильно не передаваемый через туннель с split-DNS
    • CSCtq09624 — Делают DNS iPhone AnyConnect с поведением разделенного туннелирования тем же как Windows
    • CSCts89292 — AC для запросов DNS iPhone игнорирует.local домены
    • Cisco IOS Firewall
    • Cisco Systems – техническая поддержка и документация
    Читайте также:  Не работает во время родов

    Связанные обсуждения сообщества поддержки Cisco

    В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.

    Источник

    AnyСonnect и пересечение адресных пространств

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

    Перечисленные выше недостатки актуальны абсолютно для всех удалённых пользователей. Если даже у пользователя локальная сеть отлична от корпоративных сетей и пересечение адресных пространств не происходит. Всё равно весь пользовательский трафик будет туннелироваться в рамках сессии 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-прокси серверы. Но на практике, данным требованием многие пренебрегают;
    • Для пользователей, у которых нет пересечения адресных пространств с ЦО, доступ в локальную сеть работает без проблем.
    Читайте также:  Импульсный блок питания 12в не работает

    Недостатки второго варианта:

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

    Третий вариант — использование политик Split tunneling и правил NAT. Когда сетевой инженер слышит фразу «пересечение адресных пространств», наверное, первое что приходит в голову – разрешить конфликт с помощью трансляций сетевых адресов. Рассмотрим, как это можно настроить на ASA в случае подключения удалённых пользователей.

    Предположим, наша задача организовать доступ таким образом, чтобы даже у пользователей, имеющих пересечение адресного пространства, всегда работал доступ как в конфликтную сеть ЦО, так и в собственную локальную сеть. Для этого нам потребуется транслировать конфликтную сеть ЦО в другую сеть для удалённых пользователей. Например, конфликтная сеть 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 представлен на рисунке ниже:

    В данном примере сервер «Application Server» с внутренним IP-адресом 10.1.1.100 опубликован в Интернет под публичным адресом 198.51.100.100. На корпоративном DNS-сервере существует A-запись для ресурса данного сервера www. abc.ru A Rcrd = 10.1.1.100. Функция DNS doctoring, включённая на ASA, приводит к автоматическому изменению A-записи, когда DNS-ответ проходит через ASA. В DNS-ответе происходит замена внутреннего IP-адреса сервера на публичный IP-адрес, доступный из сети Интернет.

    Замечание 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 в порядке конфигурации

    Секция 2. Network Object NAT

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

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

    Приведу пример. Для организации выхода в Интернет из конфликтной сети ЦО, как правило, требуется наличие соответствующего правила 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 необходимо модифицировать правила трансляции адресов, касающиеся конфликтных сетей.

    Заключение

    В данной заметке я рассмотрел три варианта настройки подключений удалённых пользователей с помощью клиента Cisco Anyconnect к МСЭ Cisco ASA:

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

    Для каждого варианта постарался рассмотреть работу удалённого доступа в случае пересечения адресных пространств и выделить особенности каждого варианта.

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

    Источник

    Adblock
    detector