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:

object network anyconnect-pool
 subnet 192.168.3.64 255.255.255.248
 nat (outside,outside) dynamic interface

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

Плюсы первого варианта:

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

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

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

Перечисленные выше недостатки актуальны абсолютно для всех удалённых пользователей. Если даже у пользователя локальная сеть отлична от корпоративных сетей и пересечение адресных пространств не происходит. Всё равно весь пользовательский трафик будет туннелироваться в рамках сессии AnyConnect.

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

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

# Описываем объекты
object network subnet1
 subnet 192.168.0.0 255.255.255.0
object network subnet2
 subnet 192.168.1.0 255.255.255.0
object-group network enterprise
 network-object object subnet1
 network-object object subnet2

# Описываем список доступа
access-list acl-split-tunnel extended permit ip object-group enterprise any

# Включаем политику Split tunneling Split Include в групповую политику и применяем политику к профилю соединения
group-policy GroupPolicy1 attributes
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value acl-split-tunnel
tunnel-group TEST general-attributes
 default-group-policy GroupPolicy1

В случае пересечения адресных пространств удалённый пользователь попросту теряет доступ к своей локальной сети. То есть, если у пользователя локальная сеть 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 помогает достичь универсальности: не зависимо от того, какая именно сеть у пользователя является локальной, доступ к ней всегда будет работать.

# Описываем диапазоны публичных адресов
object network range1
 range 0.0.0.0 9.255.255.255
object network range2
 range 11.0.0.0 172.15.255.255
object network range3
 range 172.32.0.0 192.167.255.255
object network range4
 range 192.169.0.0 255.255.255.255
object-group network net-exclude-RFC1918
 network-object object range1
 network-object object range2
 network-object object range3
 network-object object range4

# Описываем список доступа
access-list acl-exclude-tunnel extended permit ip object-group net-exclude-RFC1918 any
access-list acl-exclude-tunnel extended permit ip host 0.0.0.0 any	# запись “host 0.0.0.0” эквивалентна записи “0.0.0.0 255.255.255.255”

# Включаем политику Split tunneling Split Exclude в групповую политику и применяем политику к профилю соединения
group-policy GroupPolicy1 attributes
 split-tunnel-policy excludespecified
 split-tunnel-network-list value acl-exclude-tunnel
tunnel-group TEST general-attributes
 default-group-policy GroupPolicy1

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

# Конфликтная сеть ЦО
object network net-1
 subnet 192.168.1.0 255.255.255.0

# Сеть, в которую будем транслировать конфликтную сеть ЦО
object network net-25
 subnet 192.168.25.0 255.255.255.0

# Пул адресов, выдаваемых при подключении по Anyconnect
object network anyconnect-pool
 subnet 192.168.3.64 255.255.255.248

# Правило трансляции. Транслировать конфликтную сеть ЦО в новую сеть, если трафик идёт в сторону удалённого пользователя
nat (inside,outside) source static net-1 net-25 destination static anyconnect-pool anyconnect-pool no-proxy-arp

Конечно, работать с 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:

policy-map global_policy
  class inspection_default
    inspect dns

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

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

# Пока в правиле нет destination static, опция dns присутствует
nat (inside,outside) source static net-1 net-25 ?

configure mode commands/options:
  description     Specify NAT rule description
  destination     Destination NAT parameters
# DNS doctoring можно включить
  dns             Use the created xlate to rewrite DNS record
  inactive        Disable a NAT rule
  no-proxy-arp    Disable proxy ARP on egress interface
  route-lookup    Perform route lookup for this rule
  service         NAT service parameters
  unidirectional  Enable per-session NAT
  <cr>

# Как только добавляем destination static опция dns пропадает
nat (inside,outside) source static net-1 net-25 destination static anyconnect-pool anyconnect-pool ?         

configure mode commands/options:
  description     Specify NAT rule description
  inactive        Disable a NAT rule
  net-to-net      Net to net mapping of IPv4 to IPv6
  no-proxy-arp    Disable proxy ARP on egress interface
  route-lookup    Perform route lookup for this rule
  service         NAT service parameters
  unidirectional  Enable per-session NAT
  <cr>

Данное поведение задокументировано на сайте 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 и т.д. Пример настройки:

# Описываем диапазоны публичных адресов
object network range1
 range 0.0.0.0 9.255.255.255
object network range2
 range 11.0.0.0 172.15.255.255
object network range3
 range 172.32.0.0 192.167.255.255
object network range4
 range 192.169.0.0 255.255.255.255
object-group network net-exclude-RFC1918
 network-object object range1
 network-object object range2
 network-object object range3

# Конфигурируем правило dynamic pat
# Правило dynamic pat будет срабатывать только при обращении к публичным адресам
nat (inside,outside) 1 source dynamic net-1 interface destination static net-exclude-RFC1918 net-exclude-RFC1918

# Конфигурируем правило трансляции сети 192.168.1.0/24 в 192.168.25.0/24 ниже правила dynamic pat
# Не забываем указать опцию dns
nat (inside,outside) 2 source static net-1 net-25 dns no-proxy-arp

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

# Описываем список доступа
access-list acl-split-tunnel extended permit ip object-group net-25 any

# Включаем политику Split tunneling Split Include в групповую политику и применяем политику к профилю соединения
group-policy GroupPolicy1 attributes
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value acl-split-tunnel
tunnel-group TEST general-attributes
 default-group-policy GroupPolicy1

Преимущества третьего варианта:

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

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

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

Заключение

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

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

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

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