Pirmā palaišana: WireGuard ierīču parka reģistrācija

Viens attēls, viena atslēga katrai platei un autorizācijas solis, kas neuzticas pašas ierīces apgalvojumam. Četri posmi no palaišanas līdz apstiprinātam peer.

Plate startē no kopējā attēla, saņem DHCP nomu, un sagatavošanas skripts tiek izpildīts pirms kāds ir aizticis ierīcei. Kaut kur šajā skriptā tam jāiegūst WireGuard identitāte, kas pieder šai platei un nevienai citai, jāliek šo identitāti autorizēt un jāieraksta profils, ko vārteja pieņems. Attēls var nest klienta programmatūru, pārskatītu veidni un vārtejas publisko atslēgu. Tas, ko tas nekad nedrīkst nest, ir viena privātā atslēga, ko dala viss parks, jo tas vienu nozagtas plati pārvērš visa parka incidentā. Zemāk dotā secība identitāti notur lokālu, bet autorizāciju skaidru.

Ko attēls nes un ko ne

Sūtiet paketi, veidni ar vietas turētājiem, vārtejas publisko atslēgu un reģistrācijas klientu. Veidne ir forma, nevis noslēpums: tai jābūt lasāmai sagatavošanas lietotājam un tajā nedrīkst būt atslēgu materiāla.

Privātā atslēga tiek ģenerēta ierīcē pirmās palaišanas laikā un nekad to nepamet. Ceļo tikai publiskā puse, reģistrācijas pieprasījuma iekšienē, ko autorizē kaut kas cits, nevis pašas ierīces apgalvojums par to, kas tā ir. Tieši šī atšķirība neļauj nozagtai platei kļūt par visa parka problēmu. Un tieši šo daļu vairums pirmās palaišanas skriptu dara nepareizi.

1. solis: ģenerēt atslēgu lokāli

Izpildiet ģenerēšanu aizsargātā direktorijā pēc tam, kad pamata tīkla savienojums ir apstiprināts un darbojas. Apakščaula notur umask izmaiņu lokālu šai darbībai, un set -C atsakās pārrakstīt esošu failu:

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

WireGuard ātrā palaišana dokumentē atslēgu ģenerēšanas saistību, uz kuru paļaujas šīs divas komandas. Ja ģenerēšana tiek pārtraukta, atstājiet ierīci nereģistrētu un ļaujiet darbplūsmai saskaņot failus. Nedzēsiet esošu identitāti tikai tāpēc, lai skripts no sākuma darbotos tīri.

Saglabājiet gaidošo atslēgu starp atkārtotiem mēģinājumiem. Identitātes atkārtota ģenerēšana pēc katras īslaicīgas tīkla kļūmes ir veids, kā parks paliek ar bāreņiem peer, kurus neviens nevar sasaistīt ar ierīci.

2. solis: autorizēt ierīces ierakstu

Pieņemsim, ka inventārs šo plati sauc par device-042 un piešķir tai 10.90.0.42/32. Reģistrācijas servisam jāpārbauda, vai šim pieprasītājam ir tiesības uz šo ierakstu. Veidlapā ierakstīts sērijas numurs nav pierādījums, jo sērijas numuri tiek iespiesti kastes ārpusē.

Katrai ierīcei paredzēts sākotnējās autentifikācijas datu kopums, operatora apstiprinājums vai aparatūras atbalstīta atestācija var pamatot apgalvojumu. Aizsargājiet pieprasījuma integritāti un atbildes autentiskumu, un neaizstājiet vienu kopīgu VPN noslēpumu ar vienu kopīgu rūpnīcas datu kopu.

Reģistrētais ieraksts saista ierīci, tās publisko atslēgu, piešķirto adresi un atļauto pārvaldības lomu. Pats WireGuard nenosaka nekādu reģistrācijas API, tāpēc šis serviss ir kaut kas, ko jūs apzināti veidojat un pārvaldāt.

3. solis: ierakstīt divas saskanīgas konfigurācijas

Ierīcei vajadzīgs profils, kas pārvaldības prefiksus maršrutē tunelī, un vārtejai vajadzīgs peer ieraksts, kas atļauj tikai šīs ierīces pašas avota adresi. Ja vārteja ir 10.90.0.1 un pārvaldības tīkls ir 10.60.0.0/16, ierīces puse izskatās šādi:

[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

Vērtības kvadrātiekavās ir vietas turētāji, nevis atslēgas. Keepalive ir svarīgs, kad plate atrodas aiz NAT un tai jāpaliek sasniedzamai; tas nav vajadzīgs visur, un pievienošana ieraduma dēļ notur radio nomodā bez iemesla.

Vārtejā peer ieraksts ir apzināti šaurs:

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

Nekopējiet ierīces galamērķu sarakstu uz vārtejas peer ierakstu. Ierīcē šis saraksts saka, ko maršrutēt tunelī; vārtejā tas saka, kuras avota adreses šis peer drīkst izmantot, un tie ir atšķirīgi apgalvojumi.

Pārsūtīšanai, ugunsmūra noteikumiem un atgriešanās ceļam uz pārvaldības tīklu joprojām jāatļauj apstiprinātā piekļuve. Reģistrēts peer nav atļauja katrai lietotnei aiz tā.

4. solis: nofiksēt reģistrāciju kā dzīves cikla stāvokli

Piemērojiet vārtejas ierakstu un ierīces profilu caur to, kam pieder attiecīgā konfigurācija, un pēc tam atzīmējiet reģistrāciju pabeigtu tikai tad, kad paredzētā identitāte un adrese ir pieņemta. Atkārtotiem mēģinājumiem jāsaskaņo tas pats ieraksts, nevis jāpiešķir otrs peer vai otra adrese.

Turiet atkopšanas ceļu pārtrauktai sagatavošanai, tostarp gadījumu, kad vārteja pieņēma atslēgu, bet ierīce nekad neierakstīja savu profilu.

Kad plate tiek nomainīta vai izņemta no ekspluatācijas, noņemiet tās publisko atslēgu un autorizāciju kopā. Jauna atslēga ir apzināts atkārtotas reģistrācijas notikums, nevis attēla pārrakstīšanas blakusefekts. Darbu secība: ģenerēt lokāli, autorizēt pret inventāru, ierakstīt abas puses, nofiksēt stāvokli, pēc tam pārbaudīt vienu pārvaldības pieprasījumu caur tuneli.

Saistītie raksti