Первый запуск: регистрация парка устройств 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 или второй адрес.

Держите путь восстановления для прерванной подготовки, включая случай, когда шлюз принял ключ, а устройство так и не записало свой профиль.

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

Похожие статьи