Prima pornire: înregistrarea unei flote de dispozitive WireGuard

O singură imagine, o cheie pe placă și un pas de autorizare care nu se încrede în afirmația dispozitivului însuși. Patru etape de la pornire la un peer confirmat.

Placa pornește din imaginea comună, obține un lease DHCP și un script de provizionare rulează înainte ca cineva să fi atins dispozitivul. Undeva în acel script trebuie să obțină o identitate WireGuard care aparține acestei plăci și niciunei alteia, să autorizeze acea identitate și să scrie un profil pe care gateway-ul îl va accepta. Imaginea poate transporta software-ul client, un șablon revizuit și cheia publică a gateway-ului. Ce nu trebuie să transporte niciodată este o singură cheie privată partajată de întreaga flotă, pentru că asta transformă o singură placă furată într-un incident pentru întreaga flotă. Ordinea de mai jos păstrează identitatea locală și autorizarea explicită.

Ce transportă imaginea și ce nu

Trimiteți pachetul, șablonul cu substituenți, cheia publică a gateway-ului și clientul de înregistrare. Șablonul este o formă, nu un secret: trebuie să fie lizibil pentru utilizatorul de provizionare și să nu conțină niciun material de cheie.

Cheia privată este generată pe dispozitiv la prima pornire și nu îl părăsește niciodată. Călătorește doar jumătatea publică, în interiorul unei cereri de înregistrare autorizate de altceva decât afirmația dispozitivului însuși despre cine este. Această distincție este ce împiedică o placă furată să devină o problemă pentru întreaga flotă. Și este și partea pe care majoritatea scripturilor de primă pornire o greșesc.

Pasul 1: generarea cheii local

Rulați generarea într-un director protejat după ce conexiunea de rețea subiacentă este aprobată și funcționează. Subshell-ul păstrează modificarea umask locală acestei operațiuni, iar set -C refuză să suprascrie un fișier existent:

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

Pornire rapidă WireGuard documentează relația de generare a cheilor pe care se bazează aceste două comenzi. Dacă generarea este întreruptă, lăsați dispozitivul neînregistrat și lăsați fluxul de lucru să reconcilieze fișierele. Nu ștergeți o identitate existentă doar pentru ca scriptul să ruleze curat de la început.

Păstrați cheia în așteptare între reîncercări. Regenerarea unei identități după fiecare eșec temporar de rețea este modul în care o flotă ajunge cu peer-i orfani pe care nimeni nu îi poate asocia unui dispozitiv.

Pasul 2: autorizarea unei înregistrări de dispozitiv

Să presupunem că inventarul numește această placă device-042 și îi atribuie 10.90.0.42/32. Serviciul de înregistrare trebuie să verifice că acest solicitant are dreptul la acea înregistrare. Un număr de serie tastat într-un formular nu este dovadă, pentru că numerele de serie sunt imprimate pe exteriorul cutiei.

O credențială de bootstrap per dispozitiv, o aprobare a operatorului sau o atestare susținută de hardware pot stabili afirmația. Protejați integritatea cererii și autenticitatea răspunsului și nu înlocuiți un secret VPN partajat cu o credențială de fabrică partajată.

Înregistrarea înregistrată leagă dispozitivul, cheia sa publică, adresa atribuită și rolul de administrare permis. WireGuard însuși nu definește niciun API de înregistrare, așa că acel serviciu este ceva ce construiți și operați deliberat.

Pasul 3: scrierea a două configurații potrivite

Dispozitivul are nevoie de un profil care rutează prefixele de administrare în tunel, iar gateway-ul are nevoie de o intrare peer care permite doar adresa sursă proprie a acestui dispozitiv. Cu un gateway la 10.90.0.1 și o rețea de administrare de 10.60.0.0/16, partea dispozitivului arată astfel:

[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

Valorile dintre paranteze drepte sunt substituenți, nu chei. Keepalive contează când placa stă în spatele NAT și trebuie să rămână accesibilă; nu este necesar peste tot, iar adăugarea lui din obișnuință ține un radio treaz fără motiv.

Pe gateway, intrarea peer este îngustă prin proiectare:

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

Nu copiați lista de destinații a dispozitivului în intrarea peer de pe gateway. Pe dispozitiv acea listă spune ce să ruteze în tunel; pe gateway spune ce adrese sursă poate folosi acest peer, iar acestea sunt afirmații diferite.

Forwardarea, regulile de firewall și calea de întoarcere către rețeaua de administrare trebuie încă să permită accesul aprobat. Un peer înregistrat nu este permisiune pentru fiecare aplicație din spatele lui.

Pasul 4: confirmarea înregistrării ca stare a ciclului de viață

Aplicați înregistrarea gateway-ului și profilul dispozitivului prin cel care deține fiecare configurație, apoi marcați înregistrarea completă doar când identitatea și adresa dorite sunt acceptate. Reîncercările ar trebui să reconcilieze aceeași înregistrare în loc să aloce un al doilea peer sau o a doua adresă.

Păstrați o cale de recuperare pentru provizionarea întreruptă, inclusiv cazul în care gateway-ul a acceptat cheia, iar dispozitivul nu și-a scris niciodată profilul.

Când o placă este înlocuită sau retrasă, eliminați cheia ei publică și autorizarea ei împreună. O cheie nouă este un eveniment deliberat de reînregistrare, nu un efect secundar al unei reimagini. Ordinea de lucru: generare local, autorizare față de inventar, scrierea ambelor părți, confirmarea stării, apoi testarea unei cereri de administrare prin tunel.

Articole similare