В данной статье я бы хотел привести пошаговую инструкцию того как можно быстро развернуть самую масштабируемую на текущий момент схему Remote-Access VPN доступа на базе AnyConnect и Cisco ASA – VPN Load Balancing Cluster. Введение: Многие компании во всем мире ввиду текущей обстановки с COVID-19 предпринимают усилия по переводу своих сотрудников на удаленный режим работы. Ввиду массовости перехода на удаленную работу, критическим образом возрастает нагрузка на имеющиеся VPN шлюзы компаний и требуется очень быстрая возможность их масштабирования. С другой стороны, многие компании вынуждены второпях осваивать с нуля такое понятие как удаленная работа.  Для того чтобы помочь бизнесу реализовать в кратчайшие сроки удобный, безопасный и масштабируемый доступ VPN для сотрудников, компания Cisco предоставляет на срок до 13 недель лицензии на многофункциональный SSL-VPN клиент AnyConnect. Также можно взять ASAv на тест (Виртуальная ASA для гипервизоров VMWare/Hyper-V/KVM и облачных платформ AWS/Azure) у авторизованных партнеров или обратившись к работающим с Вами представителям Cisco. Процедура выписки лицензий AnyConnect COVID-19 описана тут. Я подготовил пошаговую инструкцию простого варианта развертывания VPN Load-Balancing кластера как наиболее масштабируемой технологии VPN. Нижеуказанный пример будет довольно простым с точки зрения применяемых алгоритмов аутентификации и авторизации, но будет хорошим вариантом для быстрого старта (чего сейчас очень многим не хватает) с возможностью углубленной адаптации под свои нужды в процессе развертывания. Краткие сведения: Технология VPN Load Balancing Cluster это не failover и не функция кластеризации в её нативном понимании, данной технологией можно объединять совершенно различные модели ASA (с определенными ограничениями) с целью балансировки нагрузки Remote-Access VPN соединений. Cинхронизация сессий и конфигураций между нодами такого кластера отсутствует, зато возможна автоматическая балансировка нагрузки VPN соединений и обеспечение отказоустойчивости соединений VPN пока не останется хотя бы одной активной ноды в кластере. Нагрузка в кластере балансируется автоматически в зависимости от загруженности нод по количеству VPN сессий. Для отказоустойчивости конкретных нод кластера (если это требуется) можно применять файловер, таким образом, активное соединение будет обрабатываться Primary нодой файловера. Файловер не является необходимым условием обеспечения отказоустойчивости внутри Load-Balancing кластера, сам кластер в случае отказа ноды переведет сессию пользователя на другую живую ноду, однако без сохранения статуса соединения, что как раз обеспечивается файловером. Соответственно можно при необходимости комбинировать эти две технологии.  VPN Load-Balancing кластер может содержать больше двух нод. VPN Load-Balancing кластер поддерживается на ASA 5512-X и выше.  Поскольку каждая ASA в рамках VPN Load-Balancing кластера является независимой единицей с точки зрения проводимых настроек, то все этапы конфигурации мы проводим индивидуально на каждом отдельном устройстве. Подробности технологии тут  Логическая топология приведенного примера:  Первичное развертывание:  Разворачиваем из образа экземпляры ASAv нужных нам шаблонов (ASAv5/10/30/50). Назначаем интерфейсы INSIDE/OUTSIDE на одинаковые VLAN (Outside в своем VLAN, INSIDE в своем, но общем в рамках кластера см. топологию), важном чтобы интерфейсы одного типа находились в одном L2 сегменте. Лицензии: Настраиваем базовый SSL-VPN на каждом шлюзе Далее настраиваем доступ через SSH и ASDM: Для работы ASDM надо сначала скачать его с сайта cisco.com, в моем случае это следующий файл:
 Для работы AnyConnect клиента надо загрузить на каждую ASA образ для каждой используемой десктопной ОС клиента (планируемой к использованию Linux/Windows/MAC) нужен будет файл с Headend Deployment Package в названии:
 Скачанные файлы можно выложить, к примеру, на FTP сервер и закачать на каждую отдельную ASA:
 Настраиваем ASDM и сертификат для VPN-шлюзов SSL-VPN (в продуктиве сертификат рекомендуется использовать доверенный). Установленный FQDN Виртуального адреса кластера (vpn-demo.ashes.cc), а также каждый FQDN ассоциированный с внешним адресом каждой ноды кластера должен разрешаться в внешней зоне DNS на IP адрес интерфейса OUTSIDE (либо на mapped адрес, если используется проброс порта udp/443 (DTLS) и tcp/443(TLS)). Детальная информация по требованиям к сертификату указана в разделе Certificate Verification документации.
Ниже я приведу два примера настройки сертификатов шлюза Для проверки работы ASDM не забывайте указывать порт, например:
 Проведем базовые настройки туннеля: (ОПЦИОНАЛЬНО): В вышеприведенном примере мы использовали локального пользователя на МСЭ для аутентификации удаленных пользователей, что конечно, кроме как в лаборатории слабо применимо. Я приведу пример того, как быстро адаптировать настройку для аутентификации на RADIUS сервере, для примера использован Cisco Identity Services Engine: Данная интеграция дала возможность не только быстро интегрировать процедуру аутентификации с сервисом каталогов AD, но и различать принадлежность подключаемого компьютера к AD, понимать корпоративное это устройство или личное и проводить оценку состояния подключаемого устройства.

 Сделаем настройку Transparent NAT чтобы трафик между клиентом и ресурсами сети корпоративной сети не натировался: (ОПЦИОНАЛЬНО): Чтобы выпустить наших клиентов в Интернет через ASA (при использовании tunnelall опции) с использованием PAT, а также выходить через тот же интерфейс OUTSIDE, откуда они соединяются нужно сделать следующие настройки Крайне важно при использовании кластера дать возможность внутренней сети понять на какую ASA маршрутизировать обратный трафик к пользователям, для этого необходимо нужно сделать редистрибьюцию маршрутов /32 адресов, выдаваемых клиентам.
На текущий момент кластер мы еще не настраивали, но у нас уже есть работающие VPN шлюзы, к которым можно индивидуально подключиться по FQDN или IP.

Мы видим подключенного клиента в таблице маршрутизации первой ASA:

Чтобы весь наш VPN кластер и вся корпоративная сеть знала маршрут до нашего клиента, проведем редистрибьюцию клиентского префикса в протокол динамической маршрутизации, к примеру OSPF: Теперь у нас есть маршрут до клиента с второго шлюза ASA-2 и пользователи, подключенные к разным VPN шлюзам в рамках кластера могут, например, общаться через корпоративный софтфон напрямую, также как и обратный трафик от запрашиваемых пользователем ресурсов будет приходить на нужный VPN шлюз:
 Переходим к настройке Load-Balancing кластера.
Адрес 192.168.31.40 будет использоваться как Virtual IP ( VIP — к нему будут первично соединяться все VPN клиенты), с этого адреса Master кластера будет делать REDIRECT на менее загруженную ноду кластера. Не забудьте прописать прямую и обратную DNS запись как для каждого внешнего адреса/FQDN каждой ноды кластера, так и для VIP. Вывод: Таким образом, мы быстро развернули кластер из нескольких VPN шлюзов с автоматической балансировкой нагрузки. Добавить новые ноды к кластеру не составляет труда, получив простое горизонтальное масштабирование путем развертывания новых виртуальных машин ASAv или использования аппаратных ASA. Многофункциональный клиент AnyConnect может сильно расширить возможности безопасного удаленного подключения с использованием функции Posture (оценки состояния), наиболее эффективно применяемой совместно с системой централизованного контроля и учета доступа Identity Services Engine.