Прво подигање: регистрација на флота од 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 или втора адреса.

Држете пат за обнова за прекината подготовка, вклучително и случајот кога портата го прифатила клучот, а уредот никогаш не го напишал својот профил.

Кога плочата се заменува или се повлекува од употреба, отстранете го нејзиниот јавен клуч и нејзината авторизација заедно. Нов клуч е намерен настан за повторна регистрација, а не несакан ефект од пресликување. Ред на работа: генерирајте локално, авторизирајте спрема инвентарот, напишете ги двете страни, утврдете ја состојбата, потоа тестирајте едно барање за управување низ тунелот.

Поврзани статии