Привет 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
- Static
- 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.
Для каждого варианта постарался рассмотреть работу удалённого доступа в случае пересечения адресных пространств и выделить особенности каждого варианта.
Жду Ваши комментарии. Может быть, кто-то сможет поделиться своим опытом или другим способом решения проблемы пересечения адресных пространств.
Автор: CBS
