Как перевести компанию с Cisco AnyConnect на WireGuard: пошаговый план миграции

Замена cisco anyconnect на wireguard — это вынужденный переход с неподдерживаемого вендорского решения на открытый протокол, вызванный приостановкой бизнеса Cisco в России в 2022 году. Официальные продажи, продление лицензий и техническая поддержка стали недоступны, поэтому легальная эксплуатация инфраструктуры ASA/FTD невозможна.

Компании теряют обновления безопасности и гарантию на оборудование, оставаясь с истекающими лицензиями AnyConnect (теперь Cisco Secure Client). WireGuard закрывает этот разрыв: он бесплатен, не требует привязки к вендору и обеспечивает стабильный удалённый доступ для малого и среднего бизнеса без затрат на сертифицированные ГОСТ-шлюзы.

Замена Cisco AnyConnect на WireGuard в российских компаниях почти всегда начинается не с технологии, а с вендора: Cisco приостановила бизнес в РФ в 2022 году, и с тех пор официальные продажи, продление лицензий и техподдержка недоступны. AnyConnect продолжает работать, пока не кончилась лицензия и не сломался ASA, но обновлений безопасности, замены железа по гарантии и легальной покупки новых мест больше нет. Это и есть главный драйвер миграции — не «WireGuard быстрее», а «Cisco больше не поддерживается».

Уточним терминологию, потому что на этом путаются даже админы, ежедневно работающие с продуктом. С конца 2022 года клиент Cisco официально называется Cisco Secure Client, старое имя AnyConnect осталось только в народе и в устаревших дистрибутивах (Cisco: AnyConnect Secure Mobility Client). В реальной инфраструктуре мы встречаем оба имени одновременно: старый AnyConnect на рабочих станциях и новый Secure Client там, где успели обновиться до заморозки. Для миграции это один и тот же продукт с одной и той же проблемой — жить дальше на нём нельзя.

WireGuard закрывает возникший разрыв как современный, открытый и бесплатный протокол (WireGuard): нет лицензий на пользователя, нет привязки к вендору, код открыт и аудируется. Для среднего и малого бизнеса, которому нужен рабочий удалённый доступ к 1С, RDP и файловым серверам, а не сертифицированный по ГОСТ шлюз, это прямая замена AnyConnect с сохранением привычного пользовательского сценария «запустил клиент — попал в корпоративную сеть».

Управление пользователями и раздачу конфигов на наших проектах берёт на себя веб-панель wg-portal с интеграцией в Active Directory — админ не собирает ключи руками, сотрудник получает свой профиль через самообслуживание. Тот же контур, что мы описывали в статье про аутентификацию WireGuard через Active Directory: пользователь заходит по доменной учётке, портал выдаёт ему готовый peer-конфиг, дисциплина офбординга наследуется от AD.

Не делайте типичной ошибки — не воспринимайте миграцию как «поменять клиент на сотрудниках». Мы сталкивались с ситуацией, когда заказчик планировал только замену клиентского приложения и не учёл, что вместе с ASA уходит и вся серверная сторона: политики, MFA, портал. Правильная рамка — «переносим корпоративный VPN на другой стек», а не «меняем иконку в трее».

Три различия определяют всю миграцию: коммерческая модель, протокол и эксплуатационная нагрузка. Разберём по порядку — на этих отличиях будут стоять все дальнейшие решения по архитектуре.

Лицензии. AnyConnect требует платных лицензий (Plus/Apex или Secure Client Premier) на число одновременных подключений, привязанных к ASA/FTD. WireGuard лицензий не имеет вовсе: число пиров ограничено только ресурсами вашего сервера. Для компании, у которой лицензии Cisco истекают и продлить их легально нельзя, это снимает основную повторяющуюся статью расходов. Мы регулярно видим, что после инвентаризации из платного пула Cisco фактически использована меньшая часть — и всё равно платить приходится за весь пул, потому что лицензии продаются пакетами.

Протокол. AnyConnect работает поверх TLS/DTLS (SSL VPN) или IKEv2/IPsec и тащит за собой тяжёлый стек ASA. WireGuard — компактный протокол в ядре Linux на современной криптографии (Noise framework), работающий поверх UDP (по умолчанию порт 51820 в конфиге). Меньше кода — меньше поверхность атаки и проще аудит: спецификация WireGuard короче, чем один RFC IPsec, а реализация в Linux живёт прямо в kernel-space (WireGuard в ядре Linux).

Производительность и эксплуатация. WireGuard поднимает туннель за миллисекунды и стабильнее переживает роуминг между сетями за счёт stateless-модели: соединение не «висит» в состоянии и восстанавливается по ключу, стоит клиенту получить сетевой доступ. На наших проектах это заметно у мобильных пользователей — переключение Wi-Fi/LTE перестаёт быть событием, требующим переподключения.

Обратная сторона честная: WireGuard не умеет из коробки того, что делает ASA. Нет сложных политик доступа на уровне приложений, нет постуре-проверок клиента (антивирус, домен, версия ОС), нет встроенного портала входа с брендированием. Часть этой функциональности переносится на wg-portal и firewall сервера, часть — сознательно упрощается. Мы честно предупреждаем клиента на старте: если вам нужен постуре-контроль, чистый WireGuard не заменит AnyConnect — это архитектурное отличие, а не пробел в настройке.

Сводная таблица различий, к которой удобно возвращаться при защите миграции перед руководством:

Инвентаризация AnyConnect — обязательный первый шаг: без неё миграция превращается в перенос воображаемой конфигурации, а не реальной. Мы категорически не начинаем с установки WireGuard — сначала снимаем с ASA/FTD три конкретные вещи, и только потом проектируем целевую схему.

Первое — список пользователей и групп. Кто подключается, через какие tunnel-group и group-policy, сколько реальных одновременных сессий (не купленных лицензий, а фактически используемых по логам). На наших проектах регулярно оказывается, что из купленного пула лицензий живёт заметно меньшая часть — сервер под WireGuard нужен скромный, потому что реальная одновременная нагрузка кратно ниже, чем закупленный потолок Cisco. Этот же аудит закрывает разговор о «мёртвых душах»: учётные записи уволенных сотрудников, которые формально всё ещё в tunnel-group и жгут лицензии.

Второе — политики доступа. Какие подсети и сервисы открыты каждой группе: split-tunnel ACL, access-list на group-policy, DNS-суффиксы, статические маршруты. Это карта того, что придётся воспроизвести через allowed-ips пиров и firewall-правила на WireGuard-сервере. Мы выгружаем конфигурацию group-policy целиком и группируем пользователей по одинаковым наборам доступа — иначе на выходе получится столько же индивидуальных политик, сколько в ASA, и никакого упрощения миграция не даст.

Третье — честный список того, что НЕ переносится один в один. Постуре-проверки (проверка антивируса, доменной принадлежности, версии ОС на клиенте перед пуском в сеть), интеграция с MFA прямо на ASA, клиентский автозапуск через XML-профиль, брендированный портал входа — всё это в чистом WireGuard отсутствует. Часть закрывается иначе: MFA — через OIDC-провайдер перед wg-portal (Keycloak/Authentik), доступ по группам — через маппинг AD-групп на WireGuard-интерфейсы. Постуре-контроль на уровне протокола не воспроизводится; если он критичен для контура (например, доступ к финансовым системам), это аргумент оставить в этом сегменте отдельное решение и не тащить его в WireGuard-периметр.

Не делайте ошибки, с которой мы столкнулись у одного клиента — не переносите политики «как в ASA», не пересматривая их. За годы жизни AnyConnect в group-policy накапливается мусор: правила для проектов, которых давно нет, доступ к серверам, которые уже выведены, tunnel-group с двумя активными пользователями. Аудит — единственная возможность выкинуть это, не задев рабочие сценарии. Мы фиксируем в отдельном документе решение по каждой group-policy: переносим как есть, объединяем, упраздняем. Без такого документа через полгода никто не вспомнит, почему на WireGuard-сервере висит правило доступа к 10.20.30.0/24.

Замена Cisco AnyConnect на WireGuard без простоя строится на одном ключевом принципе: параллельная работа двух VPN с поэтапным переводом, а не «выключили Cisco в пятницу вечером, включили WireGuard в понедельник утром». WireGuard поднимается на отдельном сервере и слушает свой UDP-порт (в примерах обычно 51820), не мешая работающему ASA. Пользователи продолжают ходить через AnyConnect, пока их группу не переведут, — и это гарантия отсутствия простоя, а не риторический приём.

Порядок такой. Сначала пилот. Одна некритичная группа — обычно ИТ-отдел, потому что админам проще откатиться самим, — получает WireGuard-конфиги через wg-portal и неделю работает на новом канале, не отключая AnyConnect. За эту неделю всплывают все неучтённые мелочи: забытый маршрут до сервера мониторинга, DNS-суффикс, который использовался в AD-политиках, обращение к внутреннему API по IP из split-tunnel. Мы фиксируем найденное, донастраиваем сервер, и только потом идём в следующие группы.

Затем — волнами по отделам. Выдали конфиги, дали срок на переключение (обычно неделя), следим по логам ASA, кто ещё ходит через Cisco. Волны нарезаем по группам доступа, а не по алфавиту: сначала пользователи с простыми политиками (одна подсеть, один сервис), потом сложные (несколько серверов, специфические маршруты). Финансы и топ-менеджмент — предпоследняя волна, критические сервисы вроде дежурной смены — последняя. Такой порядок мы выработали на нескольких внедрениях: если что-то пойдёт не так, оно проявится на группе с простой конфигурацией, где откат стоит десять минут, а не на директоре перед совещанием.

Когда через AnyConnect перестают заходить последние пользователи, ASA не выключают немедленно — держат ещё две недели в горячем резерве. За это время находятся забытые сценарии: подрядчик, который подключается раз в квартал; сервер, ходящий в интернет через VPN-туннель; скрипт, использующий VPN как транспорт. Только после этого ASA выводят из эксплуатации.

Такой подход мы применяли на реальных внедрениях: клиент не ловит простой, потому что откат — это «остаться на AnyConnect ещё день», а не аварийное восстановление из бэкапа. Не делайте противоположного — мы видели, как один клиент решил сэкономить неделю и отключил AnyConnect до завершения пилота; в результате три дня чинили доступ отдела продаж вручную. Разворачиваем миграцию под ключ с параллельной работой обоих каналов — корпоративный VPN под ключ, с переносом доступов и без окна простоя.

Перенос политик доступа — самая техническая часть миграции, и здесь важно не переносить конфигурацию буквально, а транслировать её в другую модель. В Cisco ASA доступ группы описан связкой tunnel-group → group-policy → split-tunnel ACL: какие подсети клиент видит через туннель, какие DNS ему пушатся, какой домен по умолчанию. В WireGuard та же логика выражается двумя механизмами, и о них стоит договориться до начала работы.

Первое — allowed-ips на стороне сервера для каждого пира. Это список подсетей, которые маршрутизируются в туннель этому пользователю, — прямой аналог split-tunnel-списка из group-policy (wg(8), параметр allowed-ips). allowed-ips работает и как cryptokey routing (какие пакеты шифровать этим ключом), и как фильтр: пакет с source-IP вне разрешённого набора будет отброшен. В клиентском конфиге тот же параметр определяет, какие маршруты добавляются в системную таблицу маршрутизации при поднятии туннеля.

Второе — firewall-правила на WireGuard-сервере (nftables или iptables), которые ограничивают, к каким хостам и портам пир реально может обращаться. Access-list, который в ASA висел на group-policy на уровне L4, переезжает в firewall сервера. Это разделение непривычно администраторам Cisco: там «доступ к сети 10.10.0.0/24 только по 445» описывался в одном месте, а здесь маршрутизация живёт в allowed-ips, а фильтрация портов — в nftables. Мы всегда фиксируем в документации, что за какое правило отвечает, — иначе через полгода следующий админ будет искать закрытый доступ не там.

Практический приём, который экономит недели работы: не переносите политики руками по одной. Выгрузите с ASA конфигурацию group-policy и split-tunnel-списки через show running-config, сгруппируйте пользователей по одинаковым наборам доступа и заведите под каждую группу свой WireGuard-интерфейс в wg-portal с общим набором маршрутов. Дальше маппинг групп Active Directory на интерфейсы делает раздачу автоматической: пользователь попадает в AD-группу — портал выдаёт ему конфиг с правильными allowed-ips. Тот же принцип, что и при обычном офбординге: убрали из группы — доступ пропал.

Так десятки индивидуальных политик ASA сводятся к трём-пяти WireGuard-интерфейсам с понятными названиями: wg-office, wg-finance, wg-devops, wg-contractors. Схема ложится в голову с первого взгляда, а новых людей в неё вводить — минуты, а не часы объяснений про наследование group-policy.

Пример минимального фрагмента серверного конфига WireGuard для одного пира с ограниченным доступом:

Здесь AllowedIPs = 10.20.1.15/32 фиксирует внутренний IP пира, а всё, что этот IP имеет право открывать в корпоративной сети, описывается уже правилами nftables — где, в отличие от ASA, всё явно и без скрытой логики group-policy.

Одновременная работа AnyConnect и WireGuard — рабочая схема на весь период миграции, но у неё есть три нюанса маршрутизации, которые лучше решить до старта, а не разбирать по инцидентам. Мы каждый раз проговариваем их с заказчиком, потому что классические грабли повторяются от проекта к проекту.

Правило одного активного VPN на клиента. Пользователь не должен быть подключён к AnyConnect и WireGuard одновременно к одним и тем же подсетям — иначе маршруты конфликтуют, и трафик идёт непредсказуемо: часть пакетов через ASA, часть через WireGuard-шлюз, ответы теряются на асимметричном пути. На время миграции проще держать правило «один пользователь — один активный VPN»: перевели человека на WireGuard, он удаляет профиль AnyConnect в тот же день. Серверные подсети при этом доступны через оба шлюза, но каждый клиент ходит через один. Мы явно пишем это в инструкции для пользователя — «сначала отключитесь от AnyConnect, потом включайте WireGuard» — и не полагаемся на то, что он сам догадается.

DNS — вторая частая засада. AnyConnect обычно пушит клиенту внутренние DNS-серверы и domain-suffix через group-policy, и пользователь этого не замечает — оно работает само. В WireGuard DNS задаётся явно в клиентском конфиге строкой DNS = 10.10.10.1, corp.local. Проверьте на пилоте, что при переключении клиент получает правильный внутренний резолвер, иначе внутренние имена вроде 1c.corp.local перестанут открываться, хотя сеть формально доступна. Мы сталкивались с тем, что пользователь звонит и говорит «интернет есть, а 1С не работает» — чаще всего это DNS, который в WireGuard-профиль забыли прописать.

Отключение AnyConnect — финальный шаг, а не первый. ASA выводят из эксплуатации только когда логи неделю показывают ноль подключений через AnyConnect и все известные сценарии подтверждены на WireGuard. До этого момента AnyConnect остаётся горячим резервом: любой недопереведённый пользователь, забытый подрядчик или редко используемая учётка просто продолжают работать по-старому, а не звонят в техподдержку с криком «у меня всё отвалилось».

Наблюдаемая цена такой миграции — растянутость по времени: месяц-два, а не выходные. Взамен мы получаем нулевой простой и возможность откатить любую группу обратно без ночного дежурства. На больших контурах — например, наш кейс на 80+ сотрудников с порталом самообслуживания — эта схема отработана волнами и подтверждена в бою.

Честная оговорка, без которой статья была бы рекламой: WireGuard использует современную, но НЕ сертифицированную по российским стандартам криптографию, и он не заменяет ГОСТ-шлюз там, где сертификация обязательна по закону. Это не мнение и не осторожность, а границы применимости продукта.

Если вы относитесь к одной из категорий с обязательными требованиями — банк или иной субъект НПС, госорган, оператор критической информационной инфраструктуры (КИИ), медучреждение с ЕГИСЗ, — и передаёте по VPN сведения, к защите которых предъявляются требования ФСБ/ФСТЭК, вам нужен сертифицированный шлюз с ГОСТ-криптографией: С-Терра, ViPNet, «Континент» и подобные. WireGuard в таком контуре юридически не подходит, каким бы удобным он ни был технически. Никакие ссылки на аудит кода и открытые исходники не заменяют сертификат — регулятора интересует бумага, а не архитектура протокола.

Наш угол WireGuard — средний и малый бизнес без ГОСТ-обязательств: те, кому нужен рабочий, дешёвый и управляемый удалённый доступ к своим 1С, RDP и файловым серверам, а не соответствие требованиям регулятора по сертифицированной криптографии. Торговля, производство, ИТ-фирмы, дизайн-студии, юридические практики без гостайны — здесь замена Cisco AnyConnect на WireGuard даёт максимальный выигрыш: снимается зависимость от несуществующей больше в РФ поддержки Cisco, уходит статья расходов на лицензии, появляется портал самообслуживания вместо ручной раздачи профилей.

Есть и гибридный сценарий, который мы применяли на смешанных контурах: WireGuard закрывает основной корпоративный доступ (почта, файлы, внутренние веб-сервисы), а сертифицированный шлюз остаётся отдельным туннелем в тот сегмент, где действительно требуется ГОСТ (например, обмен с ГИС). Это дороже, чем чистый WireGuard, но кратно дешевле, чем ГОСТ-шлюз на всех сотрудников. Такое разделение честно снимает конфликт «нужна сертификация — но не для всего».

Если сомневаетесь, к какой категории относитесь, это вопрос не к VPN, а к вашему профилю рисков и требованиям регуляторов, которые накладываются на вашу отрасль. Мы честно скажем на первом же созвоне: если ваш случай — про ГОСТ, WireGuard не подойдёт, и никакая экономия на лицензиях Cisco эту границу не сдвинет. Наоборот, если вы обычный СМБ без обязательной сертификации, а платили за AnyConnect только потому, что «так исторически сложилось», — миграция окупается уже в первый год за счёт отказа от лицензий и снятия рисков неподдерживаемого вендора.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на проектировании защищённых сетевых инфраструктур и миграции корпоративных сервисов с проприетарных решений на открытые стандарты. Имеет опыт бесшовного перевода компаний с Cisco ASA на стеки Linux/WireGuard с сохранением бизнес-непрерывности.