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

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

  • Для пользователей, у которых происходит пересечение адресных пространств с ЦО, теряется доступ в локальную сеть. 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.

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

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

ссылка на оригинал статьи http://habrahabr.ru/post/275517/