Primer arranque: registro para una flota de dispositivos WireGuard

La placa arranca desde la imagen común, obtiene una concesión DHCP y un script de aprovisionamiento se ejecuta antes de que nadie haya tocado el dispositivo. En algún punto de ese script tiene que obtener una identidad WireGuard que pertenezca a esta placa y a ninguna otra, hacer que esa identidad se autorice y escribir un perfil que la puerta de enlace acepte. La imagen puede llevar el software cliente, una plantilla revisada y la clave pública de la puerta de enlace. Lo que nunca debe llevar es una única clave privada compartida por toda la flota, porque eso convierte una sola placa robada en un incidente para toda la flota. El orden siguiente mantiene la identidad local y la autorización explícita.

Qué lleva la imagen y qué no

Envíe el paquete, la plantilla con marcadores de posición, la clave pública de la puerta de enlace y el cliente de registro. La plantilla es una forma, no un secreto: debe ser legible por el usuario de aprovisionamiento y no contener ningún material de clave.

La clave privada se genera en el dispositivo en el primer arranque y nunca lo abandona. Solo viaja la mitad pública, dentro de una solicitud de registro autorizada por algo distinto de la afirmación del propio dispositivo sobre quién es. Esa distinción es lo que impide que una placa robada se convierta en un problema para toda la flota. También es la parte que la mayoría de los scripts de primer arranque hacen mal.

Paso 1: generar la clave localmente

Ejecute la generación en un directorio protegido después de que la conexión de red subyacente esté aprobada y funcione. La subshell mantiene el cambio de umask local a esta operación, y set -C se niega a sobrescribir un archivo 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 la relación de generación de claves en la que se basan estos dos comandos. Si la generación se interrumpe, deje el dispositivo sin registrar y permita que el flujo de trabajo reconcilie los archivos. No elimine una identidad existente solo para que el script se ejecute limpio desde el principio.

Conserve la clave pendiente entre reintentos. Regenerar una identidad tras cada fallo temporal de red es la forma en que una flota acaba con peers huérfanos que nadie puede emparejar con un dispositivo.

Paso 2: autorizar un registro de dispositivo

Suponga que el inventario llama a esta placa device-042 y le asigna 10.90.0.42/32. El servicio de registro tiene que verificar que este solicitante tiene derecho a ese registro. Un número de serie escrito en un formulario no es prueba, porque los números de serie van impresos en el exterior de la caja.

Una credencial de arranque por dispositivo, una aprobación de operador o una atestación con respaldo de hardware pueden establecer la afirmación. Proteja la integridad de la solicitud y la autenticidad de la respuesta, y no sustituya un secreto VPN compartido por una credencial de fábrica compartida.

El registro inscrito vincula el dispositivo, su clave pública, su dirección asignada y su rol de gestión permitido. WireGuard no define ninguna API de registro, así que ese servicio es algo que usted construye y opera deliberadamente.

Paso 3: escribir dos configuraciones coincidentes

El dispositivo necesita un perfil que encamine los prefijos de gestión hacia el túnel, y la puerta de enlace necesita una entrada de peer que solo permita la dirección de origen propia de este dispositivo. Con una puerta de enlace en 10.90.0.1 y una red de gestión de 10.60.0.0/16, el lado del dispositivo se ve 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

Los valores entre corchetes son marcadores de posición, no claves. El keepalive importa cuando la placa está detrás de NAT y tiene que seguir siendo accesible; no hace falta en todas partes, y añadirlo por costumbre mantiene una radio despierta sin motivo.

En la puerta de enlace, la entrada de peer es estrecha por diseño:

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

No copie la lista de destinos del dispositivo en el peer de la puerta de enlace. En el dispositivo esa lista dice qué encaminar hacia el túnel; en la puerta de enlace dice qué direcciones de origen puede usar este peer, y son afirmaciones distintas.

El reenvío, las reglas de cortafuegos y la ruta de vuelta a la red de gestión todavía tienen que permitir el acceso aprobado. Un peer registrado no es permiso para cada aplicación que hay detrás.

Paso 4: confirmar el registro como estado del ciclo de vida

Aplique el registro de la puerta de enlace y el perfil del dispositivo a través de quien posea cada configuración, y luego marque el registro como completo solo cuando se acepten la identidad y la dirección previstas. Los reintentos deberían reconciliar ese mismo registro en lugar de asignar un segundo peer o una segunda dirección.

Mantenga una ruta de recuperación para el aprovisionamiento interrumpido, incluido el caso en que la puerta de enlace aceptó la clave y el dispositivo nunca escribió su perfil.

Cuando se sustituye o retira una placa, elimine su clave pública y su autorización a la vez. Una clave nueva es un evento deliberado de reinscripción, no un efecto secundario de una reimagen. Orden de trabajo: generar localmente, autorizar contra el inventario, escribir ambos lados, confirmar el estado y después probar una solicitud de gestión a través del túnel.