Виртуальная частная сеть (Virtual Private Network, VPN) является чрезвычайно широким понятием. В «Википедии» дается следующее определение: «VPN — обобщенное название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернета)». Что значит «сеть поверх других сетей» и, самое главное, кому и зачем это нужно? Попробуем разобраться.
Для примера рассмотрим общедоступную сеть Интернет. Допустим, нам требуется организовать соединение «точка – точка» между территориально разнесенными объектами, каждый из которых подключен к сети Интернет. Конечно, можно попросить монтажников проложить новые кабели между объектами и организовать по ним соединение «точка – точка». Но такое решение, скорее всего, окажется неоправданно дорогим.
Гораздо дешевле и целесообразнее использовать уже существующую сеть Интернет, а также часть ее стека протоколов, например от физического уровня до сетевого. Выше сетевого уровня можно внедрить часть стека своей сети, например от канального
до прикладного уровня. Тем самым мы построим виртуальную частную сеть поверх публичной сети Интернет, или, другими словами, создадим логический туннель передачи данных поверх существующей сетевой инфраструктуры. Данный результат достигается с привлечением механизма инкапсуляции.
Как говорилось ранее, VPN — это целый класс технологий. Разные технологии VPN предусматривают внедрение разных частей стека создаваемой частной сети на разных уровнях стека существующей публичной сети. Кроме того, различные технологии VPN позволяют реализовать специфические функции для организуемой частной сети. К ним относятся возможности аутентификации, проверки целостности, сокрытия передаваемых данных и многое другое.
Наиболее распространенной технологией построения защищенных соединений VPN через открытые публичные сети является IPsec. Она используется для организации шифруемых соединений между площадками и при удаленном доступе поверх публичных сетей, характеризующихся низким уровнем доверия (к таковым относится, например, Интернет). Необходимо отметить, что IPsec используется как сам по себе, так и в составе других технологий — VTI, DMVPN и т. д.
Наверняка многие сетевые администраторы и инженеры при настройке IPsec сталкивались с ситуацией «все настроено, а туннель не поднимается» или «туннель поднят, а трафик не передается». Мы хотим прежде всего выделить и попытаться систематизировать причины проблем, возникающих в ходе применения IPsec VPN, а также предложить некоторые рекомендации по их устранению.
ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАБОТЫ IPSEC
Прежде чем переходить к практике использования технологии IPsec, следует уделить внимание теоретическим аспектам. Подробное описание работы протоколов IPsec без труда можно найти в открытых источниках, поэтому отметим только основные общие детали.
Набор протоколов IPsec включает такие протоколы, как IKE для обмена данными с целью построения защищенного соединения, а также AH и ESP, которые обеспечивают аутентификацию, целостность и конфиденциальность передаваемых данных.
Протокол IKE опирается на протоколы ISAKMP, Oakley и SKEME. Процесс установления защищенного соединения разбивается на две фазы. На первой организуется первичное защищенное соединение, по которому осуществляется дальнейший обмен служебными пакетами, а также аутентификация устройств. Во время второй фазы происходит согласование параметров защиты трафика, который затем будет передаваться по соединению VPN.
Первая фаза IKE может проходить в двух режимах — основном и агрессивном. Основной режим предполагает обмен шестью сообщениями. Первые два сообщения служат для согласования параметров защиты соединения IKE, а именно: алгоритма шифрования, хеш-функции, алгоритма Диффи – Хеллмана, а также механизма аутентификации. Инициатор соединения отправляет все допустимые варианты параметров в первом сообщении. Ответная сторона выбирает наиболее подходящий набор допустимых параметров и подтверждает их во втором сообщении. Данные параметры на каждой стороне записываются в базу IKE Security Association (SA). Таким образом, IKE SA на каждом устройстве полностью описывает защищенное соединение.
В двух последующих сообщениях по открытому каналу связи согласуется общий секретный ключ с использованием алгоритма Диффи – Хеллмана. Этот ключ применяется для защиты данных (шифрования), передаваемых при авторизации сторон. Завершив согласование, устройства передают дальнейшие сообщения в зашифрованном виде. По результатам обмена пятым и шестым сообщениями происходит взаимная аутентификация сторон.
Агрессивный режим предполагает отправку всего трех пакетов, что ускоряет процесс установления защищенного соединения, но снижает уровень безопасности. В первом сообщении инициатор передает все параметры соединения, а также параметры для согласования общего ключа с использованием алгоритма Диффи – Хеллмана. Ответная сторона проверяет параметры соединения, вычисляет общий секретный ключ и генерирует хеш-функцию для дальнейшей аутентификации. Все эти данные отправляются во втором, ответном сообщении. Получив его, инициатор вычисляет общий секретный ключ, проверяет аутентификационные данные удаленной стороны и в ответ отправляет свои.
По результатам первой фазы IKE стороны взаимно авторизуют друг друга, так что теперь они могут переходить ко второй фазе для согласования параметров защиты — непосредственно для передаваемых данных в рамках соединения VPN. На этом этапе стороны согласуют алгоритмы шифрования и хеш-функции, а также сеансовые ключи для непосредственного шифрования передаваемых данных. Кроме того, они договариваются между собой о том, какой именно трафик необходимо шифровать (об этом речь пойдет далее).
Как уже было отмечено, для защиты данных используются два протокола: AH и ESP, параметры которых согласуются на второй фазе. Протокол AH обеспечивает аутентификацию и целостность данных, а протокол ESP — аутентификацию, целостность и конфиденциальность данных (выбор одного из протоколов или одновременно обоих определяется потребностями защиты IP-пакетов).
Оба протокола могут использоваться в двух режимах — транспортном и туннельном. В первом случае заголовки вплоть до сетевого уровня не изменяются, то есть IP-адреса отправителя и получателя не шифруются. Во втором случае система добавляет к старому заголовку IP новый, тем самым скрывая настоящие адреса отправителя и получателя. При использовании протокола IPSec самого по себе чаще всего используется туннельный режим.
Отдельно стоит остановиться на вопросе сетевого представления сеанса VPN. Данные протокола IKE инкапсулируются в дейтаграмму UDP с использованием порта 500. Данные протоколов AH и ESP вставляются по умолчанию на уровне IP, то есть транспортный уровень не задействуется. Если по маршруту движения пакета есть узел, где производится трансляция адресов, то протокол IKE позволяет установить этот факт и в дальнейшем инкапсулировать протоколы AH и ESP в дейтаграммы UDP посредством порта 4500. Такая функция называется NAT Traversal (NAT-T).
ОТ ТЕОРИИ К ПРАКТИКЕ
С какими же трудностями приходится сталкиваться при организации соединений VPN на базе IPSec? Помимо технических вопросов, о которых пойдет речь далее, при использовании таких решений возникают вопросы, связанные с лицензионной политикой: начиная от ввоза на территорию Российской Федерации криптосодержащих средств и заканчивая их внедрением и эксплуатацией. В рамках данной статьи эти вопросы не рассматриваются.
Основные трудности при работе с соединениями VPN можно разделить на несколько групп. В первую входят проблемы из-за некорректной настройки устройств, во вторую — трудности при работе с каналами связи, в третью — плохое взаимодействие устройств различных производителей, в четвертую — системные ошибки в работе оборудования (другими словами, «баги»).
В нашей практике для создания соединений VPN чаще всего приходится использовать оборудование компании Cisco Systems, поэтому именно ему будет уделено основное внимание. Если проблемы первой и второй группы в целом не зависят от марки оборудования, то те, что относятся к третьей и четвертой группам, полностью ею определяются.
ПРОБЛЕМЫ ПРИ НАСТРОЙКЕ
Итак, в чем выражается некорректная настройка устройств?
1. Параметры фазы 1 и фазы 2. Как было отмечено ранее, при установлении соединения IPSec каждая сторона предлагает свои параметры соединения, такие как алгоритм шифрования, хеш-функция, группа Диффи – Хеллмана для первой фазы IKE и т. д. Если на каждой стороне они совпадают, соединение IPSec между устройствами будет установлено. Если же на устройствах настроить различные параметры, соединение IPSec между ними не заработает.
Для диагностирования данной проблемы можно использовать два метода. Во-первых, еще раз проверить все настройки, а именно сопоставить параметры конфигурации фазы 1 и фазы 2 для протокола IKE на обоих устройствах. Не самый, конечно, профессиональный подход, но иногда он позволяет быстро локализовать проблему. Главное, чтобы не «замылился» глаз, но в этом случае всегда можно обратиться за помощью к коллеге.
Если за удаленную сторону отвечает другой специалист, сопоставить параметры настройки существенно сложнее. И здесь приходит на помощь второй вариант диагностики — запуск трассировки протокола IPSec. На оборудовании Cisco такая трассировка выполняется по команде debug crypto. Безусловно, для чтения выводимой информации необходимо обладать как пониманием работы протоколов IPSec (особенно первой и второй фаз IKE), так и умением читать выводимые данные. Впрочем, информацию по обоим вопросам можно найти в открытом доступе.
2. Выбор трафика для VPN. А теперь попробуем ответить на заданный выше вопрос о том, какой трафик подлежит шифрованию, — в терминах компании Cisco это «интересный трафик» (interesting traffic). Очень часто проблема возникает именно при его выборе на второй фазе IKE.
Соединение IPSec при использовании оборудования Cisco будет установлено, когда определения «интересного трафика» совпадают с обеих сторон (с точностью до зеркальной перестановки). Иначе говоря, если с одной стороны, например, указывается, что шифрованию подлежит трафик, передаваемый из сети 192.168.20.0/24 в сеть 172.28.5.0/25, то с другой стороны должно быть задано обратное — из сети 172.28.5.0/25 в сеть 192.168.20.0/24. Если есть хотя бы малейшее расхождение (другая сеть или маска сети), соединение IPSec установлено не будет.
Стоит отметить, что при наличии частичного пересечения соединение VPN будет установлено. Например, на одной стороне настроено правило, что следует шифровать трафик из сетей 192.168.20.0/24 и 192.168.21.0/24 в сеть 172.28.5.0/24. А на второй указано, что это необходимо делать только для трафика из сети 172.28.5.0/24 в сеть 192.168.20.0/24.
3. Функции устройства, препятствующие VPN (NAT, Same-Security-Traffic и т. д.). Достаточно часто возникает ситуация, когда соединение VPN установлено, но трафик по нему не передается. Причин может быть несколько. Все они связаны со спецификой взаимодействия IPSec и других функций сетевого оборудования.
В первую очередь рекомендуем обратить внимание на совместную работу функций NAT и IPSec, если они настроены на одном устройстве. Трафик может не попадать в соединение VPN по причине трансляции сетевых адресов, если, например, администратор забудет исключить трафик, который должен направляться в VPN, из правила трансляции адресов (функции NAT). Стоит отметить, что на оборудовании Cisco функция NAT выполняется до функции шифрования. В этом случае адрес отправителя заменяется на новый адрес в соответствии с заданными правилами NAT. После этого нужный нам трафик перестает отвечать критерию «интересного трафика», то есть подлежащего шифрованию.
Еще один нюанс работы соединений IPSec проявляется на оборудовании Cisco ASA, если трафик из одного соединения VPN требуется передавать через другое соединение VPN. Например, удаленный пользователь подключается к центральному офису по технологии Remote-Access VPN, после чего ему необходимо обратиться к ресурсам другого удаленного офиса. Между центральным и удаленным офисами настроено соединение Site-to-Site VPN. Таким образом, трафик удаленного пользователя сначала передается по туннелю IPSec до центрального офиса, а далее уже по туннелю IPSec до другого офиса.
По умолчанию оборудование Cisco ASA не позволяет передавать трафик через тот же интерфейс, на который этот трафик поступил. Поэтому при тестировании каждое в отдельности соединение VPN оказывается функциональным, а общая конфигурация — неработоспособной. Для решения данной задачи нужно настроить разрешение взаимодействия через один и тот же интерфейс на Cisco ASA. Для этого можно использовать команду «same-security-traffic permit intra-interface».
ПРОБЛЕМЫ В КАНАЛАХ СВЯЗИ
К проблемам, связанным с некорректной работой каналов связи, можно отнести блокировку промежуточным оборудованием трафика, передаваемого через определенные порты и по определенным протоколам, ограничения на максимальный размер кадра (MTU) и вопросы фильтрации трафика на собственном оборудовании.
О возможных проблемах с блокировкой трафика и размером MTU при использовании технологий виртуальных частных сетей мы говорили ранее (см. статью «Подключение к интернет-провайдеру: проблемы и решения» в июньском номере «Журнала сетевых решений/LAN» за этот год). Здесь же хотелось бы отметить, что иногда трафик блокируется подконтрольным пользователю оборудованием, особенно когда последнее (например, маршрутизаторы Cisco) применяется не только для построения соединений IPSec, но и для межсетевого экранирования. Необходимо помнить, что для работы соединения IPSec должен быть разрешен входящий трафик от удаленной стороны по протоколу UDP через порт 500, а также по протоколу ESP или AH. В случае срабатывания технологии NAT-T вместо ESP или AH нужно открыть UDP 4500, через который эти протоколы передаются инкапсулированными в дейтаграммы UDP. При использовании оборудования Cisco ASA трафик соединения IPSec всегда разрешен и не блокируется межсетевым экраном.
Отдельного внимания заслуживает вопрос фильтрации дешифрованного трафика. По умолчанию в новых версиях программного обеспечения, установленного на маршрутизаторах Cisco, списки контроля доступа, заданные для внешних сетевых интерфейсов, не применяются к трафику, поступившему по соединению IPSec. Но так было не всегда. До версии 12.3 (8) T фильтрация трафика IPSec по спискам доступа осуществлялась в два этапа: сначала проверялись зашифрованные пакеты, а затем дешифрованные. Конечно, сейчас столь «древнее» оборудование встречается редко, но об этом обстоятельстве стоит помнить.
На межсетевых экранах Cisco ASA есть отдельная функция Sysopt Connection Permit-VPN, включенная по умолчанию начиная с версии 7.0 (1), которая как раз и регулирует проверку дешифрованного трафика на соответствие спискам доступа. Если она активна, дешифрованный трафик совсем не фильтруется списками доступа. Чтобы посмотреть, включена ли данная опция на ASA, можно использовать show run all. Если ее выключить, дешифрованный трафик попадает под действие всех списков доступа, активированных на пути следования пакетов на интерфейсах устройства.
Приведем пример. Трафик из VPN IPsec попадает сначала на внешний (outside) интерфейс ASA, а затем передается на внутренний (inside). Тогда при отключении рассматриваемой опции пакеты проверяются по списку доступа на внешнем интерфейсе во входящем направлении (in) и по списку доступа на внутреннем интерфейсе в исходящем направлении (out).
Кроме того, при отключении рассматриваемой опции дешифрованный трафик попадает под действие межсетевого экранирования на ASA. Напомним, по умолчанию (если никакие списки доступа не настроены) ASA разрешает прохождение всего трафика из зоны с большим уровнем доверия в зону с меньшим уровнем доверия и блокирует весь трафик из зоны с меньшим уровнем доверия в зону с большим уровнем доверия. При этом для каждого сеанса МСЭ ASA создает ярлык (shortcut) соединения и автоматически разрешает ответный трафик, относящийся к ранее установленному соединению.
Таким образом, если требуется создать Site-to-Site VPN на базе оборудования Cisco ASA, но доверие к партнеру отсутствует и хочется оградиться от его сети полноценным МСЭ, выключение опции Sysopt Connection Permit-VPN — неплохая идея. Недостаток данного решения заключается в том, что эта опция включается/выключается глобально на устройстве и, соответственно, влияет на все соединения IPsec.
Трафик в направлении изнутри вовне (inside -> outside), подлежащий дальнейшему шифрованию на ASA, не попадает под влияние рассматриваемой опции. Соответственно, его можно фильтровать как с помощью списка доступа на внутреннем интерфейсе во входящем направлении, так и посредством списка доступа на внешнем интерфейсе в исходящем направлении. Заметим, если сеанс инициирован из удаленной подсети, то описанная фильтрация не будет влиять на ответные пакеты из внутренней сети, поскольку в этом случае применяются обычные правила МСЭ.
Зашифрованный трафик, приходящий на ASA для дальнейшей дешифрации, разрешен всегда.
ПРОБЛЕМЫ ПРИ ВЗАИМОДЕЙСТВИИ УСТРОЙСТВ РАЗНЫХ ПРОИЗВОДИТЕЛЕЙ
При настройке соединений VPN между оборудованием Cisco и недорогими устройствами других производителей сетевого оборудования (а также Cisco SA500) может возникнуть затруднение, на которое мы хотели бы обратить внимание.
Обычно для настройки таких недорогих устройств используется Web-интерфейс. В нем заранее предопределены поля для заполнения конфигурации. Иногда поле, где указывается подсеть, трафик из которой должен шифроваться, всего одно. Если таких подсетей две или более, то ввести о них информацию невозможно. Эта проблема устраняется путем создания на таких устройствах двух или более туннелей VPN. Хотя оборудование Cisco и позволяет указывать несколько подсетей для одного туннеля VPN, но, когда с другой стороны установлено оборудование без такой поддержки, настройка нескольких криптокарт является единственно верным решением.
При настройке Site-to-Site IPsec VPN между устройствами различных производителей могут возникать конфликты из-за различий в реализации протоколов IPsec на разных устройствах. Вот два наиболее интересных случая из нашей практики.
1. Cisco и MikroTik. Формулировка задачи была простая: настроить IPsec между площадками клиента и его контрагента. На стороне клиента был установлен Cisco ASA, на удаленной стороне — сетевое устройство производителя MikroTik. В последнем случае все настройки выполнялись специалистами контрагента, для чего были согласованы необходимые параметры IPsec, а именно параметры первой и второй фаз и трафик, подлежащий шифрованию. Среди прочих параметров первой фазы было предложено использовать группу Диффи – Хеллмана № 5. Данное решение должно было повысить криптостойкость канала обмена ключами на первой фазе. Такую же группу планировали использовать для механизма Perfect Forward Secrecy (PFS) во время второй фазы.
Далее события развивались стандартным образом: «все настроили, ничего не работает». После неоднократной проверки параметров первой и второй фаз на обеих сторонах инженеры пришли к выводу, что настройки выполнены корректно. В качестве следующего шага по выявлению проблемы была предпринята трассировка IPSec (Debug Crypto). Внимание привлекло сообщение в выводе трассировки, содержащее следующие слова: «Phase 1 failure: Mismatched attribute types for class Group Description: Rcv’d: Unknown Cfg’d: Group 5». Из текста сообщения видно, что Cisco не может распознать группу Диффи – Хеллмана, которую предлагает удаленная сторона.
Выяснилось, что оборудование MikroTik обозначает группу Диффи – Хеллмана № 5 как группу для генерации ключа с длиной 3072 бит (что, вообще говоря, не соответствует ее обозначению в RFC — http://tools.ietf.org/html/rfc3526#section-4). Оборудование Cisco, напротив, в соответствии с RFC идентифицирует эту группу как группу для генерации ключа с длиной 1536 бит.
Для оборудования Cisco и MikroTik длина генерируемого ключа совпадала только для групп 1 и 2. Как только параметры первой фазы были заменены на группу 2 на устройствах обеих площадок, туннель заработал.
Отсюда напрашивается вывод: не все производители реализуют IPsec в полном соответствии со стандартами, так что инженер должен быть к этому готов при настройке IPsec между устройствами различных производителей.
2. Cisco и ZyXEL. Формулировка задачи такая же: настроить IPsec между площадками клиента и его контрагента, только на стороне контрагента было установлено оборудование ZyXEL. В общем и целом данная ситуация попадает в категорию проблем № 1 «Проблемы при настройке», потому что, как выяснилось впоследствии, трафик не передавался по туннелю из-за того, что на удаленной стороне был неверно определен трафик, подлежащий шифрованию (interesting traffic). Однако мы поместили эту ситуацию в текущий раздел, чтобы заострить внимание на том, как по-разному ведут себя устройства различных производителей. Ранее указывалось, что при настройке IPsec VPN, например между двумя устройствами Cisco, необходимо зеркальное совпадение параметра Interesting Traffic.
В случае с ZyXEL, напротив, туннель создавался даже в том случае, когда на удаленной стороне была предложена для шифрования несуществующая подсеть. Когда инициатором создания туннеля выступало оборудование ZyXEL, Cisco ASA послушно создавал для туннеля IPsec Security Association, в которой указывал эту самую «фантомную» подсеть. Для инженера Cisco такая ситуация выглядела весьма странно, ведь во всей конфигурации межсетевого экрана не обнаруживалось ни одного упоминания про эту подсеть. Конечно, проблема сразу решилась, когда на удаленной стороне корректно настроили Interesting Traffic. Но на диагностику проблемы пришлось все же выделить дополнительное время, так как из трассировки IPsec (Debug Crypto) ничего информативного выявить не удалось — туннель поднимался без проблем.
Вывод аналогичен случаю с MikroTik: не все производители реализуют IPsec одинаково.
СИСТЕМНЫЕ ОШИБКИ В РАБОТЕ ОБОРУДОВАНИЯ
К сожалению, любое, даже самое надежное и дорогое, оборудование не может гарантировать идеальную бесперебойную работу всех поддерживаемых сервисов. Иногда включенные и настроенные функции не работают так, как заявил производитель, а в некоторых случаях работа одного сервиса нарушается из-за активации другого сервиса или новой функции.
Следует заметить, что корректная работа IPsec VPN зависит не только от правильности реализации входящих в IPsec протоколов, но и от корректности взаимодействия IPsec с прочими технологиями, используемыми в устройстве. Например, чтобы пакеты успешно направлялись в IPsecVPN, необходимо корректное взаимодействие сервиса IPsec с технологиями маршрутизации, фильтрации, межсетевого экранирования, NAT и многими другими.
Ярким примером системной ошибки служит некорректная работа IPsec VPN (а именно засорение VPN (trashing)) на Cisco ASA при смене маршрута. Ошибка проявлялась, когда ASA был подключен к двум интернет-провайдерам и настроен на автоматическое переключение между ними с помощью функции мониторинга SLA и объекта Track. При этом Site-to-Site IPsec для связи c удаленным офисом настроен на интерфейсах обоих провайдеров. Такая схема весьма распространена, поскольку в таком случае при отказе канала, ведущего к основному интернет-провайдеру, шлюз автоматически переключается на резервный, а после восстановления основного все возвращается к исходным настройкам. В отличие от маршрутизаторов Cisco, на ASA данный функционал реализован в несколько урезанном виде и отсутствует возможность настройки задержки переключения маршрута (delay up/down): как только на последовательность пакетов ICMP Request не поступает ответ, ASA сразу считает, что маршрут недоступен.
Казалось бы, при чем здесь IPsec? Поменялся маршрут, и что с того? На удаленной стороне на устройстве указано два IP-адреса для терминирования IPsec — через основного провайдера ASA и через резервного. Благодаря механизму Deed Peer Detection (isakmp keepalive), удаленная сторона знает, когда основной провайдер у ASA недоступен, и устанавливает IPsec VPN c ASA через резервного провайдера. На практике же оказалось, что при отказе канала основного провайдера и смене маршрута по умолчанию на резервный связь с удаленным офисом через IPsec VPN полностью пропадала — туннель не работал. При этом попытки сбросить туннель на ASA и организовать его заново тоже не приводили к восстановлению связи.
Ситуация прояснилась только после консультации со службой технической поддержки Cisco. В программном обеспечении ASA имеется ряд ошибок. Корень проблемы заключался в следующем. Маршрутизаторы Cisco являются пакетно-ориентированными устройствами, тогда как межсетевые экраны Cisco ASA ориентированы на соединения. ASA принимает решение о том, куда пересылать очередной пакет, опираясь в первую очередь на информацию из таблицы существующих соединений, а не на данные из таблицы маршрутизации. Другими словами, если для какого-либо сеанса ранее уже было создано соединение, при смене маршрута пакеты в рамках открытого сеанса могут по-прежнему направляться по старому маршруту. В программном обеспечении ASA предусмотрены определенные механизмы воздействия на существующие соединения при смене маршрутов. К таким механизмам относятся service resetinbound, service resetoutbound, timeout floating-conn и др. (их рассмотрение представляет собой отдельную тему и выходит за рамки данной статьи).
Как же записи в таблице соединений на ASA влияют на IPsec? Ответ прост: триггером создания новых ассоциаций ISAKMP и IPsec является факт появления на интерфейсе отправителя, к которому применена настройка IPsec, пакета, направленного в этот туннель IPsec. При определенных неблагоприятных ситуациях (о них чуть позже) может сложиться ситуация, когда в таблице соединений ASA часть записей указывает на одного провайдера, а часть — на другого. В таких условиях ASA предпринимает хаотические попытки создать ассоциации ISAKMP и IPsec то на одном интерфейсе, то на другом. При поступлении пакетов в «правильный» IPsec VPN-туннель открывается и по нему начинают передаваться пакеты, но как только приходят пакеты от старых сеансов, для которых существуют «паразитные» соединения на ASA, устройство вынуждено выключать «правильный» туннель и пытаться построить туннель через другой канал. При этом туннель через нерабочий канал зависал в состоянии MM_WAIT_MSG2. Описанную ситуацию называют засорением VPN.
Системные ошибки (или баги), которые приводили к описанным проблемам с IPsec, были связаны в первую очередь с некорректной реализацией в программном обеспечении ASA механизмов, отвечавших за удаление устаревших соединений, для которых указывался несуществующий маршрут. Механизмы воздействия на существующие соединения при смене маршрутов работали корректно для «открытых» соединений, но не всегда для соединений через туннель VPN IPsec. При возникновении описанной ситуации упорядочить работу туннелей IPsec помогала принудительная очистка таблицы соединений на ASA. Особенную сложность в диагностировании данной проблемы представлял тот факт, что она проявлялась непредсказуемо: в какие-то моменты времени «паразитные» соединения разрывались, в какие-то нет, а иногда отсутствовал трафик, приводящий к засорению.
На момент написания статьи описанный баг был устранен. В реализацию IPsec добавлен код, позволяющий отслеживать факт изменения исходящего интерфейса для туннеля. При его смене все затрагиваемые туннели IPsec разрываются принудительно. Cisco настоятельно рекомендует использовать новые версии ПО для топологий с избыточными туннелями IPsec VPN.
В продолжение поднятой темы следует сделать еще одно важное замечание по поводу работы межсетевого экрана Cisco ASA в сетевых топологиях с избыточными туннелями IPsec VPN. На ASA предусматривается возможность указывать две и более точки терминирования туннеля IPsec VPN — например, через основного провайдера удаленной площадки и через резервного. (Речь идет о ситуации, когда для подключения к каждому провайдеру используется выделенное устройство — шлюз VPN.) При запросе на установление туннеля ASA пробует последовательно (в соответствии с их перечислением в конфигурации) подключиться к указанным IP-адресам удаленной площадки. Если обнаруживается, что точка терминирования туннеля недоступна по каким-то причинам (например, отказ провайдера на удаленной стороне), устройство устанавливает VPN ко второй точке (например, через резервного провайдера). Однако при восстановлении доступности первой точки терминирования туннеля и сохранении доступности второй точки туннель останется подключенным ко второй. К сожалению, в отличие от маршрутизаторов Cisco, межсетевой экран Cisco ASA не поддерживает механизма IPsec Preferred Peer.
Кроме того, для описанной схемы туннелей VPN настоятельно рекомендуется настраивать оборудование таким образом, чтобы инициатором установления соединения могло выступать только то устройство, на котором указано несколько точек терминирования туннеля. Устройства на удаленной площадке не должны выступать в качестве инициаторов туннелей IPsec.
ЗАКЛЮЧЕНИЕ
В завершение обсуждения заметим, что далеко не всегда можно однозначно отнести возможные трудности к той или иной группе. Как отмечалось выше, причин может быть очень много. Поэтому процедура диагностики оказывается не такой очевидной, как если бы мы сразу знали, что имеющаяся проблема относится ко второй или, например, третьей группе. На наш взгляд, в реальных условиях эксплуатации сетей при диагностике необходимо придерживаться некоторого алгоритма, когда последовательно исключается каждая группа проблем. При этом начинать следует именно в той последовательности, которую мы рассматривали в данной статье.
Сергей Калашников — технический директор компании «Компьютерные бизнес системы» (CBS), CCIE. С ним можно связаться по адресу: ksg@cbs.ru. Борис Усков — системный инженер компании «Компьютерные бизнес системы» (CBS). С ним можно связаться по адресу: uskov@cbs.ru.