Отзыв доступа к VPN у уволенного: offboarding через LDAP-синхронизацию

Отзыв доступа VPN при увольнении — это автоматическое прекращение сетевого подключения сотрудника после блокировки его учётной записи в Active Directory, исключающее ручное вмешательство администратора. В корпоративных сетях на базе WireGuard протокол не различает статус занятости: он проверяет лишь криптографические ключи. Пока публичный ключ бывшего работника остаётся в конфигурации сервера, туннель активен, открывая путь к файловым хранилищам, системам учёта и терминальным серверам.

Ручное удаление пиров создаёт опасную задержку между кадровым решением и техническим ограничением. Инженеры IT For Prof устраняют этот разрыв, внедряя LDAP-синхронизацию через wg-portal. Такой подход превращает стандартную блокировку аккаунта в автоматический отзыв сетевых привилегий на ближайшем цикле синхронизации, а при конфликтном увольнении доступ снимается немедленно вручную через портал — без дополнительных операций в чек-листе увольнения.

Ручной отзыв VPN оставляет открытым окно доступа, потому что WireGuard не знает понятий «пользователь» или «уволен»: протокол проверяет только пару ключей и список allowed-ips (WireGuard). Пока публичный ключ бывшего сотрудника лежит в конфигурации сервера, туннель поднимается — вне зависимости от того, что человек уже не в компании.

Увольнение — это гонка со временем. Учётную запись в домене кадровик и служба безопасности закрывают в первые минуты, а VPN на ручной модели живёт своей жизнью. Нужно вспомнить, какой из десятков пиров чей, удалить нужную строку из конфига и перезапустить сервис. У нас был случай, когда пир уволенного разработчика оставался в конфиге несколько дней просто потому, что задачу поставили не тому админу, а VPN был вне общего чек-листа.

Не делайте так: мы сталкивались с ситуацией, когда бывший сотрудник спокойно продолжал ходить к файловому серверу и 1С через VPN, пока это случайно не всплыло на плановой инвентаризации доступов. Это классический разрыв между HR-процессом и технической реализацией: аккаунт в AD заблокирован, почта закрыта, RDP не пускает, а туннель работает.

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

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

LDAP-синхронизация в wg-portal делает Active Directory источником пользователей WireGuard: портал раз в интервал обходит каталог, сверяет список и применяет изменения к пирам. В секции auth.ldap файла config/config.yaml описывается LDAP-провайдер: адрес контроллера домена, сервисная учётка для чтения каталога, корень поиска base_dn и фильтры (документация wg-portal).

Интервал синхронизации задаётся параметром sync_interval, по умолчанию 15 минут. За один цикл портал получает актуальный срез пользователей: кто активен, кто заблокирован, кто пропал из каталога. Всё, что дальше происходит с пирами WireGuard, — следствие этой сверки, а не отдельный поток команд из внешних систем.

Доступ к конкретному сегменту сети привязывается к группе AD через interface_filter. Члены группы VPNUsers получают пир на офисном интерфейсе, Contractors — на изолированном, у которого свои маршруты и firewall-правила. Добавили сотрудника в группу — на следующем цикле синхронизации портал сам заводит ему пир, генерирует конфиг и выдаёт профиль. Убрали из группы — пир снимается. Именно эта двусторонняя синхронизация превращает кадровую операцию в AD в управление VPN-доступом без ручной правки конфигов.

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

Такая раскладка удобна ещё и для аудита: по имени интерфейса на сервере сразу видно, к какой роли относится подключение, а любой лишний пир на офисном интерфейсе, которого нет в группе VPNUsers, — сигнал о ручном обходе портала. Такое встречается, когда админ по-быстрому «подсунул» кому-то ключ в конфиг, минуя wg-portal, и потом этот пир никем не управляется.

Для offboarding в этой конструкции важны два поля синхронизации, которые мы разберём в следующем разделе. Первое — фильтр по флагу отключённой учётной записи, реагирующий на disable в AD. Второе — параметр disable_missing, закрывающий сценарий с удалением или перемещением учётки за пределы base_dn. Оба поля живут в конфиге портала и работают по одному циклу синхронизации, что делает поведение системы предсказуемым.

Автоматический offboarding в связке wg-portal и Active Directory настраивается двумя LDAP-фильтрами и одним флагом синхронизации, а срабатывает от штатного «Disable Account» в оснастке домена. И login_filter, и sync_filter в конфигурации содержат условие (!userAccountControl:1.2.840.113556.1.4.803:=2). Строка 1.2.840.113556.1.4.803 — OID правила LDAP_MATCHING_RULE_BIT_AND в Active Directory, а число 2 — бит ADS_UF_ACCOUNTDISABLE атрибута userAccountControl (userAccountControl, Microsoft Learn). Условие с отрицанием читается как «аккаунт НЕ отключён».

Дальше всё просто. Кадровик или служба безопасности блокирует учётную запись уволенного в оснастке AD (Disable Account). На следующем цикле синхронизации пользователь перестаёт проходить фильтр, и wg-portal переводит его пир в состояние disabled: убирает из активной конфигурации WireGuard. Туннель больше не поднимается, попытки подключения не приводят к успешному рукопожатию.

Флаг disable_missing: true закрывает второй сценарий. Если учётную запись не только заблокировали, но и удалили из каталога или вывели за пределы base_dn (например, перенесли в архивный OU, который не попадает в фильтр поиска), пользователь исчезает из результатов синхронизации, и портал тоже деактивирует его пир. Отдельно вспоминать про VPN при увольнении и подчищать список ключей руками не нужно: синхронизация делает это сама.

Единственный параметр, который стоит выбрать осознанно, — это sync_interval. Он же определяет максимальную задержку отзыва: между блокировкой в AD и снятием пира проходит до одного интервала. По умолчанию 15 минут — разумный компромисс для большинства офисов: нагрузку на контроллер домена практически не даёт, а окно между блокировкой аккаунта и падением туннеля укладывается в четверть часа. На контурах с чувствительными данными мы снижаем интервал до 5 минут, чтобы сократить окно неотозванного доступа.

Мы не рекомендуем ставить sync_interval ниже минуты «на всякий случай». LDAP-запрос выполняется по всему base_dn, и на каталоге в тысячи записей частая полная синхронизация нагрузит контроллер домена без реального выигрыша: если увольнение конфликтное, всё равно нужен принудительный kick через веб-интерфейс, а не ожидание короткого цикла. Про принудительное завершение сессии — в следующем разделе.

Ещё один нюанс: если у вас несколько площадок и на каждой свой экземпляр wg-portal с общей LDAP-инфраструктурой, окно отзыва суммируется по площадкам условно. Каждый экземпляр синхронизируется независимо, поэтому отзыв доступа VPN при увольнении сработает не мгновенно на всех, а с разбросом до sync_interval на каждой. Это нормально для регулярных увольнений и не подходит для аварийных сценариев, где нужен именно ручной kick через веб-интерфейс на нужной площадке.

Активные туннели после отзыва пира гаснут сами в пределах нескольких минут: WireGuard работает на переустановке сессии через периодические рукопожатия, и когда пир удалён из конфигурации, продлить сессию нечем. Здесь важно понимать механику протокола: сессия WireGuard не вечная, она периодически переустанавливается новым рукопожатием (rehandshake), и рукопожатие с несуществующим пиром сервер отклоняет.

Если такой задержки нельзя допустить (увольнение с конфликтом, подозрение на кражу данных), доступ закрывают немедленно, не дожидаясь ни sync_interval, ни естественного истечения сессии. Заходим в интерфейс wg-portal под администратором и деактивируем пользователя вручную: пир снимается с WireGuard-интерфейса сразу, активная сессия обрывается. Это тот самый принудительный kick, о котором просят службы безопасности при разборе инцидентов.

На сервере факт снятия пира можно проверить одной командой:

В выводе список активных пиров с их публичными ключами, endpoint и временем последнего рукопожатия. Пира уволенного там больше нет — значит, туннель обслуживать некому.

Дополнительный рубеж — preshared key. WireGuard поддерживает опциональный общий предварительный ключ на каждого пира: симметричный слой поверх основной криптографии (WireGuard). Для доступов повышенной чувствительности ротация PSK при увольнении гарантирует, что старый клиентский конфиг уволенного становится нерабочим целиком, даже если где-то сохранилась его копия: на личном ноутбуке, в почте, в облачном хранилище.

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

Не полагайтесь на то, что «клиент просто отключится сам». У нас был случай, когда ноутбук уволенного стоял с включённым VPN в спящем режиме, и после блокировки аккаунта туннель гас не сразу, а до первого промаха рукопожатия. Небольшой хвост в пару минут — но если увольнение конфликтное, лучше сразу отработать вручную через портал и не ждать, пока WireGuard самостоятельно поймёт, что сессию продлевать некому.

Аудит и логирование в связке WireGuard и wg-portal строится на двух источниках: состоянии активных пиров на сервере и журнале синхронизации портала. Отозвать доступ мало — при проверке или разборе инцидента нужно доказать, что отзыв доступа VPN при увольнении действительно состоялся и когда. WireGuard даёт для этого простой и надёжный факт: время последнего рукопожатия по каждому пиру.

Команда wg show на сервере выводит поле latest handshake — момент, когда пир в последний раз выходил на связь (WireGuard). Для контроля состояния после отзыва мы обычно смотрим детализированный вывод в машинном формате:

Формат dump удобно парсить скриптом и складывать в отчёт: одна строка на пир, публичный ключ, endpoint, latest handshake, счётчики трафика. По этим строкам легко видеть, кто вообще соединялся с сервером в последние часы и когда.

Логика доказательства такая. После деактивации пира его записи в активной конфигурации нет, а по журналу видно, что последнее рукопожатие датировано временем до отзыва и новых подключений после не было. Это и есть подтверждение, что уволенный после блокировки в сеть не заходил: не «мы верим, что не заходил», а видимый временной штамп.

Со стороны портала картину дополняет его собственный журнал. Включённый флаг log_user_info: true делает записи о синхронизации подробнее: видно, на каком цикле пользователь был деактивирован и по какой причине (не прошёл фильтр sync_filter, пропал из каталога, вышел из группы interface_filter). Для регулярной отчётности эти два источника — состояние пиров на сервере и журнал портала — закрывают вопрос «докажите, что доступ отозван» без ручного сбора скриншотов.

На наших проектах мы дополнительно настраиваем регулярную выгрузку состояния пиров cron-задачей: раз в сутки wg show all dump уходит в архив с датой. Так постепенно набирается готовая хронология доступа: по любому уволенному можно поднять журнал за нужный день и показать, что после блокировки пир пропал, а новых рукопожатий с его ключом сервер не видел.

Практический совет: не полагайтесь только на память о том, что «пир вроде сняли». Раз в период выгружайте состояние активных пиров и сверяйте с актуальным списком сотрудников из AD. Рассинхрон сразу покажет забытые доступы, если где-то остался ручной пир в обход портала, о котором никто уже не помнит.

Чек-лист offboarding на инфраструктуре с единым каталогом сокращается до одной операции: блокировки учётной записи в Active Directory (Disable Account). Всё остальное — VPN, почта, мессенджер, RDP — отзывается каскадом за эту же операцию. В этом главный выигрыш связки: отзыв доступа VPN при увольнении перестаёт быть отдельным пунктом, вокруг которого возникают зазоры между отделами.

Пошагово увольнение выглядит так:

• Заблокировать учётную запись в Active Directory (Disable Account). Отправная точка: с неё начинается автоматика, и на этом же шаге фиксируется дата и автор блокировки в журнале AD.
• VPN — отзывается сам на следующем цикле синхронизации wg-portal или немедленно вручную через портал, если увольнение конфликтное и ждать интервала нельзя.
• Почта и мессенджер — если они аутентифицируются через тот же AD/LDAP, доступ закрывается той же блокировкой. Для корпоративного мессенджера на своём сервере с интеграцией в домен это тот же принцип единого входа.
• RDP и доступ к серверам — при доменной аутентификации блокировка учётки закрывает и вход на терминальные серверы, и подключения к рядовым Windows-хостам.
• Проверить активные сессии — убедиться, что действующие туннели WireGuard и открытые RDP-сессии разорваны, а не висят до истечения таймаута.
• Зафиксировать факт отзыва — сохранить состояние пиров и запись журнала портала на дату увольнения для аудита или служебной проверки.

Мы не рекомендуем оставлять VPN и почту на «отдельных админах» с разными задачами в трекере. На одном из клиентских контуров до внедрения wg-portal именно так и было: HR писала письмо в IT, оттуда разлетались задачи в почту, VPN и helpdesk, и что-то из них регулярно тормозило. После централизации через AD задача превратилась в один клик кадровика, а IT видит результат по своим журналам.

Отдельно стоит настроить регулярный контроль обратной стороны — что при найме и переводе сотрудника нужные группы AD действительно назначаются вовремя, иначе новый человек не сможет войти в VPN. Та же LDAP-операция, которая при увольнении обрывает доступ, при найме его открывает.

Разворачиваем такую связку под ключ на вашем сервере: настраиваем корпоративный VPN под ключ с интеграцией в Active Directory, автоматическим отзывом доступа и журналированием подключений. Пример на реальном масштабе — наш кейс на 80+ сотрудников с порталом самообслуживания, где offboarding отработан именно так: блокировка в AD, снятие пира в течение цикла синхронизации, запись в журнале.

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

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на построении безопасных сетевых периметров и автоматизации управления доступом в Linux-средах. Внедряет решения на базе WireGuard и wg-portal для устранения ручных операций в процессах IAM.