Warum der erneute Import eines Client-VPN-Zertifikats einen neuen Endpunkt erfordert

Eine Client-VPN-Verbindung bricht ab, das Zertifikat in ACM wird ersetzt, und nichts ändert sich. Das Zertifikatsobjekt war nie das, was der Endpunkt verwendete. Ein Endpunkt speichert beim Erstellen eine Verknüpfung zu einem Zertifikat, zusammen mit der Client-CA, gegen die er validiert, dem Authentifizierungstyp, den Subnetzen und den Autorisierungsregeln, und keine dieser Verknüpfungen hat einen Änderungsaufruf, der ein Ersatzzertifikat annimmt. Die Bytes hinter einem ARN zu ersetzen ist eine Änderung am Zertifikat, nicht am Endpunkt, der es festgehalten hat.

Der Endpunkt speichert Referenzen, keine Zertifikate

Der Mechanismus verdient eine präzise Formulierung, weil er den gesamten Fehler erklärt. create-client-vpn-endpoint nimmt einen Serverzertifikat-ARN und einen ARN der Client-Root-Zertifikatskette, und der resultierende Endpunkt behält diese Referenzen samt den Authentifizierungsoptionen als feste Eigenschaften. Die API-Oberfläche bietet keine Operation, die das Serverzertifikat an einem bestehenden Endpunkt austauscht.

Sie können die Bindung ohne Raten bestätigen. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 gibt den Zertifikat-ARN, den ARN der Client-Root-Kette, den Authentifizierungstyp, das Client-CIDR und die zugehörigen Subnetze aus, also die vollständige Menge von Eigenschaften, die Sie nachbilden müssten. Führen Sie ihn vor und nach einem erneuten Import aus, und die Ausgabe bewegt sich nicht. Das ist der Beweis, dass der erneute Import nie helfen konnte.

Warum ein erneuter Import den Endpunkt nicht erreichen kann

Ein erneuter Import schreibt einen neuen Zertifikatskörper unter einen bestehenden ARN. Das ist ein legitimer Vorgang, wenn ein Zertifikat kurz vor dem Ablauf steht, und ACM akzeptiert ihn, solange der private Schlüssel passt und die Kette validiert. Was er nicht tut, ist die Validierung aus der Erstellungszeit des Endpunkts erneut auszuführen, sodass die Verknüpfung und das Material dahinter so bleiben, wie sie beim Bau des Endpunkts waren.

Deshalb liest sich das Symptom auch wie ein Netzwerkfehler. Der TLS-Handshake schlägt fehl oder wird zurückgesetzt, bevor die Autorisierung überhaupt bewertet wird, sodass Sicherheitsgruppen, Routen und Autorisierungsregeln alle unschuldig aussehen, und das sind sie auch.

Die Kette ist Teil des Client-Zertifikats

Die zweite Hälfte des Fehlers liegt im Client-Zertifikat, und sie ist leichter abzutun. Ein Client-Zertifikat muss mit der Kette importiert werden, die es ausgestellt hat, obwohl das Importformular dieses Feld als optional darstellt. Ohne die Kette kann der Endpunkt keinen Pfad vom Client-Zertifikat zur Client-Root-CA aufbauen, mit der er konfiguriert wurde, und die Verbindung endet in einem weichen Reset, der wie eine Firewall klingt, die Pakete verwirft. openssl verify -CAfile root-ca.pem client.crt beantwortet diese Frage lokal in einer Sekunde, und es sollte der erste Befehl sein, den Sie ausführen.

Der erneute Import mit der Kette ist eine echte Korrektur für diese Hälfte, und sie ist für sich genommen immer noch nicht genug. Sobald sich das ACM-Objekt geändert hat, ist der Endpunkt mit der alten Verknüpfung das falsche Ding, gegen das man weiter testet. Beide Schritte gehören zur selben Reparatur, weshalb die zweiteilige Korrektur kein Widerspruch ist.

Einen Endpunkt neu zu erstellen ist eine Migration

Einen Ersatzendpunkt zu erstellen ist eine Migration, kein erneuter Versuch, und ihn als erneuten Versuch zu behandeln, ist der Weg, auf dem Teams mit zwei halb konfigurierten Endpunkten enden. Der neue Endpunkt bekommt eine neue ID und, sofern nicht geplant, einen neuen DNS-Namen für jeden Benutzer. Halten Sie das Client-Profil auf einen Namen statt auf eine Adresse zeigen, damit der Wechsel eine Datensatzänderung wird statt einer Neuverteilung.

Die Reihenfolge, die das sicher hält, ist kurz: Erstellen Sie den neuen Endpunkt mit demselben CIDR, denselben Subnetzen und denselben Autorisierungsregeln, exportieren Sie ein frisches Profil mit aws ec2 export-client-vpn-client-configuration und verifizieren Sie mit einem Benutzer. Erst danach wird der alte Endpunkt abgebaut.

Das Außerbetriebnehmen des alten Endpunkts hat seine eigene Reihenfolge. Widerrufen Sie die Client-Zertifikate, die Sie außer Betrieb nehmen wollten, bevor Sie ihn löschen, denn ein neuer Endpunkt, der der alten CA noch vertraut, akzeptiert weiterhin Zertifikate, von denen Sie glaubten, sie seien verschwunden. Löschen Sie dann den alten Endpunkt und entfernen Sie seine Autorisierungsregeln, damit ein veraltetes Profil sich nicht erneut mit einem Zielnetz verbinden kann, das Sie für geschlossen hielten. Schreiben Sie die ID des alten Endpunkts und die Verknüpfungsbezeichner in den Änderungsdatensatz, denn eine Migration, die mit dem Gedächtnis verglichen wird, ist der Weg, auf dem ein funktionierender Endpunkt zweimal neu gebaut wird.

Ordnen Sie die Diagnose

Trennen Sie drei Fehler, bevor Sie irgendeine Konfiguration ändern. Der Client kann TLS nicht abschließen, der Client schließt TLS ab und ist nicht autorisiert, oder der Client verbindet sich und erreicht kein Ziel. Die Zertifikatsverknüpfung gehört zum ersten, eine Autorisierungsregel, die die Client-Adresse nicht abdeckt, zum zweiten, und eine Route oder Sicherheitsgruppe zum dritten, wo das Neuerstellen eines Endpunkts fast immer der falsche Schritt ist.

Ein Endpunkt, der monatelang funktionierte und dann ohne Zertifikats- oder Richtlinienänderung aufhörte, ist ein eigener Fall. Ihn mit identischen Einstellungen neu zu bauen kann den Dienst wiederherstellen, aber das ist ein Grund, die Konfiguration reproduzierbar zu halten, kein Grund, bei jedem Vorfall neu zu bauen.

Halten Sie vier Dinge unter Versionskontrolle, damit der nächste Neuaufbau ein Diff ist und keine Improvisation: die Endpunktparameter, die Zertifikats- und Ketten-ARNs, die Autorisierungsregeln und das Client-CIDR. Die Dokumentation zur Client-VPN-Authentifizierung listet auf, welches Zertifikat welche Rolle spielt, was sich lohnt zu prüfen, bevor Sie überhaupt annehmen, ein Zertifikat sei das Problem. Wenn ein erneuter Import nichts ändert und der Endpunkt weiter zurücksetzt, ist die Verknüpfung der Verdächtige, und die Antwort ist ein neuer Endpunkt, gebaut aus den aufgezeichneten Parametern. Wenn der Endpunkt das neue Objekt doch übernimmt, war die Verknüpfung bereits korrekt, und der Fehler sitzt in der Client-Kette oder der Autorisierungsschicht.