Перший запуск: реєстрація парку пристроїв WireGuard

Один образ, один ключ на плату і крок авторизації, який не довіряє власному твердженню пристрою. Чотири етапи від запуску до підтвердженого peer.

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

Що образ несе, а що ні

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

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

Крок 1: згенерувати ключ локально

Виконуйте генерацію в захищеному каталозі після того, як базове мережеве з'єднання схвалене й працює. Підоболонка утримує зміну umask локальною для цієї операції, а set -C відмовляється перезаписувати наявний файл:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

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

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

Крок 2: авторизувати запис пристрою

Припустімо, інвентар називає цю плату device-042 і призначає їй 10.90.0.42/32. Служба реєстрації має перевірити, що цей заявник має право на такий запис. Серійний номер, введений у форму, не є доказом, бо серійні номери друкуються із зовнішнього боку коробки.

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

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

Крок 3: записати дві узгоджені конфігурації

Пристрою потрібен профіль, який спрямовує префікси керування в тунель, а шлюзу потрібен запис peer, який дозволяє лише власну адресу джерела цього пристрою. Зі шлюзом на 10.90.0.1 і мережею керування 10.60.0.0/16 бік пристрою виглядає так:

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

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

На шлюзі запис peer навмисно вузький:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

Не копіюйте список призначень пристрою в запис peer на шлюзі. На пристрої цей список каже, що спрямовувати в тунель; на шлюзі він каже, які адреси джерела цей peer може використовувати, і це різні твердження.

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

Крок 4: закріпити реєстрацію як стан життєвого циклу

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

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

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

Схожі статті