Один обліковий запис VPN на двох серверах: три реєстри стану

Один обліковий запис, який може увійти на будь-який із двох вузлів VPN, ставить проєктне питання задовго до питання про програмне забезпечення. Подання запису, мережа, якою володіє кожен вузол, і сеанс, який тримає підключений клієнт, — це три різні види стану, і вони відмовляють по-різному, коли ви копіюєте їх з місця на місце. Копіювання всіх трьох в одну систему — поширений спосіб втратити один із них.

Пройдіть три реєстри нижче по порядку. Кожен питає, що є авторитетним, що локальним і що відбувається, коли іншого вузла немає, і відповіді не випливають одна з одної.

Хто може підключатися: одна авторитетна сторона, багато вузлів

Почніть із реєстру допуску: яке джерело ідентичності авторитетне, яким видавцям сертифікатів довіряють, які записи припустимі, який другий фактор застосовується і чого може досягти кожен запис. Потім запишіть, як кожен вузол дізнається про зміни і як швидко.

Спільна база даних — один із можливих складників цієї відповіді. Вона не доводить, що вся відповідна політика живе там або що кожен вузол застосовує зміну в один і той самий момент. Запис, вимкнений на вузлі A, але все ще прийнятий на вузлі B, означає, що процес виведення не завершено.

Вирішіть, що робить вузол, коли авторитетна сторона недоступна. Приймати кешовані облікові дані під час збою — це вибір політики з ціною для безпеки, а відхиляти їх — вибір політики з ціною для доступності. Будь-який із них можна захистити; залишити це неописаним — ні.

Тримайте авторитет видавця окремо від даних запису. Кілька шлюзів можуть довіряти одному й тому самому CA, не зберігаючи його ключа підпису, і кожному вузлу все ще потрібен власний сертифікат сервера та власні довірчі відносини на боці клієнта.

Чим володіє вузол: адреси та маршрути

Другий реєстр локальний для кожного вузла: адреса прослуховування, ідентичність сервера, пул адрес, маршрути до приватних ресурсів, політика резолвера і те, як трафік виходить до інтернету. Той самий запис може обслуговуватися будь-яким із двох вузлів, поки ці об’єкти залишаються різними.

Зворотний шлях — це частина, яку забувають. Якщо обидва вузли видають адреси з одного пулу, приватна мережа не може сказати, якому вузлу належить даний клієнт, і відповідь може піти не туди. Різним пулам теж потрібні маршрути й дозволи, тому окремий діапазон номерів — не повний проєкт.

Спрямовуйте клієнтів на вузол усвідомлено. Вибір DNS, списки кінцевих точок клієнта і фронтенд-сервіс — різні механізми з різною поведінкою перевірки стану й перемикання при відмові. Вибрати один — нормально; вважати «балансування навантаження» проєктом — означає залишити зворотний шлях і поведінку при відмові невизначеними.

Документований приклад продукту тут допомагає. Документація Pritunl щодо реплікації розглядає мережу VPN як об’єкт на кожну репліку, і клієнтам на різних репліках потрібні додаткові маршрути й зв’язність, щоб досягти одне одного. Це властиве продукту впорядкування, а не рецепт для Community OpenVPN, але воно показує, чому додавання репліки змінює мережу, а не лише сховище записів.

Що таке сеанс: живий стан, а не рядок

Третій реєстр — живий сеанс. У підключеного клієнта є стан протоколу та мережеве призначення на вузлі, який його прийняв. Знання запису на іншому вузлі не дає цьому вузлу сеанс, ключі чи можливість продовжувати пакети.

Будьте точними щодо того, що відбувається при відмові вузла. Підтримуваним результатом може бути повторне підключення до іншого вузла зі свіжою автентифікацією та новою адресою, після чого застосунок відновлюється своїм шляхом. Якщо потрібна безперервна передача, ця вимога потребує явної підтримки в реалізації, а не висновку з реплікації бази даних. Запишіть відповідь там, де черговий інженер зможе її знайти.

Правила ємності потребують такого самого підходу. Обмеження у два одночасні сеанси на запис можна забезпечити між вузлами лише тоді, коли якась авторитетна сторона має узгоджене уявлення про зайняті місця. Локальні для вузлів списки й історичний запис не складаються в таке уявлення.

Перевірка трьох реєстрів

Перевірте кожен окремо. Увійдіть через вузол A, потім через вузол B і переконайтеся, що обидва успішні з очікуваними діапазонами адрес. Відкличте ідентичність і перевірте обидва вузли, а не лише той, який ви випадково тестували. Потім зупиніть один вузол і подивіться, що насправді роблять клієнт і приватний застосунок.

Включіть зворотний шлях у приймальний тест. Клієнт, який підключається до B, але не може отримувати відповіді від ресурсу за A, пройшов перевірку допуску і провалив мережеву, і ця різниця має з’явитися у звіті.

Проєкт запису для кількох вузлів завершений лише тоді, коли всі три реєстри мають явного власника, шлях зміни й поведінку при відмові. Копіювання файлу конфігурації між вузлами не відповідає на жодне з цих питань.