Фиксированный VPN IP: Framed-IP-Address в RADIUS или резерв в пуле

Фиксированный внутренний адрес для VPN-клиента могут хранить три места, и только одно из них должно им владеть. RADIUS может вернуть адрес в Access-Accept, шлюз может держать статическое сопоставление для учётной записи, а адаптер клиента можно задать вручную. Первые два — это политика, а третье — локальное предположение, которое шлюз вправе игнорировать или перезаписать. Выбор между первыми двумя и есть настоящее решение, и он зависит от того, что реально реализует сервер доступа к сети.

Три места, где может жить фиксированный адрес

RADIUS владеет адресом, когда ответ несёт Framed-IP-Address и шлюз применяет это значение к сеансу. Шлюз владеет им, когда администратор сопоставляет учётную запись со статическим адресом внутри пула. Клиент не владеет ничем, даже если его адаптер показывает адрес вручную, потому что сервер назначает внутренний адрес во время согласования, а локальная настройка важна только тогда, когда сервер ничего не присылает. Все три выглядят одинаково на работающем подключении, поэтому конфликты всплывают поздно. Разница видна при переподключении, на втором устройстве и после изменения политики.

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

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

Что может и чего не может обещать ответ RADIUS

RFC 2865определяет Framed-IP-Address как адрес IPv4, который нужно настроить для пользователя, и он принадлежит Access-Accept. Тот же атрибут в Access-Request — лишь подсказка, которую сервер может проигнорировать, и это важно, когда клиент или шлюз предлагает предпочтительный адрес. Ничто в протоколе не обязывает шлюз соблюдать ответ, потому что именно сервер доступа к сети применяет его к сеансу.

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

Ответ, который шлюз игнорирует, выглядит точно как ответ, который никогда не отправлялся. Чтение Access-Accept и адреса сеанса рядом — единственный способ различить эти два случая.

Зарезервируйте адрес внутри пула, который вы уже маршрутизируете

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

Решите, что должен делать второй одновременный сеанс. Назначение одного адреса дважды — это не управление устройствами, и возникшая коллизия проявляется как прерывистая связь у обоих сеансов. Либо выдавайте отдельные идентичности на каждое устройство, либо отдельные назначения, либо обеспечивайте одновременность поддерживаемой проверкой, например Simultaneous-Use, вместо того чтобы надеяться, что клиент никогда не переподключится до истечения старого сеанса.

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

Проверьте ответ, прежде чем доверять резерву

Проверяйте сторону AAA и сторону сеанса отдельно, потому что они отказывают по разным причинам. Локальный radtest показывает, что сервер возвращает для учётной записи, не задействуя шлюз, а запись в файле пользователей показывает, с чем сервер должен совпасть. Затем переподключите клиента и сравните полученный адрес с атрибутом в ответе.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

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

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

Выберите одного владельца и запишите его

Если шлюз надёжно применяет адреса в рамке, пусть RADIUS владеет назначением, а любое статическое сопоставление для той же учётной записи удалите. Если нет, пусть шлюз владеет им, а атрибут уберите из ответа, чтобы два источника не могли разойтись. Хранение обоих из-за того, что каждый почти работает, гарантирует будущий сеанс с неверным адресом и без очевидной причины.

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