Първо стартиране: регистрация на флот от устройства 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 или втори адрес.

Пазете път за възстановяване при прекъснато провизиране, включително случая, в който шлюзът е приел ключа, а устройството никога не е записало профила си.

Когато платка бъде заменена или изведена от експлоатация, премахнете публичния ѝ ключ и оторизацията ѝ заедно. Новият ключ е съзнателно събитие по пререгистрация, а не страничен ефект от пресъздаване на образа. Ред на работа: генериране локално, оторизиране спрямо инвентара, записване на двете страни, утвърждаване на състоянието и след това тестване на една заявка за управление през тунела.

Подобни статии