Статична IP OpenVPN для кожного клієнта: ifconfig-push, а не ipp.txt
Файл збереження — це історія, а не резервування. Виберіть правильне ім'я клієнта, узгодьте топологію та доведіть адресу на новому з'єднанні.
Редагування рядка в ipp.txt здається резервуванням адреси, але це не так. Цей файл, який називає ifconfig-pool-persist, записує, яку адресу спільне ім'я мало минулого разу, щоб пул міг повернути ту саму, коли це зручно. Ніщо в ньому не прив'язує наступне з'єднання до цього номера.
Виконайте наведені нижче перевірки по порядку. Кожна або підтверджує механізм, або каже зупинитися й виправити вхідні дані.
Для чого потрібен файл збереження
Файл існує, щоб адреси залишалися стабільними між перезапусками, що робить повторні підключення зручнішими, а журнали — читабельнішими. Він читається як історія і записується як історія, а шлях розподілу залишається вільним вибрати іншу адресу, коли підказка не підходить: інший пул, конфліктне призначення або клієнт, який прийшов після заповнення пулу. Тому ручна правка може виглядати в файлі бездоганно і нічого не змінювати в з'єднанні. Ставтеся до нього як до кешу минулих рішень, а не як до джерела політики.
Якщо вам потрібна конкретна адреса для конкретного клієнта, задокументований механізм — ifconfig-push, і він належить конфігурації, яка володіє цим клієнтом.
Перевірте, що вибрано правильного клієнта
Явне призначення шукається за спільним ім'ям клієнта, тож файл, названий для неправильної особи, просто ніколи не читається. Підтвердьте, що сервер вважає ім'ям цього клієнта, особливо там, де username-as-common-name змінює його після автентифікації. Потім підтвердьте, що ім'я файлу точно відповідає цьому значенню, включно з регістром.
Подумайте про паралельність, поки ви тут. Якщо duplicate-cn дозволено, кілька пристроїв можуть представити ту саму особу, і одна фіксована адреса не може бути унікальною для всіх. Вирішіть, чи варта фіксована адреса відмови від паралельних сеансів для цієї особи, бо ці дві вимоги не можна задовольнити одночасно.
Перевірте, що числа відповідають топології
Значення аргументів залежить від топології тунелю, і саме тут скопійований приклад завдає найбільшої шкоди. У старій схемі net30 кожен клієнт займає блок із чотирьох адрес, тому push подає пару адрес. У топології підмережі клієнт отримує одну адресу плюс маску пулу, і форма пари неправильна. Прочитайте топологію з робочої конфігурації, перш ніж писати рядок.
# /etc/openvpn/ccd/partner-a (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0Перевірте адресу проти всього іншого, що могло б нею володіти: іншого явного призначення, діапазону динамічного пулу й будь-якого статичного маршруту, який припускає фіксований хост. Адреса, що перекривається з пулом, працюватиме, доки пул не віддасть її комусь іншому, і ця відмова виглядатиме випадковою.
Перевірте результат на новому з'єднанні
Наявний сеанс зберігає надану адресу, тож єдина осмислена перевірка — нове з'єднання. Відключіть клієнта, підключіться знову й прочитайте адресу, яку він фактично отримав, разом із маршрутами, що прийшли з нею. Якщо адреса досі динамічна, призначення не застосовано, і наступний крок — пошук у конфігурації, а не ще одна правка файлу історії.
Тримайте докази разом: ім'я клієнта, файл, що збігся, призначену адресу й пул, з якого вона прийшла.
Нарешті, фіксована адреса тунелю — це не облікові дані пристрою. Вона позначає місце в плані адрес, а автентифікація досі спирається на сертифікат і обліковий запис. Змішування двох перетворює конфлікт адрес на припущення про безпеку, якого ніхто не записав.