Фіксована 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, чи зіставленням на шлюзі, перш ніж змінювати будь-що з цього.