Перш ніж Juju charm стане вашим VPN: ідентичність, контракт, порти

Хтось знаходить charm, який нібито запускає VPN, розгортає його, відкриває застосунок і чекає на підключення клієнта. Розгортання вдається, порт відкривається, а тунель усе одно не працює, бо три не пов'язані обіцянки було зведено в одну. Charm — це реалізація розгортання з певним контрактом. Розгляньте ці обіцянки окремо, і прогалини виявляться до випуску, а не після.

Крок перший: закріпіть артефакт, про який ви читаєте

Прочитайте власні метадані кандидата: видавця, репозиторій джерел, канал, ревізію, базу й архітектуру. Потім визначте, хто супроводжує програму VPN усередині робочого навантаження і хто постачає її оновлення безпеки, бо це часто дві різні сторони. Непідтримуваний upstream усередині добре підтримуваного charm — це проблема підтримки, що чекає на поганий тиждень.

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

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

Крок другий: читайте конфігурацію як контракт

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

Дотримуйтеся інтерфейсів і дій, які charm справді надає. Не припускайте, що дія реєстрації існує лише тому, що її має інший charm для того самого програмного забезпечення.

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

Крок третій: відокремте слухача від перенаправленого шляху

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

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

Крок четвертий: експонування — це дія брандмауера

У Juju 3.6 експонування застосунку коригує правила хмарного брандмауера і за замовчуванням дозволяє трафік з будь-якого джерела до портів, які відкрило робоче навантаження. Селектори endpoint і CIDR команди існують саме для того, щоб це замовчування можна було звузити.

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

Крок п'ятий: прийміть чотирма тестами

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

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