Ein verlorenes VPN-Gerät widerrufen: Schlüssel, Zertifikat oder Konto

Ihr Laptop ist weg, und das VPN führt ihn weiterhin als Client. Die dringende Frage ist nicht, wie man das Profil auf einer Maschine löscht, die man nicht mehr hat, sondern welche Identität der Server noch akzeptiert. WireGuard prüft einen öffentlichen Schlüssel, eine PKI-basierte OpenVPN Konfiguration prüft ein Client-Zertifikat, und ein VPN mit SSO prüft ein Konto und dessen Sitzungstoken. Diese drei werden an verschiedenen Orten und mit unterschiedlicher Geschwindigkeit widerrufen, und eines zu reparieren, während man die anderen ignoriert, ist der Grund, warum ein verlorenes Gerät verbunden bleibt.

Drei Identitäten und was jede von ihnen steuert

Jeder Mechanismus beantwortet eine andere Frage. Ein Peer-Schlüssel beantwortet, ob dies die Maschine ist, die Sie registriert haben. Ein Zertifikat beantwortet, ob es von Ihrer CA signiert und nicht widerrufen wurde. Ein Konto beantwortet, ob sich diese Person kürzlich genug authentifiziert hat. Ein Deployment, das zwei davon schichtet, etwa Zertifikat plus Verzeichnisanmeldung, schließt die Tür erst, wenn jeder Ebene, die dem Gerät etwas ausgestellt hat, gesagt wurde, es nicht mehr zu akzeptieren.

Die praktische Falle besteht darin, dass die fehlende Maschine die private Hälfte jedes Nachweises hält, sodass nichts, was Sie lokal tun, den Server erreicht.

WireGuard: Entfernen Sie den Peer, denn es gibt keine Sperrliste

WireGuard führt keine Sperrliste. Die Schnittstelle akzeptiert genau die öffentlichen Schlüssel, die als Peers konfiguriert sind, also ist Widerruf Löschen: Führen Sie wg set wg0 peer <public-key> remove aus, die in wg(8) dokumentierte Form, und löschen Sie dann den passenden [Peer]-Block aus wg0.conf. Tun Sie beides. Ein Entfernen nur zur Laufzeit überlebt bis zum nächsten Neustart oder Konfigurations-Reload, bei dem die Datei den Schlüssel wieder einsetzt.

Bestehende Sitzungen brauchen keinen Timer, um zu sterben. Das Entfernen des Peers verwirft dessen Handshake und Schlüsselmaterial, sodass der Verkehr stoppt, sobald wieder ein gültiges Schlüsselpaar verlangt wird. Prüfen Sie wg show wg0 latest-handshakes auf dem Server: Der Eintrag für den verlorenen Schlüssel sollte verschwinden und verschwunden bleiben, während die anderen Peers weiterhin aktuelle Epochen melden.

Ein Vorbehalt ist wichtiger, als er aussieht. Wenn das verlorene Gerät einen Schlüssel mit anderen Geräten geteilt hat, weil jemand eine Konfigurationsdatei kopiert hat, trennt das Entfernen dieses Schlüssels alle von ihnen; das ist trotzdem der richtige Schritt, und Sie stellen danach Schlüssel pro Gerät neu aus, statt den geteilten wiederherzustellen.

Zertifikate: Eine CRL zählt nur, wenn der Daemon sie liest

Zertifikatsbasierter Zugriff fügt einen Schritt hinzu, den Leute überspringen. easyrsa revoke laptop-01 markiert das Zertifikat in der CA-Datenbank als widerrufen, aber das VPN lernt daraus nichts. Dann führen Sie easyrsa gen-crl aus, um crl.pem zu schreiben, kopieren es an den in der Option crl-verify des Servers genannten Pfad und bestätigen, dass der laufende Daemon die neue Datei verwendet. Ein Widerruf ohne Neuerzeugung und Verteilung der CRL ist wirkungslos.

Das Timing ist die zweite Hälfte. Eine CRL wird konsultiert, wenn ein Client sich verbindet oder neu verhandelt, sodass ein bestehender Tunnel bis dahin weiterleiten kann. Muss das Gerät sofort abgeschnitten werden, beenden Sie diese Sitzung ausdrücklich über die OpenVPN-Managementschnittstelle, statt auf den nächsten Handshake zu warten. Das Neuladen oder Neustarten des Dienstes, je nachdem wie das Deployment die CRL lädt, gehört zur Änderung und ist kein optionaler Zusatz.

Die Prüfung lohnt sich von einer anderen Maschine aus: Legen Sie das widerrufene Zertifikat vor und erwarten Sie einen Handshake-Fehler, typischerweise VERIFY ERROR: depth=0, error=certificate revoked. Wenn die Verbindung trotzdem gelingt, liest der Client eine andere CRL als die, die Sie aktualisiert haben.

Konten und Sitzungen: Deaktivieren ist nicht dasselbe wie Hinauswerfen

Verzeichnis- oder SSO-Anmeldungen werden zum Authentifizierungszeitpunkt geprüft. Das Deaktivieren des Kontos blockiert die nächste Anmeldung, aber das Refresh-Token und der bestehende Tunnel können weiterarbeiten, bis sie ablaufen. Widerrufen Sie die Sitzungen und Tokens dieses Benutzers, oder erhöhen Sie eine Sitzungsversion, wenn der Identitätsanbieter das unterstützt. Entfernen Sie das verlorene Gerät auch aus der MFA-Registrierung, denn ein registrierter Authenticator ist für sich genommen ein Zugangsweg.

RADIUS-gestützte VPNs können eine Trennungsnachricht oder eine Autorisierungsänderung senden, um eine aktive Sitzung zu beenden, aber nicht jeder Netzwerkzugangsserver befolgt das. Im Zweifel beenden Sie die Sitzung des Benutzers serverseitig und bestätigen in den Protokollen, dass die alte Sitzung geschlossen wurde.

Reihenfolge der Schritte für die nächste Stunde

Beginnen Sie beim Inventar, nicht beim Client: Listen Sie jede Identität auf, die mit dem Gerät verbunden ist, sei es Peer-Schlüssel, Zertifikatsseriennummer oder Konto. Widerrufen Sie in jedem ausstellenden System in der Reihenfolge, in der die Verbindung aufgebaut wird, also zuerst das Konto, dann das Zertifikat, dann den Peer. Beweisen Sie die Ablehnung anschließend von einer Maschine aus, die Sie kontrollieren.

Zwei Folgeschritte vergisst man leicht. Erstens rotieren Sie alles andere, was das Gerät hielt, insbesondere SSH-Schlüssel, Cloud-Konsolen-Anmeldedaten und einen gemeinsam genutzten vorab geteilten WireGuard-Schlüssel. Zweitens prüfen Sie, ob Konfigurationsmanagement, Snapshots oder Gold-Images den entfernten Client beim nächsten Rebuild wieder einführen können.

Die dauerhafte Lösung ist eine Identität pro Gerät. Wenn jeder Laptop seinen eigenen Peer-Schlüssel oder sein eigenes Zertifikat trägt, kostet ein Verlust einen Widerrufsbefehl und eine Neuausstellung statt eines Rebuilds der gesamten Flotte.