Стабільні адреси OpenVPN мають визначатися ідентичністю, а не вихідною IP-адресою
Статична адреса — це твердження про ідентичність, а не про вихідну IP-адресу. Спершу виберіть ключ, тримайте резервації поза пулом, потім визначте власника призначення.
Плани адрес, які кажуть «цей ноутбук отримує 10.90.0.10», насправді є твердженнями про ідентичність: який автентифікований пристрій може володіти цією адресою. Поточна публічна IP-адреса цього пристрою майже не має до цього відношення, бо NAT і роумінг змінюють її, не змінюючи того, ким є користувач. Побудова плану на вихідній адресі дає правила, що ламаються в першій же готельній мережі. Побудова його на автентифікованій ідентичності дає план, який переживає подорожі.
Почніть із того, що сервер може перевірити, а потім вирішіть, для чого ця адреса.
Виберіть ключ ідентичності раніше за адресу
Окремий клієнтський сертифікат на кожен пристрій дає серверу стабільний і перевірюваний ключ для кожного учасника, і це найчистіша основа для статичного призначення. Розгортання з автентифікацією на кожного користувача може натомість брати за ключ ім'я користувача, аби лише вибір конфігурації йшов за тим самим полем. Змішування двох моделей дає призначення, які збігаються із сертифікатом одного клієнта та іменем користувача іншого, і ніхто не може передбачити, що переможе. Вирішіть, який ключ використовує план, перш ніж писати хоч одну резервацію.
Із duplicate-cn кілька одночасних сеансів можуть подавати однакове загальне ім'я, тож одна закріплена адреса не може розрізнити їх поодинці. Це властивість моделі ідентичності, а не те, що може виправити кращий план адрес.
Резервуйте адреси поза динамічним діапазоном
У мережі з топологією subnet, як-от 10.90.0.0/24, тримайте нижні адреси для названих учасників, а динамічний пул розміщуйте в окремому діапазоні. Призначення для закріпленого учасника виглядає як ifconfig-push 10.90.0.10 255.255.255.0 у файлі, який сервер вибирає для цієї ідентичності. Другий аргумент означає дещо інше за net30, тому приклад не є нейтральним щодо топології. Прочитайте топологію, перш ніж копіювати його.
Збереження стану пулу записує недавні оренди і схильне повертати ту саму адресу, що є зручністю, а не резервацією. Не дозволяйте файлу збереження стати записом про володіння, бо він змінюється за історією з'єднань, а не за політикою.
Пріоритет призначення вирішує, хто перемагає
Посібник документує порядок: явне призначення, згенероване під час client-connect, може набути чинності раніше за запис у client-config-dir, який, своєю чергою, передує звичайному виділенню з пулу. Цей порядок пояснює більшість звітів «закріплена адреса не застосувалася». Він також означає, що динамічний розподілювач, який пише конфігурацію на кожен сеанс, може тихо перекрити статичний файл, який ви вважали авторитетним.
Виберіть один шар, який володіє призначеннями, і зробіть інші доступними лише для читання. Два шари, які обидва заявляють право вирішувати, дають призначення, що залежать від моменту часу.
Динамічному розподілювачу потрібна та сама модель
Інтеграція client-connect, яка видає адреси на кожен сеанс, — це невеликий розподілювач із типовими проблемами розподілювача. Він має перевіряти ідентичність запитувача, резервувати адресу атомарно, видавати лише підтримуваний вивід на кожне з'єднання та звільняти резервацію при відключенні або збої. Одночасні запити потребують блокування або обмеження бази даних, а не послідовності «читання потім запис». Без очищення пул втрачає адреси до перезапуску.
Тримайте стан розподілювача там, де його прочитає наступний оператор, і журналюйте рішення від ідентичності до адреси, а не лише адресу.
Вирішіть, чи адреса це політика, чи зручність
Якщо правило брандмауера або маршрут дозволяє трафік з однієї адреси тунелю, то ця адреса бере участь у політиці доступу, і повторне призначення успадковує цей дозвіл. Узгоджуйте життєвий цикл ідентичності, адреси та брандмауера або прив'яжіть правило до чогось, що не можна призначити повторно. Стабільна адресація робить конфігурацію читабельною; вона не замінює автентифікацію.
Запишіть план як інвентар із власником для кожного запису, а потім перегляньте його, коли пристрій виводять із експлуатації. Невикористана резервація — це та, яку випадково використають повторно.