Første opstart: tilmelding for en flåde af WireGuard-enheder

Ét image, én nøgle per kort og et autorisationstrin, der ikke stoler på enhedens eget udsagn. Fire faser fra opstart til en fastlagt peer.

Kortet starter fra det fælles image, får en DHCP-lease, og et provisioning-script kører, før nogen har rørt enheden. Et sted i det script skal det skaffe en WireGuard-identitet, der hører til dette kort og ingen andre, få den identitet autoriseret og skrive en profil, som gatewayen accepterer. Imaget må gerne indeholde klientsoftwaren, en gennemgået skabelon og gatewayens offentlige nøgle. Det må aldrig indeholde én privat nøgle, som hele flåden deler, for det gør ét stjålet kort til en hændelse for hele flåden. Rækkefølgen nedenfor holder identiteten lokal og autorisationen eksplicit.

Hvad imaget indeholder – og hvad det ikke gør

Medsend pakken, skabelonen med pladsholdere, gatewayens offentlige nøgle og tilmeldingsklienten. Skabelonen er en form, ikke en hemmelighed: den skal kunne læses af provisioning-brugeren og ikke indeholde nøglemateriale.

Den private nøgle genereres på enheden ved første opstart og forlader den aldrig. Kun den offentlige halvdel rejser, inde i en tilmeldingsanmodning, der autoriseres af noget andet end enhedens eget udsagn om, hvem den er. Den forskel er det, der forhindrer et stjålet kort i at blive et problem for hele flåden. Det er også den del, som de fleste first-boot-scripts gør forkert.

Trin 1: generér nøglen lokalt

Kør genereringen i en beskyttet mappe, efter at den underliggende netværksforbindelse er godkendt og virker. Subshellen holder umask-ændringen lokal for denne handling, og set -C nægter at 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 beskrives den nøglegenereringssammenhæng, som de to kommandoer bygger på. Hvis genereringen afbrydes, så lad enheden være utilmeldt og lad arbejdsgangen afstemme filerne. Slet ikke en eksisterende identitet bare for at få scriptet til at køre rent fra toppen.

Bevar den ventende nøgle på tværs af nye forsøg. At generere en identitet igen efter hver midlertidig netværksfejl er måden, hvorpå en flåde ender med forældreløse peers, som ingen kan knytte til en enhed.

Trin 2: autorisér en enhedspost

Antag, at inventaret kalder dette kort device-042 og tildeler det 10.90.0.42/32. Tilmeldingstjenesten skal bekræfte, at den, der anmoder om det, har ret til posten. Et serienummer, der er skrevet ind i en formular, er ikke bevis, for serienumre er trykt på ydersiden af æsken.

En bootstrap-legitimation per enhed, en godkendelse fra en operatør eller en hardwareunderstøttet attestation kan fastslå kravet. Beskyt anmodningens integritet og svarets ægthed, og erstat ikke én delt VPN-hemmelighed med én delt fabrikslegitimation.

Den registrerede post binder enheden, dens offentlige nøgle, dens tildelte adresse og dens tilladte administrationsrolle. WireGuard definerer ikke selv noget tilmeldings-API, så den tjeneste er noget, du bygger og driver bevidst.

Trin 3: skriv to konfigurationer, der passer sammen

Enheden har brug for en profil, der router administrationspræfikserne ind i tunnelen, og gatewayen har brug for en peer-post, der kun tillader enhedens egen kildeadresse. Med en gateway på 10.90.0.1 og et administrationsnet på 10.60.0.0/16 ser enhedssiden sådan ud:

[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ærdierne i kantede parenteser er pladsholdere, ikke nøgler. Keepalive betyder noget, når kortet sidder bag NAT og skal forblive nåbart; det er ikke nødvendigt overalt, og hvis man tilføjer det af vane, holder man en radio vågen uden grund.

På gatewayen er peer-posten bevidst snæver:

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

Kopiér ikke enhedens destinationsliste over på gateway-peeren. På enheden siger listen, hvad der skal routes ind i tunnelen; på gatewayen siger den, hvilke kildeadresser denne peer må bruge, og det er forskellige udsagn.

Videresendelse, firewallregler og returvejen til administrationsnettet skal stadig tillade den godkendte adgang. En registreret peer er ikke tilladelse til hver applikation bag den.

Trin 4: fastlæg tilmeldingen som en livscyklustilstand

Anvend gateway-posten og enhedsprofilen gennem den, der ejer den enkelte konfiguration, og markér først tilmeldingen som fuldført, når den tilsigtede identitet og adresse er accepteret. Nye forsøg bør afstemme den samme post i stedet for at tildele en anden peer eller en anden adresse.

Hold en gendannelsesvej for afbrudt provisioning, inklusive tilfældet hvor gatewayen accepterede nøglen, og enheden aldrig skrev sin profil.

Når et kort udskiftes eller udfases, skal dets offentlige nøgle og dets autorisation fjernes sammen. En ny nøgle er en bevidst gentilmelding, ikke en bivirkning af en reimage. Arbejdsrækkefølge: generér lokalt, autorisér mod inventaret, skriv begge sider, fastlæg tilstanden, og test derefter én administrationsanmodning gennem tunnelen.

Relaterede artikler