Første oppstart: registrering for ein flåte av WireGuard-einingar

Eitt image, éin nøkkel per kort og eit autorisasjonssteg som ikkje trur på påstanden til eininga sjølv. Fire trinn frå oppstart til ein fastsett peer.

Kortet startar frå det felles imaget, får ein DHCP-leige, og eit provisjoneringsskript køyrer før nokon har rørt eininga. Ein stad i det skriptet må det skaffe ein WireGuard-identitet som høyrer til dette kortet og ingen andre, få den identiteten autorisert og skrive ein profil som gatewayen godtek. Imaget kan bere klientprogramvara, ein gjennomgått mal og den offentlege nøkkelen til gatewayen. Det det aldri kan bere, er éin privat nøkkel som heile flåten deler, for det gjer eitt stole kort til ein hending for heile flåten. Rekkjefølgja nedanfor held identiteten lokal og autorisasjonen eksplisitt.

Kva imaget ber, og kva det ikkje ber

Lever pakken, malen med plasshaldarar, den offentlege nøkkelen til gatewayen og registreringsklienten. Malen er ei form, ikkje ei hemmelegheit: han skal vera lesbar for provisjoneringsbrukaren og ikkje innehalde noko nøkkelmateriale.

Den private nøkkelen blir generert på eininga ved første oppstart og forlèt henne aldri. Berre den offentlege halvdelen reiser, inne i ein registreringsførespurnad som blir autorisert av noko anna enn påstanden til eininga sjølv om kven ho er. Den skilnaden er det som hindrar eit stole kort i å bli eit problem for heile flåten. Og det er også den delen dei fleste first-boot-skript gjer feil.

Trinn 1: generer nøkkelen lokalt

Køyr genereringa i ein verna katalog etter at den underliggjande nettverkskoplinga er godkjend og verkar. Underskala held umask-endringa lokal for denne operasjonen, og set -C nektar å skrive over ei eksisterande fil:

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

WireGuard hurtigstart dokumenterer nøkkelgenereringssambandet som desse to kommandoane byggjer på. Om genereringa blir avbroten, lat eininga vera uregistrert og lat arbeidsflyten jamne ut filene. Ikkje slett ein eksisterande identitet berre for at skriptet skal køyre reint frå byrjinga.

Ta vare på den ventande nøkkelen gjennom nye forsøk. Å generere ein identitet på nytt etter kvar mellombels nettverksfeil er korleis ein flåte endar med foreldrelause peers som ingen kan knyte til ei eining.

Trinn 2: autoriser ein einingsoppføring

Anta at inventaret kallar dette kortet device-042 og tildeler det 10.90.0.42/32. Registreringstenesta må stadfeste at den som ber om dette, har rett til oppføringa. Eit serienummer skrive inn i eit skjema er ikkje bevis, for serienummer er trykte på utsida av eska.

Ein bootstrap-legitimasjon per eining, ei godkjenning frå ein operatør eller ein maskinvarestøtta attestasjon kan feste påstanden. Vern integriteten til førespurnaden og ektheita til svaret, og byt ikkje ut éi delt VPN-hemmelegheit med éin delt fabrikklegitimasjon.

Den registrerte oppføringa bind eininga, den offentlege nøkkelen hennar, den tildelte adressa og den tillatne styringa. WireGuard sjølv definerer ikkje noko registrerings-API, så den tenesta er noko du byggjer og driv medvite.

Trinn 3: skriv to konfigurasjonar som passar saman

Eininga treng ein profil som rutar styringsprefiksa inn i tunnelen, og gatewayen treng ei peer-oppføring som berre tillèt den eigne kjeldeadressa til denne eininga. Med ein gateway på 10.90.0.1 og eit styringsnett på 10.60.0.0/16 ser eininga si side 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

Verdiane i hakeparentesar er plasshaldarar, ikkje nøklar. Keepalive har noko å seie når kortet sit bak NAT og må vera tilgjengeleg; det er ikkje naudsynt overalt, og å leggje det til av vane held ein radio vaken utan grunn.

På gatewayen er peer-oppføringa medvite smal:

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

Ikkje kopier mållista til eininga over til gateway-peeren. På eininga seier lista kva som skal rutast inn i tunnelen; på gatewayen seier ho kva kjeldeadresser denne peeren kan bruke, og det er ulike utsegner.

Vidaresending, brannmurreglar og returvegen til styringsnettet må framleis tillate den godkjende tilgangen. Ein registrert peer er ikkje løyve for kvar applikasjon bak han.

Trinn 4: fest registreringa som ein livssyklustilstand

Bruk gateway-oppføringa og eining-profilen gjennom den som eig kvar konfigurasjon, og merk registreringa som fullført først når den tiltenkte identiteten og adressa blir godtekne. Nye forsøk bør jamne ut den same oppføringa i staden for å tildele ein annan peer eller ei anna adresse.

Hald ein gjenopprettingsveg for avbroten provisjonering, inkludert tilfellet der gatewayen godtok nøkkelen og eininga aldri skreiv profilen sin.

Når eit kort blir bytt ut eller teke ut av drift, fjern den offentlege nøkkelen og autorisasjonen saman. Ein ny nøkkel er ei medvite nyregistrering, ikkje ein biverknad av ein reimage. Arbeidsrekkjefølgje: generer lokalt, autoriser mot inventaret, skriv begge sider, fest tilstanden, og test deretter éin styringsførespurnad gjennom tunnelen.

Relaterte artiklar