MFA для VPN в UserGate — штука полезная: никакого RADIUS, без дополнительных лицензий, всё — из коробки. Одна проблема: фирменный клиент есть только под Linux. При этом еще далеко не все российские компании целиком перешли на отечественные ОС. 

Конечно, можно дождаться, пока вендор выпустит клиент под все платформы. Или можно взять L2TP/IPsec, штатные VPN-клиенты ОС, пару скриптов, немного покопаться в реестре Windows и собрать рабочее решение прямо сейчас. Именно это мы сегодня и сделаем.

Архитектура стенда

Для начала соберем типовую схему, которая часто встречается в компаниях: UserGate последней стабильной версии (на момент написания статьи это 7.4.2.390439R) в ней выступает пограничным устройством. За ним находится внутренний сервер, к которому нужно организовать удаленный доступ. Пользователь подключается снаружи через канал, имитирующий интернет.

IP-адресация такая:

• 192.168.1.10 — внешний интерфейс UserGate. В реальной среде здесь будет белый IP-адрес или серый адрес за NAT провайдерского роутера.

• 172.30.252.0/24 — виртуальная подсеть, из которой VPN-клиенты получают адреса при подключении.

• 172.168.100.0/24 — целевая внутренняя подсеть с защищенным сервером. Маршрут до нее мы будем отдавать авторизованному клиенту.

В демонстрации я использую локальных пользователей, а не AD или LDAP, но на механику работы VPN это не влияет. При использовании доменных учетных записей добавятся два дополнительных шага: интеграция с LDAP и настройка доменной авторизации на корпоративном портале. Однако настройка доменных политик — отдельная тема. В этой демонстрации оставим локальных пользователей и сконцентрируемся на том, как работает связка L2TP/IPsec и MFA.

Настройка серверной части NGFW

Remote Access VPN со вторым фактором в UserGate работает через взаимодействие нескольких сущностей, которые нужно правильно связать между собой.

Шаг 1. Сетевые интерфейсы и маршрутизация

Сначала определяем, через какой интерфейс будут приходить удаленные подключения и куда именно мы будем пускать пользователей после аутентификации. Для этого на внешнем интерфейсе (в нашем случае — 192.168.1.10) нужно разрешить два сервиса на уровне зоны: VPN и Веб-портал. 

Без VPN туннель просто не поднимется, а без Веб-портала пользователь не сможет зайти на веб-портал и получить QR-код для привязки второго фактора.

Далее создаем профиль сети VPN. В нем задаем пул адресов для клиентов, например, 172.30.250.2-172.30.250.254, и маску 255.255.255.0.

В соседней вкладке задаем маршрут до целевой внутренней подсети 172.168.100.0/24.

После этого поднимаем туннельный интерфейс (допустим, tunnel1), включаем его, переводим в статический режим и назначаем адрес из VPN-подсети, например, 172.30.250.1/255.255.255.0. Это будет клиентский шлюз внутри туннеля.

Шаг 2. Параметры IKE и IPsec

Теперь задаем криптографические параметры. По сути, определяем, как технически будет реализована виртуальная частная сеть. Для этого создаем серверный профиль безопасности.

В основных свойствах указываем:

• Протокол: IPsec/L2TP.

• Режим IKE: Основной (Main mode).

• Тип идентификации: Отсутствует.

• Общий ключ (Preshared Key / PSK): надежный пароль (например, TestRMVPN123!), который потребуется ввести на устройствах пользователей при первичной настройке.

На этом этапе сертификаты не используем. Для демонстрационного стенда достаточно аутентификации сервера по общему ключу.

Далее отдельно задаем параметры для IKE Фаза 1 и Фаза 2. 

Первая фаза отвечает за создание защищенного канала для служебного обмена (аутентификация, согласование алгоритмов). Вторая — за создание ключей для шифрования самого трафика.

В первой фазе выставляем время жизни ключа 24 часа, отключаем Dead Peer Detection в рамках демо и добавляем наборы шифрования. Из разумного минимума стоит оставить SHA256/AES256 и SHA1/AES256. Связку SHA1/3DES имеет смысл использовать только ради совместимости со старыми клиентскими устройствами. Если можно обойтись без 3DES, лучше так и поступить.

Время жизни ключей в Фаза 2 обычно меньше, чтобы обеспечить более частую ротацию. Поэтому для IPsec SA задаем 12 часов и аналогично выбираем алгоритмы аутентификации и шифрования.

Шаг 3. Профиль MFA

Теперь включаем то, ради чего все и затевалось. В интерфейсе UserGate нет отдельной кнопки формата «включить 2FA для VPN». Настройка делается через профиль MFA. Создаем профиль и задаем в нем логику второго фактора:

• MFA через: TOTP.

• Инициализация TOTP: выбираем «Показать ключ на странице captive-портала». Эта настройка заставит шлюз сгенерировать QR-код, когда пользователь впервые придет логиниться через браузер.

• Показывать QR-код: галочка обязательна.

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

Теперь при первом входе на веб-портал шлюз покажет пользователю QR-код для приложения-аутентификатора. В UserGate есть и другие способы доставки второго фактора. Например, отправка кода на email или СМС. Но TOTP — самый надежный: один раз отсканировал, и дальше коды генерируются прямо на смартфоне, без задержек на доставку.

Шаг 4. Связываем все вместе

Теперь у нас есть туннель, криптография и профиль MFA. Осталось собрать их в одну рабочую схему.

Сначала создаем профиль аутентификации. В нем выбираем созданный MFA-профиль, а во вкладке методов аутентификации добавляем «Локальный пользователь» или доменный метод, если вы настраиваете продуктовую среду. Дальше создаем пользователя, например, user1, задаем логин, пароль и добавляем его в группу VPN users.

Переходим к созданию пользователей. В разделе «Пользователи» заводим user1. Задаем логин, сложный пароль и помещаем в группу VPN users.

После этого создаем серверное правило VPN. В нем указываем:

• профиль безопасности VPN;

• сеть VPN с пулом адресов;

• профиль аутентификации с привязанным TOTP;

• интерфейс tunnel1.

Во вкладках «Источник» и «Назначение» можно разрешить подключения с любых адресов, а доступ ограничить группой VPN users или конкретным пользователем. 

Все, серверная часть готова. Теперь шлюз знает: где принимать подключения, как шифровать трафик и кому выдавать адреса.

Клиентская настройка: Windows, реестр и немного боли

На этом этапе нас ждут неочевидные костыли. Встроенный Windows-клиент для L2TP/IPsec плохо переносит сценарии подключения с участием NAT, а домашние устройства сотрудников, как правило, располагаются именно за NAT. Windows по умолчанию считает такое соединение небезопасным и сбрасывает попытку построения туннеля с невнятной ошибкой. Это лечится правкой реестра.

Правка реестра для NAT Traversal

1. Открываем regedit.

2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent — в этом разделе создаем параметр DWORD (32 бита) с именем AssumeUDPEncapsulationContextOnSendRule и значением 2.

   

3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters — в этом разделе меняем значение параметра AllowL2TPWeakCrypto на 1.

4. Перезагружаем компьютер.

Значение «2» означает, что сервер находится за NAT, и нужно использовать UDP-инкапсуляцию для ESP-пакетов.

Для справки: при работе L2TP/IPsec через NAT стандартные порты IKE (500) и ESP (50) могут блокироваться. Механизм NAT Traversal (NAT-T) инкапсулирует ESP-пакеты в UDP на порт 4500, что позволяет обходить эти ограничения. Правка реестра как раз включает этот механизм на стороне Windows.

Настройка подключения в Windows

1. Параметры → Сеть и Интернет → VPN → Добавить VPN-подключение.

2. В поле поставщика услуг VPN выбираем Windows (встроенные).

3. Задаем имя подключения, например, UserGateVPN.

4. Указываем адрес сервера 192.168.1.10.

5. Выбираем тип VPN L2TP/IPsec с общим ключом.

6. Указываем PSK из серверного профиля, например, TestRMVPN123!.

7. В качестве типа данных для входа выбираем Имя пользователя и пароль.

Сразу убираем галочку «Запомнить мои данные для входа». В данном случае она только вредит. Дело в том, что в нашей конфигурации одноразовый TOTP-код вводится прямо в поле пароля через двоеточие в формате «пароль:одноразовый код».

После создания подключения открываем свойства адаптера UserGateVPN. На вкладке «Безопасность» включаем «Незашифрованный пароль (PAP)». Без этого аутентификация не пройдет.

На вкладке «Сеть для IPv4» открываем дополнительные параметры и снимаем «Использовать основной шлюз в удаленной сети». Иначе отправите весь домашний трафик пользователя в корпоративный туннель, хотя вам нужен только маршрут до 172.168.100.0/24.

А теперь то же самое через скрипты

Весь этот процесс можно автоматизировать. Для этого потребуются два скрипта. 

Первый скрипт отвечает за правку реестра и создает тот самый параметр, который заставляет Windows использовать UDP-инкапсуляцию для ESP-пакетов при подключении через NAT. 

Скрипт-редактор реестра:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters]
"AllowL2TPWeakCrypto"=dword:00000001

Второй скрипт создает готовое VPN-подключение. Он формирует ярлык на рабочем столе, в котором уже прописаны все настройки: адрес сервера; тип VPN (L2TP/IPsec с общим ключом); общий ключ (PSK); отключенная галочка «Запомнить мои данные»; включенный протокол PAP; отключенный «Основной шлюз в удаленной сети».

Полный скрипт настройки подключения (проверен на Windows 11):

$adapterName = "UserGateVPN"
$serverAddress = "192.168.1.10"
$vpnType = "L2tp"
$sharedKey = "TestRMVPN123!"

# Сборка параметров подключения
$vpnParams = @{
    Name                = $adapterName
    ServerAddress       = $serverAddress
    TunnelType          = $vpnType
    L2tpPsk             = $sharedKey
    AuthenticationMethod = "Pap"
    SplitTunneling      = $true
    RememberCredential  = $false
    Force               = $true
}

# 1. Создание VPN соединения
Add-VpnConnection @vpnParams

# 2. Создание ярлыка на рабочем столе
$shell = New-Object -ComObject WScript.Shell
$desktop = [System.Environment]::GetFolderPath("Desktop")
$shortcut = $shell.CreateShortcut("$desktop\$adapterName.lnk")
$shortcut.TargetPath = "rasphone.exe"
$shortcut.Arguments = "-d $adapterName"
$shortcut.IconLocation = "shell32.dll,135"
$shortcut.Save()

Write-Host "VPN '$adapterName' успешно настроен с SplitTunneling и PAP." -ForegroundColor Cyan

Шаг 0. Проверяем версию ОС

Если на компьютере установлена Windows 11, то перед запуском скриптов нужно совершить одно дополнительное действие — открыть PowerShell от имени администратора и выполнить:

Set-ExecutionPolicy Bypass 

Эта команда разрешает выполнение неподписанных скриптов в текущей сессии. Без нее операционная система не даст запустить скрипты, сославшись на политику безопасности.

Шаг 1. Правим реестр

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

Шаг 2. Создаем VPN-подключение

После перезагрузки запускаем второй скрипт с помощью PowerShell и подтверждаем выполнение.

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

Онбординг пользователя

Технически все уже готово, но настроить инфраструктуру — только полдела. Остается самое интересное: объяснить пользователю, как это все использовать.

Инициализация второго фактора

Перед первым подключением пользователь должен открыть Captive-портал, например: https://192.168.1.10:4443/.

Дальше пользователь вводит свой логин и пароль (те самые, что вы создали на шлюзе или в AD) и получает QR-код и текстовый секрет TOTP.

В качестве приложения-аутентификатора подойдут Google Authenticator, Microsoft Authenticator, FreeOTP, браузерные расширения вроде 2FA Authenticator. Если ориентироваться на российские реалии, лучше использовать «Яндекс.Ключ». Для самого шлюза разницы нет — алгоритм TOTP стандартизирован, но с учетом политики импортозамещения и потенциальных ограничений зарубежных сервисов отечественное решение выглядит предпочтительнее.

Привязка второго фактора хранится внутри UserGate. Так, если пользователь потеряет телефон, администратор сможет сбросить привязку через веб-консоль, что довольно удобно.

Подключение к VPN

Для подключения на Windows удобно использовать rasphone. В окне ввода учетных данных пользователь указывает логин, а в поле пароля вводит уже не обычный пароль, а строку в таком формате:

ПарольОтУчетки:КодИзПриложения

Например:

MySuperSecretPass:123608

Нужно отметить, что тут пользователи часто совершают ошибки: вводят только пароль, забывая двоеточие и код; пропускают двоеточие; не успевают ввести код до его обновления (коды меняются каждые 30 секунд). Поэтому если вы хотите внедрить такую схему авторизации на практике, вам точно потребуется написать четкую и понятную инструкцию.

Если учетные данные введены правильно, соединение поднимается. Проверить маршрут можно командой route print — в таблице маршрутизации должен появиться путь до подсети 172.168.100.0 через туннель.

Опыт использования

Таким образом можно получить полноценный Remote Access VPN со вторым фактором на базе штатных средств ОС и встроенного функционала UserGate, но опыт использования этой схемы авторизации различается на разных платформах.

На macOS не нужно править реестр, и L2TP поднимается проще, но удобнее от этого не становится. Динамический код все так же нужно дописывать к паролю. К тому же macOS любит сохранять учетные данные в Keychain, из-за чего после сна или переподключения система подставляет старый пароль, и пользователь вынужден лезть в настройки, чтобы исправить составную строку. Формально все работает, но пользоваться такой авторизацией на постоянной основе очень неудобно.

На Android и iOS связка L2TP/IPsec с такой механикой второго фактора и вовсе не похожа на нормальный пользовательский сценарий.

На Linux подключение через Network Manager тоже поднимается, если установить необходимые пакеты, но стабильность сильно зависит от конкретной сборки и набора плагинов. На тестовых стендах работает хорошо, но в реальной эксплуатации могут случаться спонтанные обрывы. 

Если говорить о распространенных технических проблемах при настройке такого подключения, то в 90% случаев виновата одна из трех вещей:

1. Профили собраны неправильно. MFA-профиль не привязан к профилю аутентификации, пользователь не попал в нужную группу или правило VPN указывает не на те объекты.

2. На внешней зоне забыли включить VPN и Веб-портал. Без этого туннель просто не поднимется, а пользователь не получит QR-код.

3. Сбои на фазе IKE или на участке с NAT Traversal. Для пользователя это выглядит как «оно просто не подключается», хотя реальная проблема глубже.

К счастью, в актуальных версиях UserGate диагностика VPN-сессий стала заметно удобнее: логи теперь показывают, на какой фазе произошел обрыв и по какой причине. Разобраться с ошибками стало намного проще.

Итоги

Если оценивать эту схему по балансу безопасности и удобства, я бы поставил ей 6 из 10. Почему так мало? Потому что L2TP/IPsec в такой роли — откровенно компромиссная реализация с довольно кривым UX.

Почему не ниже? Потому что встроенный MFA в UserGate действительно полезен. Он не требует отдельного RADIUS-сервера, не просит дополнительных лицензий и в базовом варианте закрывает потребность в защищенном соединении.

Кому это подойдет? Тем, у кого уже стоит UserGate, нет бюджета или пространства для отдельного VPN-шлюза, а потребность во втором факторе возникла уже сейчас. 

Чего здесь действительно не хватает, так это отлаженного клиента под все популярные платформы. Когда вендор закроет эту потребность, вся схема сразу станет заметно удобнее и полезнее.

И последнее. Самая хрупкая часть этой конструкции — не криптография и не маршруты, а пользователь. Если вы внедряете такую удаленку, не экономьте на инструкции. Покажите на скриншотах, где взять QR-код, куда его сканировать, почему пароль теперь вводится через двоеточие и почему его нельзя сохранять, как раньше. Это как раз тот случай, когда хорошая инструкция экономит нервы и пользователям, и техподдержке.

Удачного развертывания, и да пребудет с вами аптайм!