Одна службова IP-адреса на кожному вузлі OpenVPN: чого вона не робить

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

Чому та сама адреса на кожному вузлі працює

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

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

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

Призначте її loopback, а не тунелю

Розміщення адреси на інтерфейсі loopback відв’язує її від часу життя будь-якого тунельного пристрою, тому перепідключення або перезавантаження конфігурації її не видаляє. Адреса існує, поки існує хост.

Адреса на lo не фільтр. Сервіс усе одно має на ній слухати, і міжмережевий екран хоста все одно оцінює реальний вхідний шлях, який надходить на інтерфейс тунелю. Хто вважає, що loopback означає лише локально, зрештою або блокує законних клієнтів, або відкриває те, чого не мав наміру.

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

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Проштовхніть один маршрут і майте на увазі один пункт призначення

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

Перевірте, що встановив клієнт, перш ніж звинувачувати сервіс.

ip route get 10.250.0.1

Для HTTP-сервісу дайте адресі ім’я та сертифікат для цього імені. Спільна IP не є ідентичністю, і вона не скасовує перевірку TLS, а також не виправдовує копіювання одного закритого ключа на кожен вузол. Ім’я, що розв’язується в спільну адресу, зберігає історію сертифіката звичайною і дозволяє зберегти ідентичність на вузол, якщо вона потрібна.

Чого спільна адреса не може

Вона не забезпечує перемикання в разі відмови. Якщо вибраний вузол помирає, адреса помирає разом з ним, і клієнту треба перепідключитися в іншому місці.

Вона не переносить живу TCP-сесію, бо нове з’єднання завершується на іншому хості, який нічого не знає про старе.

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

Тримайте ідентичність сервісу разом з іменем

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

Потім опишіть частини разом: адресу, інтерфейс, на якому вона живе, маршрут, який проштовхує сервер, і ім’я та сертифікат, які представляє сервіс. Чотири маленькі факти, які майбутній читач зможе перевірити, у тому порядку, у якому він їх перевірятиме.

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

Якщо вимога це доступність, підніміться на рівень вище: балансувальник навантаження, ім’я сервісу з перевірками здоров’я або система оркестрації, яка вже знає, як замінити вузол.

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