Primeiro arranque: rexistro para unha flota de dispositivos WireGuard

Unha imaxe, unha chave por placa e un paso de autorización que non confía na afirmación do propio dispositivo. Catro etapas desde o arranque ata un peer confirmado.

A placa arrinca desde a imaxe común, obtén unha concesión DHCP e un script de aprovisionamento execútase antes de que ninguén tocara o dispositivo. Nalgún punto dese script ten que obter unha identidade WireGuard que pertence a esta placa e a ningunha outra, facer autorizar esa identidade e escribir un perfil que a pasarela acepte. A imaxe pode levar o software cliente, un modelo revisado e a chave pública da pasarela. O que nunca debe levar é unha única chave privada compartida por toda a flota, porque iso converte unha soa placa roubada nun incidente para toda a flota. A orde seguinte mantén a identidade local e a autorización explícita.

Que leva a imaxe e que non

Envíe o paquete, o modelo con marcadores de posición, a chave pública da pasarela e o cliente de rexistro. O modelo é unha forma, non un segredo: debe ser lexible polo usuario de aprovisionamento e non conter ningún material de chave.

A chave privada xérase no dispositivo no primeiro arranque e nunca o abandona. Só viaxa a metade pública, dentro dunha solicitude de rexistro autorizada por algo distinto da afirmación do propio dispositivo sobre quen é. Ese matiz é o que impide que unha placa roubada se converta nun problema para toda a flota. Tamén é a parte que a maioría dos scripts de primeiro arranque fan mal.

Paso 1: xerar a chave localmente

Execute a xeración nun directorio protexido despois de que a conexión de rede subxacente estea aprobada e funcione. A subshell mantén o cambio de umask local a esta operación, e set -C négase a sobrescribir un ficheiro existente:

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

Inicio rápido de WireGuard documenta a relación de xeración de chaves na que se basean estas dúas ordes. Se a xeración se interrompe, deixe o dispositivo sen rexistrar e permita que o fluxo de traballo reconcilie os ficheiros. Non elimine unha identidade existente só para que o script se execute limpo desde o principio.

Conserve a chave pendente entre reintentos. Xerar de novo unha identidade tras cada fallo temporal de rede é como unha flota acaba con peers orfos que ninguén pode emparellar cun dispositivo.

Paso 2: autorizar un rexistro de dispositivo

Supoña que o inventario chama a esta placa device-042 e lle asigna 10.90.0.42/32. O servizo de rexistro ten que verificar que este solicitante ten dereito a ese rexistro. Un número de serie escrito nun formulario non é proba, porque os números de serie van impresos na parte exterior da caixa.

Unha credencial de arranque por dispositivo, unha aprobación de operador ou unha atestación con respaldo de hardware poden establecer a afirmación. Protexa a integridade da solicitude e a autenticidade da resposta, e non substitúa un segredo VPN compartido por unha credencial de fábrica compartida.

O rexistro inscrito vincula o dispositivo, a súa chave pública, o enderezo asignado e o seu rol de xestión permitido. WireGuard non define ningunha API de rexistro, así que ese servizo é algo que vostede constrúe e opera deliberadamente.

Paso 3: escribir dúas configuracións coincidentes

O dispositivo necesita un perfil que encamiñe os prefixos de xestión cara ao túnel, e a pasarela necesita unha entrada de peer que só permita o enderezo de orixe propio deste dispositivo. Cunha pasarela en 10.90.0.1 e unha rede de xestión de 10.60.0.0/16, o lado do dispositivo queda así:

[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

Os valores entre corchetes son marcadores de posición, non chaves. O keepalive importa cando a placa está detrás de NAT e ten que seguir sendo accesible; non fai falta en todas partes, e engadilo por costume mantén unha radio esperta sen motivo.

Na pasarela, a entrada de peer é estreita por deseño:

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

Non copie a lista de destinos do dispositivo no peer da pasarela. No dispositivo esa lista di que encamiñar cara ao túnel; na pasarela di que enderezos de orixe pode usar este peer, e son afirmacións distintas.

O reenvío, as regras de cortafogos e a ruta de volta á rede de xestión aínda teñen que permitir o acceso aprobado. Un peer rexistrado non é permiso para cada aplicación que hai detrás.

Paso 4: confirmar o rexistro como estado do ciclo de vida

Aplique o rexistro da pasarela e o perfil do dispositivo a través de quen posúe cada configuración, e despois marque o rexistro como completo só cando se acepten a identidade e o enderezo previstos. Os reintentos deberían reconciliar ese mesmo rexistro en lugar de asignar un segundo peer ou un segundo enderezo.

Manteña unha ruta de recuperación para o aprovisionamento interrompido, incluído o caso en que a pasarela aceptou a chave e o dispositivo nunca escribiu o seu perfil.

Cando se substitúe ou se retira unha placa, elimine a súa chave pública e a súa autorización á vez. Unha chave nova é un evento deliberado de reinscrición, non un efecto secundario dunha nova imaxe. Orde de traballo: xerar localmente, autorizar contra o inventario, escribir ambos os dous lados, confirmar o estado e despois probar unha solicitude de xestión a través do túnel.

Artigos relacionados