Primer arrencada: inscripció per a una flota de dispositius WireGuard

Una imatge, una clau per placa i un pas d'autorització que no es refia de l'afirmació del propi dispositiu. Quatre etapes de l'arrencada a un peer confirmat.

La placa arrenca des de la imatge comuna, obté una concessió DHCP i un script d'aprovisionament s'executa abans que ningú hagi tocat el dispositiu. En algun punt d'aquest script ha d'obtenir una identitat WireGuard que pertanyi a aquesta placa i a cap altra, fer autoritzar aquesta identitat i escriure un perfil que la passarel·la accepti. La imatge pot portar el programari client, una plantilla revisada i la clau pública de la passarel·la. El que no ha de portar mai és una única clau privada compartida per tota la flota, perquè això converteix una sola placa robada en un incident per a tota la flota. L'ordre següent manté la identitat local i l'autorització explícita.

Què porta la imatge i què no

Envieu el paquet, la plantilla amb marcadors de posició, la clau pública de la passarel·la i el client d'inscripció. La plantilla és una forma, no un secret: ha de ser llegible per l'usuari d'aprovisionament i no ha de contenir cap material de clau.

La clau privada es genera al dispositiu en la primera arrencada i no el deixa mai. Només viatja la meitat pública, dins d'una sol·licitud d'inscripció autoritzada per una cosa diferent de l'afirmació del propi dispositiu sobre qui és. Aquesta distinció és el que impedeix que una placa robada es converteixi en un problema per a tota la flota. També és la part que la majoria dels scripts d'arrencada fan malament.

Pas 1: generar la clau localment

Executeu la generació en un directori protegit després que la connexió de xarxa subjacent estigui aprovada i funcioni. La subshell manté el canvi d'umask local a aquesta operació, i set -C es nega a sobreescriure un fitxer existent:

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

Inici ràpid de WireGuard documenta la relació de generació de claus en què es basen aquestes dues ordres. Si la generació s'interromp, deixeu el dispositiu sense inscriure i feu que el flux de treball reconciliï els fitxers. No esborreu una identitat existent només perquè el script s'executi net des del principi.

Conserveu la clau pendent entre reintents. Regenerar una identitat després de cada fallada temporal de xarxa és com una flota acaba amb peers orfes que ningú no pot aparellar amb un dispositiu.

Pas 2: autoritzar un registre de dispositiu

Suposeu que l'inventari anomena aquesta placa device-042 i li assigna 10.90.0.42/32. El servei d'inscripció ha de verificar que aquest sol·licitant té dret a aquest registre. Un número de sèrie escrit en un formulari no és una prova, perquè els números de sèrie van impresos a la part exterior de la caixa.

Una credencial d'arrencada per dispositiu, una aprovació d'operador o una atestació amb suport de maquinari poden establir l'afirmació. Protegiu la integritat de la sol·licitud i l'autenticitat de la resposta, i no substituïu un secret VPN compartit per una credencial de fàbrica compartida.

El registre inscrit lliga el dispositiu, la seva clau pública, l'adreça assignada i el seu rol de gestió permès. WireGuard mateix no defineix cap API d'inscripció, així que aquest servei és una cosa que construïu i opereu deliberadament.

Pas 3: escriure dues configuracions coincidents

El dispositiu necessita un perfil que encamini els prefixos de gestió cap al túnel, i la passarel·la necessita una entrada de peer que només permeti l'adreça d'origen pròpia d'aquest dispositiu. Amb una passarel·la a 10.90.0.1 i una xarxa de gestió de 10.60.0.0/16, el costat del dispositiu sembla així:

[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

Els valors entre claudàtors són marcadors de posició, no claus. El keepalive importa quan la placa és darrere de NAT i ha de romandre accessible; no cal a tot arreu, i afegir-lo per costum manté una ràdio desperta sense motiu.

A la passarel·la, l'entrada de peer és estreta per disseny:

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

No copieu la llista de destinacions del dispositiu a l'entrada de peer de la passarel·la. Al dispositiu aquesta llista diu què cal encaminar cap al túnel; a la passarel·la diu quines adreces d'origen pot usar aquest peer, i són afirmacions diferents.

L'encaminament, les regles de tallafoc i el camí de tornada a la xarxa de gestió encara han de permetre l'accés aprovat. Un peer inscrit no és permís per a cada aplicació al darrere.

Pas 4: confirmar la inscripció com a estat del cicle de vida

Apliqueu el registre de la passarel·la i el perfil del dispositiu a través de qui posseeix cada configuració, i després marqueu la inscripció com a completa només quan la identitat i l'adreça previstes siguin acceptades. Els reintents haurien de reconciliar aquest mateix registre en lloc d'assignar un segon peer o una segona adreça.

Manteniu un camí de recuperació per a l'aprovisionament interromput, inclòs el cas en què la passarel·la va acceptar la clau i el dispositiu no va escriure mai el seu perfil.

Quan una placa es substitueix o es retira, traieu la seva clau pública i la seva autorització alhora. Una clau nova és un esdeveniment deliberat de reinscripció, no un efecte secundari d'una reimatge. Ordre de treball: generar localment, autoritzar contra l'inventari, escriure els dos costats, confirmar l'estat i després provar una sol·licitud de gestió a través del túnel.

Articles relacionats