Första uppstarten: registrering för en flotta av WireGuard-enheter

En image, en nyckel per kort och ett auktoriseringssteg som inte litar på enhetens eget påstående. Fyra steg från uppstart till en fastställd peer.

Kortet startar från den gemensamma imagen, får en DHCP-lease och ett provisioning-skript körs innan någon har rört enheten. Någonstans i det skriptet måste det skaffa en WireGuard-identitet som hör till det här kortet och inget annat, få den identiteten auktoriserad och skriva en profil som gatewayen accepterar. Imagen får innehålla klientprogramvaran, en granskad mall och gatewayens publika nyckel. Det den aldrig får innehålla är en enda privat nyckel som delas av hela flottan, för det gör ett enda stulet kort till en incident för hela flottan. Ordningen nedan håller identiteten lokal och auktoriseringen explicit.

Vad imagen innehåller – och vad den inte gör

Skicka med paketet, mallen med platshållare, gatewayens publika nyckel och registreringsklienten. Mallen är en form, inte en hemlighet: den ska vara läsbar för provisioning-användaren och inte innehålla något nyckelmaterial.

Den privata nyckeln genereras på enheten vid första uppstarten och lämnar den aldrig. Bara den publika halvan färdas, inuti en registreringsbegäran som auktoriseras av något annat än enhetens eget påstående om vem den är. Den skillnaden är det som hindrar ett stulet kort från att bli ett problem för hela flottan. Det är också den del som de flesta first-boot-skript gör fel.

Steg 1: generera nyckeln lokalt

Kör genereringen i en skyddad katalog efter att den underliggande nätverksanslutningen är godkänd och fungerar. Subshellen håller umask-ändringen lokal för den här operationen, och set -C vägrar skriva över en befintlig fil:

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

I WireGuard-snabbstarten dokumenteras det nyckelgenereringssamband som de här två kommandona bygger på. Om genereringen avbryts, lämna enheten oregistrerad och låt arbetsflödet stämma av filerna. Radera inte en befintlig identitet bara för att skriptet ska kunna köras rent från början.

Behåll den väntande nyckeln över nya försök. Att generera om en identitet efter varje tillfälligt nätverksfel är hur en flotta hamnar med föräldralösa peers som ingen kan koppla till en enhet.

Steg 2: auktorisera en enhetspost

Anta att inventariet kallar det här kortet device-042 och tilldelar det 10.90.0.42/32. Registreringstjänsten måste verifiera att den som begär detta har rätt till posten. Ett serienummer som skrivits in i ett formulär är inget bevis, för serienummer står tryckta på utsidan av lådan.

En bootstrap-uppgift per enhet, ett operatörsgodkännande eller en hårdvarubackad attestation kan fastställa anspråket. Skydda begärans integritet och svarets äkthet, och ersätt inte en delad VPN-hemlighet med en delad fabriksuppgift.

Den registrerade posten binder enheten, dess publika nyckel, dess tilldelade adress och dess tillåtna hanteringsroll. WireGuard definierar självt inget registrerings-API, så den tjänsten är något du bygger och driver medvetet.

Steg 3: skriv två matchande konfigurationer

Enheten behöver en profil som routar hanteringsprefixen in i tunneln, och gatewayen behöver en peer-post som bara tillåter enhetens egen källadress. Med en gateway på 10.90.0.1 och ett hanteringsnät på 10.60.0.0/16 ser enhetssidan ut så här:

[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ärdena inom hakparenteser är platshållare, inte nycklar. Keepalive spelar roll när kortet sitter bakom NAT och måste förbli nåbart; det krävs inte överallt, och att lägga till det av vana håller en radio vaken utan anledning.

På gatewayen är peer-posten medvetet snäv:

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

Kopiera inte enhetens destinationslista till gateway-peeren. På enheten säger listan vad som ska routas in i tunneln; på gatewayen säger den vilka källadresser den här peeren får använda, och det är olika påståenden.

Vidarebefordran, brandväggsregler och returvägen till hanteringsnätet måste fortfarande tillåta den godkända åtkomsten. En registrerad peer är inte tillstånd för varje program bakom den.

Steg 4: fastställ registreringen som ett livscykeltillstånd

Tillämpa gateway-posten och enhetsprofilen genom den som äger respektive konfiguration, och markera sedan registreringen som klar först när den avsedda identiteten och adressen accepteras. Nya försök bör stämma av samma post i stället för att tilldela en andra peer eller en andra adress.

Håll en återställningsväg för avbruten provisioning, inklusive fallet där gatewayen accepterade nyckeln och enheten aldrig skrev sin profil.

När ett kort byts ut eller tas ur drift, ta bort dess publika nyckel och dess auktorisering tillsammans. En ny nyckel är en medveten omregistrering, inte en bieffekt av en reimage. Arbetsordning: generera lokalt, auktorisera mot inventariet, skriv båda sidorna, fastställ tillståndet och testa sedan en hanteringsbegäran genom tunneln.

Relaterade artiklar