Første oppstart: registrering for en flåte av WireGuard-enheter

Ett image, én nøkkel per kort og et autorisasjonstrinn som ikke stoler på enhetens eget påstand. Fire trinn fra oppstart til en fastsatt peer.

Kortet starter fra det felles imaget, får en DHCP-lease, og et provisioning-skript kjører før noen har rørt enheten. Et sted i det skriptet må det skaffe en WireGuard-identitet som hører til dette kortet og ingen andre, få den identiteten autorisert og skrive en profil som gatewayen godtar. Imaget kan inneholde klientprogramvaren, en gjennomgått mal og gatewayens offentlige nøkkel. Det det aldri kan inneholde, er én privat nøkkel som hele flåten deler, for det gjør ett stjålet kort til en hendelse for hele flåten. Rekkefølgen nedenfor holder identiteten lokal og autorisasjonen eksplisitt.

Hva imaget inneholder – og hva det ikke gjør

Lever pakken, malen med plassholdere, gatewayens offentlige nøkkel og registreringsklienten. Malen er en form, ikke en hemmelighet: den skal være lesbar for provisioning-brukeren og ikke inneholde nøkkelmateriale.

Den private nøkkelen genereres på enheten ved første oppstart og forlater den aldri. Bare den offentlige halvdelen reiser, inne i en registreringsforespørsel som autoriseres av noe annet enn enhetens eget påstand om hvem den er. Den forskjellen er det som hindrer et stjålet kort i å bli et problem for hele flåten. Det er også den delen de fleste first-boot-skript gjør feil.

Trinn 1: generer nøkkelen lokalt

Kjør genereringen i en beskyttet katalog etter at den underliggende nettverkstilkoblingen er godkjent og virker. Subshellen holder umask-endringen lokal for denne operasjonen, og set -C nekter å overskrive en eksisterende fil:

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

I WireGuard-hurtigstarten dokumenteres nøkkelgenereringsforholdet som disse to kommandoene bygger på. Hvis genereringen avbrytes, la enheten være uregistrert og la arbeidsflyten avstemme filene. Ikke slett en eksisterende identitet bare for å få skriptet til å kjøre rent fra toppen.

Ta vare på den ventende nøkkelen på tvers av nye forsøk. Å generere en identitet på nytt etter hver midlertidige nettverksfeil er hvordan en flåte ender opp med foreldreløse peers som ingen kan knytte til en enhet.

Trinn 2: autoriser en enhetspost

Anta at inventaret kaller dette kortet device-042 og tildeler det 10.90.0.42/32. Registreringstjenesten må verifisere at den som ber om dette, har rett til posten. Et serienummer som er skrevet inn i et skjema, er ikke bevis, for serienumre er trykt på utsiden av esken.

En bootstrap-legitimasjon per enhet, en godkjenning fra en operatør eller en maskinvarestøttet attestasjon kan fastslå kravet. Beskytt forespørselens integritet og svarets ekthet, og ikke bytt ut én delt VPN-hemmelighet med én delt fabrikklegitimasjon.

Den registrerte posten binder enheten, dens offentlige nøkkel, dens tildelte adresse og dens tillatte administrasjonsrolle. WireGuard definerer ingen registrerings-API selv, så den tjenesten er noe du bygger og driver bevisst.

Trinn 3: skriv to konfigurasjoner som passer sammen

Enheten trenger en profil som ruter administrasjonsprefiksene inn i tunnelen, og gatewayen trenger en peer-post som bare tillater enhetens egen kildeadresse. Med en gateway på 10.90.0.1 og et administrasjonsnett på 10.60.0.0/16 ser enhetssiden slik ut:

[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

Verdiene i hakeparenteser er plassholdere, ikke nøkler. Keepalive betyr noe når kortet sitter bak NAT og må forbli tilgjengelig; det er ikke nødvendig overalt, og å legge det til av vane holder en radio våken uten grunn.

På gatewayen er peer-posten bevisst smal:

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

Ikke kopier enhetens destinasjonsliste over til gateway-peeren. På enheten sier listen hva som skal rutes inn i tunnelen; på gatewayen sier den hvilke kildeadresser denne peeren kan bruke, og det er forskjellige utsagn.

Videresending, brannmurregler og returveien til administrasjonsnettet må fortsatt tillate den godkjente tilgangen. En registrert peer er ikke tillatelse for hver applikasjon bak den.

Trinn 4: fastsett registreringen som en livssyklustilstand

Bruk gateway-posten og enhetsprofilen gjennom den som eier den enkelte konfigurasjonen, og merk registreringen som fullført først når den tiltenkte identiteten og adressen er godtatt. Nye forsøk bør avstemme den samme posten i stedet for å tildele en annen peer eller en annen adresse.

Hold en gjenopprettingsvei for avbrutt provisioning, inkludert tilfellet der gatewayen godtok nøkkelen og enheten aldri skrev profilen sin.

Når et kort byttes ut eller tas ut av drift, fjern den offentlige nøkkelen og autorisasjonen sammen. En ny nøkkel er en bevisst nyregistrering, ikke en bivirkning av en reimage. Arbeidsrekkefølge: generer lokalt, autoriser mot inventaret, skriv begge sider, fastsett tilstanden, og test deretter én administrasjonsforespørsel gjennom tunnelen.

Relaterte artikler