Premier démarrage : enrôlement d'une flotte d'appareils WireGuard

Une image, une clé par carte et une étape d'autorisation qui ne fait pas confiance à l'affirmation de l'appareil lui-même. Quatre étapes du démarrage à un peer validé.

La carte démarre depuis l'image commune, obtient un bail DHCP, et un script de provisionnement s'exécute avant que quiconque ait touché l'appareil. Quelque part dans ce script, il doit obtenir une identité WireGuard qui appartient à cette carte et à aucune autre, faire autoriser cette identité, et écrire un profil que la passerelle acceptera. L'image peut transporter le logiciel client, un modèle revu et la clé publique de la passerelle. Ce qu'elle ne doit jamais transporter, c'est une clé privée unique partagée par toute la flotte, car cela transforme une seule carte volée en incident pour toute la flotte. L'ordre ci-dessous garde l'identité locale et l'autorisation explicite.

Ce que l'image transporte, et ce qu'elle ne transporte pas

Livrez le paquet, le modèle avec des espaces réservés, la clé publique de la passerelle et le client d'enrôlement. Le modèle est une forme, pas un secret : il doit être lisible par l'utilisateur de provisionnement et ne contenir aucun matériel de clé.

La clé privée est générée sur l'appareil au premier démarrage et ne le quitte jamais. Seule la moitié publique voyage, à l'intérieur d'une demande d'enrôlement autorisée par autre chose que l'affirmation de l'appareil sur ce qu'il est. C'est cette distinction qui empêche une carte volée de devenir un problème pour toute la flotte. C'est aussi la partie que la plupart des scripts de premier démarrage ratent.

Étape 1 : générer la clé localement

Lancez la génération dans un répertoire protégé une fois la connexion réseau sous-jacente approuvée et fonctionnelle. Le sous-shell garde le changement d'umask local à cette opération, et set -C refuse d'écraser un fichier existant :

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

Démarrage rapide de WireGuard documente la relation de génération de clés sur laquelle reposent ces deux commandes. Si la génération est interrompue, laissez l'appareil non enrôlé et laissez le flux de travail réconcilier les fichiers. Ne supprimez pas une identité existante juste pour que le script s'exécute proprement depuis le début.

Conservez la clé en attente entre les tentatives. Régénérer une identité après chaque panne réseau temporaire, c'est ainsi qu'une flotte finit avec des peers orphelins que personne ne peut associer à un appareil.

Étape 2 : autoriser un enregistrement d'appareil

Supposons que l'inventaire appelle cette carte device-042 et lui attribue 10.90.0.42/32. Le service d'enrôlement doit vérifier que ce demandeur a droit à cet enregistrement. Un numéro de série saisi dans un formulaire n'est pas une preuve, car les numéros de série sont imprimés à l'extérieur de la boîte.

Un justificatif d'amorçage par appareil, une approbation d'opérateur ou une attestation adossée au matériel peuvent établir l'affirmation. Protégez l'intégrité de la demande et l'authenticité de la réponse, et ne remplacez pas un secret VPN partagé par un justificatif d'usine partagé.

L'enregistrement inscrit lie l'appareil, sa clé publique, l'adresse qui lui est attribuée et son rôle de gestion autorisé. WireGuard lui-même ne définit aucune API d'enrôlement, donc ce service est quelque chose que vous construisez et exploitez délibérément.

Étape 3 : écrire deux configurations concordantes

L'appareil a besoin d'un profil qui achemine les préfixes de gestion dans le tunnel, et la passerelle a besoin d'une entrée de peer qui n'autorise que l'adresse source propre à cet appareil. Avec une passerelle à 10.90.0.1 et un réseau de gestion en 10.60.0.0/16, le côté appareil ressemble à ceci :

[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

Les valeurs entre crochets sont des espaces réservés, pas des clés. Le keepalive compte lorsque la carte se trouve derrière NAT et doit rester joignable ; il n'est pas requis partout, et l'ajouter par habitude maintient une radio éveillée sans raison.

Sur la passerelle, l'entrée de peer est étroite par conception :

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

Ne copiez pas la liste de destinations de l'appareil sur le peer de la passerelle. Sur l'appareil, cette liste indique quoi acheminer dans le tunnel ; sur la passerelle, elle indique quelles adresses source ce peer peut utiliser, et ce sont des affirmations différentes.

Le transfert, les règles de pare-feu et le chemin de retour vers le réseau de gestion doivent encore autoriser l'accès approuvé. Un peer enregistré n'est pas une autorisation pour chaque application derrière lui.

Étape 4 : valider l'enrôlement comme état de cycle de vie

Appliquez l'enregistrement de la passerelle et le profil de l'appareil par l'intermédiaire de qui possède chaque configuration, puis marquez l'enrôlement terminé seulement lorsque l'identité et l'adresse prévues sont acceptées. Les tentatives doivent réconcilier ce même enregistrement plutôt que d'allouer un second peer ou une seconde adresse.

Gardez un chemin de récupération pour un provisionnement interrompu, y compris le cas où la passerelle a accepté la clé et où l'appareil n'a jamais écrit son profil.

Lorsqu'une carte est remplacée ou retirée, supprimez sa clé publique et son autorisation ensemble. Une nouvelle clé est un événement de réenrôlement délibéré, pas un effet secondaire d'une réimage. Ordre du travail : générer localement, autoriser contre l'inventaire, écrire les deux côtés, valider l'état, puis tester une requête de gestion à travers le tunnel.

Articles similaires