Першы запуск: рэгістрацыя флоту прылад 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 або другі адрас.

Трымайце шлях аднаўлення для перарванай падрыхтоўкі, уключна з выпадкам, калі шлюз прыняў ключ, а прылада так і не запісала свой профіль.

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

Падобныя артыкулы