Primo avvio: registrazione per una flotta di dispositivi WireGuard

Un'immagine, una chiave per scheda e un passo di autorizzazione che non si fida dell'affermazione del dispositivo stesso. Quattro fasi dall'avvio a un peer confermato.

La scheda si avvia dall'immagine comune, ottiene una lease DHCP e uno script di provisioning viene eseguito prima che qualcuno abbia toccato il dispositivo. Da qualche parte in quello script deve ottenere un'identità WireGuard che appartiene a questa scheda e a nessun'altra, far autorizzare quell'identità e scrivere un profilo che il gateway accetterà. L'immagine può trasportare il software client, un modello revisionato e la chiave pubblica del gateway. Ciò che non deve mai trasportare è un'unica chiave privata condivisa da tutta la flotta, perché questo trasforma una sola scheda rubata in un incidente per tutta la flotta. L'ordine seguente mantiene l'identità locale e l'autorizzazione esplicita.

Cosa trasporta l'immagine e cosa no

Distribuite il pacchetto, il modello con segnaposto, la chiave pubblica del gateway e il client di registrazione. Il modello è una forma, non un segreto: deve essere leggibile dall'utente di provisioning e non contenere materiale di chiave.

La chiave privata viene generata sul dispositivo al primo avvio e non lo lascia mai. Viaggia solo la metà pubblica, dentro una richiesta di registrazione autorizzata da qualcosa di diverso dall'affermazione del dispositivo su chi sia. È questa distinzione che impedisce a una scheda rubata di diventare un problema per tutta la flotta. Ed è anche la parte che la maggior parte degli script di primo avvio sbaglia.

Passo 1: generare la chiave localmente

Eseguite la generazione in una directory protetta dopo che la connessione di rete sottostante è approvata e funzionante. La subshell mantiene la modifica di umask locale a questa operazione, e set -C rifiuta di sovrascrivere un file esistente:

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

Avvio rapido di WireGuard documenta la relazione di generazione delle chiavi su cui si basano questi due comandi. Se la generazione viene interrotta, lasciate il dispositivo non registrato e lasciate che il flusso di lavoro riconcili i file. Non eliminate un'identità esistente solo perché lo script funzioni in modo pulito dall'inizio.

Conservate la chiave in sospeso tra i tentativi. Rigenerare un'identità dopo ogni guasto di rete temporaneo è il modo in cui una flotta finisce con peer orfani che nessuno può associare a un dispositivo.

Passo 2: autorizzare un record di dispositivo

Supponete che l'inventario chiami questa scheda device-042 e le assegni 10.90.0.42/32. Il servizio di registrazione deve verificare che questo richiedente abbia diritto a quel record. Un numero di serie digitato in un modulo non è una prova, perché i numeri di serie sono stampati all'esterno della scatola.

Una credenziale di bootstrap per dispositivo, un'approvazione dell'operatore o un'attestazione supportata dall'hardware possono stabilire l'affermazione. Proteggete l'integrità della richiesta e l'autenticità della risposta, e non sostituite un segreto VPN condiviso con una credenziale di fabbrica condivisa.

Il record registrato lega il dispositivo, la sua chiave pubblica, l'indirizzo assegnato e il ruolo di gestione consentito. WireGuard stesso non definisce alcuna API di registrazione, quindi quel servizio è qualcosa che costruite e gestite deliberatamente.

Passo 3: scrivere due configurazioni corrispondenti

Il dispositivo ha bisogno di un profilo che instradi i prefissi di gestione nel tunnel, e il gateway ha bisogno di una voce peer che consenta solo l'indirizzo sorgente proprio di questo dispositivo. Con un gateway su 10.90.0.1 e una rete di gestione di 10.60.0.0/16, il lato dispositivo appare così:

[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

I valori tra parentesi quadre sono segnaposto, non chiavi. Il keepalive conta quando la scheda sta dietro NAT e deve restare raggiungibile; non è richiesto ovunque, e aggiungerlo per abitudine tiene una radio sveglia senza motivo.

Sul gateway, la voce peer è stretta per scelta:

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

Non copiate l'elenco delle destinazioni del dispositivo nella voce peer del gateway. Sul dispositivo quell'elenco dice cosa instradare nel tunnel; sul gateway dice quali indirizzi sorgente questo peer può usare, e sono affermazioni diverse.

L'inoltro, le regole del firewall e il percorso di ritorno verso la rete di gestione devono ancora consentire l'accesso approvato. Un peer registrato non è un permesso per ogni applicazione che sta dietro.

Passo 4: confermare la registrazione come stato del ciclo di vita

Applicate il record del gateway e il profilo del dispositivo tramite chi possiede ciascuna configurazione, poi segnate la registrazione come completa solo quando l'identità e l'indirizzo previsti vengono accettati. I tentativi dovrebbero riconciliare quello stesso record invece di allocare un secondo peer o un secondo indirizzo.

Mantenete un percorso di recupero per il provisioning interrotto, incluso il caso in cui il gateway ha accettato la chiave e il dispositivo non ha mai scritto il suo profilo.

Quando una scheda viene sostituita o ritirata, rimuovete la sua chiave pubblica e la sua autorizzazione insieme. Una nuova chiave è un evento di nuova registrazione deliberato, non un effetto collaterale di una reimmagine. Ordine di lavoro: generare localmente, autorizzare rispetto all'inventario, scrivere entrambi i lati, confermare lo stato, poi provare una richiesta di gestione attraverso il tunnel.

Articoli correlati