Erststart: Registrierung einer Flotte von WireGuard-Geräten

Ein Image, ein Schlüssel pro Platine und ein Autorisierungsschritt, der der Behauptung des Geräts über sich selbst nicht vertraut. Vier Stufen vom Start bis zum freigegebenen Peer.

Die Platine bootet vom gemeinsamen Image, bezieht eine DHCP-Lease, und ein Bereitstellungsskript läuft, bevor irgendjemand das Gerät berührt hat. Irgendwo in diesem Skript muss es eine WireGuard-Identität beschaffen, die zu dieser Platine gehört und zu keiner anderen, diese Identität autorisieren lassen und ein Profil schreiben, das das Gateway akzeptiert. Das Image darf die Client-Software, eine geprüfte Vorlage und den öffentlichen Schlüssel des Gateways enthalten. Was es niemals enthalten darf, ist ein einziger privater Schlüssel, den die ganze Flotte teilt, denn das macht aus einer einzigen gestohlenen Platine einen Vorfall für die gesamte Flotte. Die folgende Reihenfolge hält die Identität lokal und die Autorisierung explizit.

Was das Image enthält – und was nicht

Liefere das Paket, die Vorlage mit Platzhaltern, den öffentlichen Schlüssel des Gateways und den Registrierungsclient aus. Die Vorlage ist eine Form, kein Geheimnis: Sie sollte für den Bereitstellungsbenutzer lesbar sein und kein Schlüsselmaterial enthalten.

Der private Schlüssel wird beim ersten Start auf dem Gerät erzeugt und verlässt es nie. Nur die öffentliche Hälfte reist, in einer Registrierungsanfrage, die durch etwas anderes autorisiert wird als durch die eigene Behauptung des Geräts, wer es ist. Diese Unterscheidung ist es, die verhindert, dass eine gestohlene Platine zu einem Problem für die ganze Flotte wird. Und genau das machen die meisten Erststart-Skripte falsch.

Schritt 1: den Schlüssel lokal erzeugen

Führe die Erzeugung in einem geschützten Verzeichnis aus, nachdem die zugrunde liegende Netzwerkverbindung freigegeben ist und funktioniert. Die Subshell hält die umask-Änderung auf diesen Vorgang beschränkt, und set -C weigert sich, eine vorhandene Datei zu überschreiben:

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

Der WireGuard-Schnellstart dokumentiert die Beziehung der Schlüsselerzeugung, auf die sich diese beiden Befehle stützen. Wenn die Erzeugung unterbrochen wird, lasse das Gerät unregistriert und überlasse es dem Workflow, die Dateien in Einklang zu bringen. Lösche keine bestehende Identität, nur damit das Skript sauber von oben durchläuft.

Bewahre den ausstehenden Schlüssel über Wiederholungsversuche hinweg auf. Eine Identität nach jedem vorübergehenden Netzwerkfehler neu zu erzeugen, ist der Weg, auf dem eine Flotte Peers zurücklässt, die niemand einem Gerät zuordnen kann.

Schritt 2: einen Gerätedatensatz autorisieren

Angenommen, die Inventarisierung nennt diese Platine device-042 und weist ihr 10.90.0.42/32 zu. Der Registrierungsdienst muss prüfen, dass dieser Anforderer zu diesem Datensatz berechtigt ist. Eine in ein Formular getippte Seriennummer ist kein Beweis, denn Seriennummern stehen auf der Außenseite der Schachtel.

Ein geräteeigenes Bootstrap-Anmeldeinformationspaar, eine Freigabe durch einen Operator oder eine hardwaregestützte Attestierung können den Anspruch belegen. Schütze die Integrität der Anfrage und die Authentizität der Antwort, und ersetze nicht ein gemeinsames VPN-Geheimnis durch ein gemeinsames Werks-Anmeldeinformationspaar.

Der registrierte Datensatz verbindet das Gerät, seinen öffentlichen Schlüssel, seine zugewiesene Adresse und seine erlaubte Managementrolle. WireGuard selbst definiert keine Registrierungs-API, also ist dieser Dienst etwas, das du bewusst baust und betreibst.

Schritt 3: zwei zueinander passende Konfigurationen schreiben

Das Gerät braucht ein Profil, das die Management-Präfixe in den Tunnel routet, und das Gateway braucht einen Peer-Eintrag, der nur die eigene Quelladresse dieses Geräts erlaubt. Mit einem Gateway auf 10.90.0.1 und einem Managementnetz 10.60.0.0/16 sieht die Geräteseite so aus:

[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

Die eingeklammerten Werte sind Platzhalter, keine Schlüssel. Der Keepalive ist wichtig, wenn die Platine hinter NAT sitzt und erreichbar bleiben muss; er ist nicht überall nötig, und ihn aus Gewohnheit hinzuzufügen hält ein Funkmodul ohne Grund wach.

Auf dem Gateway ist der Peer-Eintrag bewusst eng:

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

Kopiere die Zielliste des Geräts nicht auf den Gateway-Peer. Auf dem Gerät sagt diese Liste, was in den Tunnel geroutet wird; auf dem Gateway sagt sie, welche Quelladressen dieser Peer nutzen darf, und das sind unterschiedliche Aussagen.

Weiterleitung, Firewall-Regeln und der Rückweg zum Managementnetz müssen den freigegebenen Zugriff weiterhin erlauben. Ein registrierter Peer ist keine Erlaubnis für jede Anwendung dahinter.

Schritt 4: die Registrierung als Lebenszyklus-Zustand festschreiben

Wende den Gateway-Datensatz und das Geräteprofil über die Stelle an, der die jeweilige Konfiguration gehört, und markiere die Registrierung erst dann als abgeschlossen, wenn die beabsichtigte Identität und Adresse akzeptiert sind. Wiederholungsversuche sollten denselben Datensatz abstimmen, statt einen zweiten Peer oder eine zweite Adresse zuzuteilen.

Halte einen Wiederherstellungspfad für unterbrochene Bereitstellung bereit, einschließlich des Falls, dass das Gateway den Schlüssel akzeptiert hat und das Gerät sein Profil nie geschrieben hat.

Wenn eine Platine ersetzt oder ausgemustert wird, entferne ihren öffentlichen Schlüssel und ihre Autorisierung zusammen. Ein neuer Schlüssel ist ein bewusstes Neu-Registrierungsereignis, kein Nebeneffekt eines Reimages. Reihenfolge der Arbeit: lokal erzeugen, gegen das Inventar autorisieren, beide Seiten schreiben, den Zustand festschreiben und dann eine Management-Anfrage durch den Tunnel testen.

Ähnliche Artikel