Комментарии 24
Причем бесплатно, без СМС и за 15 минут.
У меня после прочтения данной статьи вопросы по производительности такой схемы.
А также вопрос, как масштабировать горизонтально, если более одного аплинка?
Масштабирование ограничено лишь суммарной производительностью нод кластера, может держать многие тысячи VPN соединений.
Теперь подсчитайте бюджет такого решения для обслуживания, например 500Kpps шифрованного трафика.
А потом я покажу бюджет решения на PC x86.
Для экстрималов, можете поиграться с Mikrotik, на скольки десятках Мбит шифрованного траффика он «сдуется».
Схема сети чисто лабораторная. Изначальные условия и требования выложены по ссылке в начале поста. Данная статья дает возможность в условиях «пожара» быстро развернуть удаленный доступ для тысяч сотрудников. В Cisco множество технологий и возможностей построения Remote-Access VPN и описанная схема не является универсальным решением на все случаи жизни, она является самой масштабируемой тем не менее. Я наше оборудование Cisco как у реальных заказчиков вижу как работает под нагрузкой, так и в специализированных лабораториях тестирую на нагрузке, свои цифры производительности оно показывает. Попробуйте на Микротике с десяток тысяч VPN пользователей активных затерминировать активно работающих.
Повторюсь, эта схема для больших и очень больших развертываний VPN. Для большинства подойдут схемы сильно более простые.
описанная схема не является универсальным решением на все случаи жизни, она является самой масштабируемой тем не менее
То есть FirePower до сих пор не годится на замену ASA?
Конечно можно и на FTD развернуть VPN, но проблема именно в конкретной ситуации, никто (большинство) не планировал емкость своих концентраторов на вот такой сценарий «удаленки» COVID-19. Так как можем быстро выписать ASAv, вот и инструкция под него…
Дмитрий, спасибо, классно!
Небольшое уточнение, для ASAv не надо дополнительно скачивать/устанавливать ASDM, он уже там есть в основном образе. Во flash его не видно, но он есть.
Еще раз благодарю за подробное описание!
Отправлять их на конкретный узел где для таких бедололаг настроен пул? Объявлять их хостовые маршруты при подключении по какому нибудь протоколу маршрутизации? или есть какое то более красивое решение?
Подробнее можно почитать здесь в разделе Enforcing Static IP Address Assignment for AnyConnect Tunnels, а ISE в свою очередь может читать этот параметр из LDAP как динамический атрибут о чем рекомендую посмотреть здесь.
Вопрос в том, что на различных нодах ВПН кластера используется свой уникальный пул, а куда подключается пользователь в случае коннекта к кластеру — зависит от нагрузки шлюзов и далеко не факт, что он попадет на железку, на которой настроен пул в который входит его статический адрес.
Собственно отсюда и вопрос — как правильно выдавать статику в случае настроенного VPN кластера. Варианты которые вижу я описал в своем первом комментарии. Может вендор скажет как правильно?
Я правильно понял, что бы сделать такой LB кластер как минимум «внешние» интерфейсы должны быть в одной сети? Есть ли возможность собрать кластер когда ноды находятся в разных датацентрах, с разными IP адресами?
+ как быть в случае NAT, когда внешний интерфейс ASA спрятан за другим файрволлом, например? Что указывать в качестве VIP адреса? Публичнный или внутренний?
Спасибо!
L2 сегмент должен быть единый для внутренних интерфейсов и отдельный L2 сегмент для внешних интерфейсов. Таким образом, если растянуть L2 на разные ЦОД нет возможности, то надо организовывать несколько кластеров. Завтра в рамках CiscoClub буду рассказывать.
По поводу NAT, есть соответствующая настройка в рамках блока конфигурации vpn load-balancing, называется она собственно nat, и дает возможность задать адрес как IPv4, так и IPv6 при использовании NAT на вышестоящем устройстве для идентификации конкретного члена кластера.
Развертывание ASA VPN Load-Balancing кластера