Framed-IP-Address в RADIUS для стабильного адреса клиента VPN

RADIUS может ответить адресом для конкретного пользователя; получит ли его туннель на самом деле, зависит от шлюза. Именно в этом разрыве между возвращённым и применённым и терпят неудачу большинство планов со стабильным адресом. Атрибут в тестовом ответе доказывает, что сервер может его отправить, а не то, что служба удалённого доступа его применяет. Приведённая ниже последовательность проверяет обе половины, прежде чем адрес попадёт в правила межсетевого экрана.

Определите, какой уровень владеет адресом

Шлюзы удалённого доступа обычно имеют локальный пул, и многие могут принимать адрес и из ответа аутентификации. Что победит, зависит от платформы, протокола и конфигурации службы, поэтому прочитайте правило приоритета для точной используемой версии. Там, где приоритет у локального пула, атрибут — только украшение, и клиент всё равно оказывается на случайном адресе. Запишите решение, в том числе должно ли возвращённое значение находиться внутри диапазона пула или может выходить за него.

RFC 2865 определяет Framed-IP-Address как адрес, который нужно настроить для пользователя, и ничего не говорит о готовности конкретного шлюза его уважать. Авторитетом в вопросе приоритета является документация производителя, а не определение атрибута.

Отправьте тестовый запрос и прочитайте ответ

Сначала протестируйте сервер отдельно, чтобы отсутствующий атрибут не приняли за проблему шлюза. radtest отправляет один Access-Request и выводит атрибуты, которые возвращаются.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Найдите Framed-IP-Address в Access-Accept и убедитесь, что значение — нужное, а не адрес пула из резервного правила. Когда атрибут отсутствует, запись пользователя или политика авторизации не совпадают, и настройка шлюза не может дать то, что сервер никогда не отправлял. Повторите запрос, пока сервер работает в режиме отладки, если ответ трудно связать с конкретным правилом. Держите общий секрет вне истории оболочки и заявок, потому что заполнитель выше не является учётными данными.

Убедитесь, что шлюз применил значение

Правильный ответ — лишь половина договора. Адрес, который появляется на интерфейсе туннеля, — это то наблюдение, которое имеет значение, и его читают на клиенте, а не выводят из конфигурации шлюза.

ip -4 addr show tun0

Сравните этот адрес с атрибутом из Access-Accept. Несовпадение означает, что шлюз проигнорировал или переписал значение, что снова открывает вопрос приоритета из первого раздела. Подключитесь ещё раз, потому что резервирование, работающее только с первой попытки, обычно указывает на устаревшую сессию или аренду, которую всё ещё удерживает предыдущее соединение. Запишите версию шлюза и протокол рядом с результатом, чтобы следующий человек мог понять, зависит ли поведение от версии.

Спланируйте параллельность и отзыв

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

Стабильная адресация упрощает правила и журналы, но никогда не доказывает, кто создал пакет. Аутентификация и авторизация назначения по-прежнему важны, когда этот адрес позже переходит в другую сессию.