Eerste opstart: inskrywing vir 'n vloot WireGuard-toestelle

Een image, een sleutel per bord en 'n magtigingstap wat nie die toestel se eie bewering vertrou nie. Vier fases van opstart tot 'n vasgelê peer.

Die bord begin van die gemeenskaplike image, kry 'n DHCP-huur, en 'n voorsieningskrip loop voordat enigiemand die toestel aangeraak het. Ergens in daardie skrip moet dit 'n WireGuard-identiteit kry wat aan hierdie bord en aan geen ander behoort nie, daardie identiteit laat magtig, en 'n profiel skryf wat die poort aanvaar. Die image kan die kliëntesagteware, 'n nagegane sjabloon en die poort se publieke sleutel bevat. Wat dit nooit mag bevat nie, is een private sleutel wat die hele vloot deel, want dit maak van een gesteelde bord 'n voorval vir die hele vloot. Die volgorde hieronder hou die identiteit plaaslik en die magtiging uitdruklik.

Wat die image bevat, en wat nie

Stuur die pakket, die sjabloon met plekhouers, die poort se publieke sleutel en die inskrywingskliënt saam. Die sjabloon is 'n vorm, nie 'n geheim nie: dit moet deur die voorsieningsgebruiker leesbaar wees en geen sleutelmateriaal bevat nie.

Die private sleutel word by die eerste opstart op die toestel gegenereer en verlaat dit nooit. Net die publieke helfte reis, binne 'n inskrywingsversoek wat gemagtig word deur iets anders as die toestel se eie bewering oor wie hy is. Daardie onderskeid is wat keer dat 'n gesteelde bord 'n probleem vir die hele vloot word. Dit is ook die deel wat die meeste eerste-opstart-skripte verkeerd doen.

Stap 1: genereer die sleutel plaaslik

Voer die generering in 'n beskermde gids uit nadat die onderliggende netwerkverbinding goedgekeur is en werk. Die subspers hou die umask-verandering plaaslik vir hierdie bewerking, en set -C weier om 'n bestaande lêer te oorskryf:

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

Die WireGuard-vinnige begin dokumenteer die sleutelgenereringsverhouding waarop hierdie twee opdragte staatmaak. As die generering onderbreek word, laat die toestel oningeskryf en laat die werkvloei die lêers met mekaar versoen. Moenie 'n bestaande identiteit uitwis net om die skrip skoon van bo af te laat loop nie.

Bewaar die hangende sleutel oor herprobeerslae heen. Om 'n identiteit na elke tydelike netwerkfout te hergenereer, is hoe 'n vloot agterbly met wees-peers wat niemand aan 'n toestel kan koppel nie.

Stap 2: magtig 'n toestelrekord

Veronderstel die voorraad noem hierdie bord device-042 en ken 10.90.0.42/32 daaraan toe. Die inskrywingsdiens moet verifieer dat hierdie aanvraer op daardie rekord geregtig is. 'n Reeksnommer wat in 'n vorm getik word, is nie bewys nie, want reeksnommers word op die buitekant van die boks gedruk.

'n Bootstrap-bewys per toestel, 'n operateur-goedkeuring of 'n hardeware-gesteunde attestasie kan die aanspraak vestig. Beskerm die versoek se integriteit en die antwoord se egtheid, en vervang nie een gedeelde VPN-geheim met een gedeelde fabrieksbewys nie.

Die geregistreerde rekord bind die toestel, sy publieke sleutel, sy toegewysde adres en sy toegelate bestuursrol. WireGuard definieer self geen inskrywings-API nie, so daardie diens is iets wat jy doelbewus bou en bedryf.

Stap 3: skryf twee passende konfigurasies

Die toestel het 'n profiel nodig wat die bestuursprefikse in die tonnel instuur, en die poort het 'n peer-inskrywing nodig wat net hierdie toestel se eie bronadres toelaat. Met 'n poort op 10.90.0.1 en 'n bestuursnetwerk van 10.60.0.0/16 lyk die toestelkant so:

[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

Die waardes tussen hakies is plekhouers, nie sleutels nie. Die keepalive maak saak wanneer die bord agter NAT sit en bereikbaar moet bly; dit is nie oral nodig nie, en om dit uit gewoonte by te voeg hou 'n radio wakker sonder rede.

Op die poort is die peer-inskrywing doelbewus smal:

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

Moenie die toestel se bestemmingslys na die poort-peer kopieer nie. Op die toestel sê daardie lys wat in die tonnel ingestuur moet word; op die poort sê dit watter bronadresse hierdie peer mag gebruik, en dit is verskillende stellings.

Deurstuur, firewall-reëls en die terugpad na die bestuursnetwerk moet steeds die goedgekeurde toegang toelaat. 'n Geregistreerde peer is nie toestemming vir elke toepassing daar agter nie.

Stap 4: lê inskrywing as 'n lewensiklustoestand vas

Pas die poortrekord en die toestelprofiel toe deur wie elkeen se konfigurasie besit, en merk inskrywing eers voltooi wanneer die beoogde identiteit en adres aanvaar is. Herprobeerslae moet dieselfde rekord versoen eerder as om 'n tweede peer of 'n tweede adres toe te wys.

Hou 'n herstelpad vir onderbroke voorsiening, insluitend die geval waar die poort die sleutel aanvaar het en die toestel nooit sy profiel geskryf het nie.

Wanneer 'n bord vervang of uit diens onttrek word, verwyder sy publieke sleutel en sy magtiging saam. 'n Nuwe sleutel is 'n doelbewuste herinskrywing, nie 'n newe-effek van 'n herbeelding nie. Werkorde: genereer plaaslik, magtig teen die voorraad, skryf beide kante, lê die toestand vas, en toets dan een bestuursversoek deur die tonnel.

Verwante artikels