OGOwnGate

· Команда OwnGate

Туннель в никуда: почему блокировка в AD не сбрасывает сессии OpenVPN

Вы заблокировали пользователя в Active Directory, но удалёнщик продолжает сидеть в корпоративной сети. Разбираем, почему VPN не разрывает сокеты и как настроить мгновенный сброс.

«Я же нажал Disable Account»: немой вопрос в три часа ночи

Классический инцидент из жизни дежурного ИБ. Сотрудника уволили в 18:00, аккаунт в Active Directory заблокирован, все галочки проставлены.

В 02:40 ночи система обнаружения вторжений (IDS) поднимает тревогу: с внутреннего IP-адреса 10.8.0.42 идёт массовое сканирование портов базы данных и скачивание файлов с закрытого SMB-сервера.

Дежурный открывает лог VPN-шлюза: соединение с этого IP установлено в 17:45 — за пятнадцать минут до официального увольнения.

Но почему оно до сих пор живо? Ведь доменная учётка заблокирована!

Разрыв VPN-сессии на защитном шлюзе

---

Архитектура сокета: почему VPN не спрашивает AD во время работы

Многие системные администраторы искренне верят, что если OpenVPN или WireGuard настроены на авторизацию через Active Directory (по LDAP или RADIUS), то блокировка пользователя мгновенно обрывает связь.

Это опасное заблуждение. Вот как устроена реальная механика туннеля:

1. Проверка пароля только на старте. В момент вызова connect клиент отправляет логин и пароль. VPN-сервер делает запрос к Active Directory, получает OK, согласует сессионные криптографические ключи и открывает виртуальный сетевой интерфейс (tun0).

2. Переход в режим чистого роутинга. После того как туннель поднят, VPN-сервер превращается в обычный сетевой маршрутизатор. Он пересылает зашифрованные IP-пакеты туда и обратно.

3. Никаких повторных проверок. Сервер OpenVPN не делает LDAP-запрос на каждый переданный мегабайт трафика (иначе контроллер домена упал бы через пять минут). Для сервера пользователь остаётся «авторизован», пока открыт сетевой сокет.

Туннель будет жить часами, а иногда и сутками — пока уволенный сам не нажмёт кнопку отключения или пока администратор вручную не прибьёт конкретное соединение.

---

Три костыля, которыми обычно пытаются это лечить (и почему они плохи)

Костыль 1. Уменьшение reneg-sec в конфиге OpenVPN

По умолчанию OpenVPN каждые 3600 секунд (1 час) проводит renegotiation — пересогласование ключей. Некоторые админы ставят reneg-sec 300 (5 минут), надеясь, что каждые 5 минут сервер будет перепроверять статус пользователя в AD.

  • Проблема: Пересогласование ключей рвёт активные SSH-сессии, сбрасывает долгие загрузки файлов и грузит процессор шифрованием. Разработчики и аналитики взвоют от нестабильного интернета.

Костыль 2. Отзыв клиентских сертификатов (CRL)

Генерация нового списка отозванных сертификатов:


easyrsa revoke username

easyrsa gen-crl
  • Проблема: Если вы используете общие сертификаты или авторизацию только по связке логин/пароль + TOTP — CRL бесполезен. А если на каждого юзера генерируется отдельный сертификат, поддержание актуального CRL на 100+ человек превращается в ручной кошмар.

Костыль 3. Ручной kill процесса через OpenVPN Management Interface

Подключиться к сокету управления:


telnet 127.0.0.1 7505

kill username
  • Проблема: Про это нужно вспомнить. В стрессе увольнения или в конце тяжёлой смены администратор гарантированно забудет зайти на VPN-сервер и проверить активные сокеты.

---

Архитектурное решение: как добиться мгновенного отзыва туннелей

Чтобы удалённый доступ закрывался гарантированно и без ручных плясок, VPN должен быть встроен в единый контур авторизации компании:


[ Клиент VPN ] ──▶ [ Шлюз доступа (SSO / OIDC) ] ──▶ [ Active Directory ]

                           │

                 (проверка статуса каждые N мин)

                           │

                  (принудительный сброс сокета)

                           ▼

                    [ VPN Gateway ]

1. Авторизация через короткоживущие токены

Вместо статических паролей или бессмертных конфигов клиент получает короткоживущий токен доступа (на 15–30 минут) через централизованный шлюз доступа. Шлюз обновляет сессию только в том случае, если учётная запись в Active Directory активна и входит в разрешённую группу доступа (например, SG_VPN_RemoteAccess).

2. Принудительный Webhook на сброс сессий

В момент, когда в шлюзе доступа изменяется статус пользователя (блокировка или исключение из группы), шлюз отправляет автоматический API-запрос на VPN-сервер:


POST /api/vpn/disconnect {"user": "ivanov"}

VPN-сервер мгновенно сбрасывает маршруты и уничтожает криптографический контекст конкретного туннеля.

---

Главный вывод

Пока отзыв сетевого доступа требует от администратора ручных действий на трёх разных серверах, в вашем периметре всегда будут открыты «туннели в никуда».

Безопасность удалённого доступа должна опираться на автоматику: одно действие в каталоге пользователей обязано синхронно закрывать веб-сессии, аннулировать токены и мгновенно глушить сетевые сокеты VPN.

← Все статьи