Чи готовий WireGuard до продакшену? Відповідь не в протоколі

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

Питання за питанням

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

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

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

Ворота перші: шлях мусить нести UDP

WireGuard передає свій трафік через UDP і документує, що не пропонує режиму TCP або маскування трафіку. Дизайн, який розраховує на те, що трафік виглядатиме як звичайний веб, або на зміну порту заради поведінки TCP, спирається на припущення, яке програма не підтримує.

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

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

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

Ворота другі: хтось має володіти ключами

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

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

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

Ворота треті: пакету потрібен супровідник

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

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

Ворота четверті: прийміть навантаження, а не рукостискання

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

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

Тримайте докази поруч із критеріями, включно з тим локальним станом, що їх створив:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

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