Zwei Geräte, ein OpenVPN-Zertifikat: die Wiederverbindungsschleife

Ein Tunnel, der hochkommt und dann alle halbe Minute neu startet, ist meistens kein Cipher- oder MTU-Problem. Es ist eine Identität, die zweimal benutzt wird. Der Server sieht einen vertrauten Common Name, nimmt die neue Sitzung als die neueste, und das ältere Gerät stellt fest, dass es ersetzt wurde. Aus Client-Sicht sieht das wie ein Inaktivitäts-Timeout und ein Neustart aus, weshalb die Untersuchung so oft an der falschen Stelle beginnt.

Beim Neustartintervall anfangen

Das Intervall ist ein Hinweis vor allem anderen. Ein gleichmäßiger Takt, der zum ping-restart-Fenster passt, deutet auf eine ersetzte Sitzung hin und nicht auf einen fehlerhaften Pfad, denn Pfadfehler sind selten so regelmäßig. Notieren Sie den genauen Abstand zwischen den Neustarts und die Begründungszeile im Client-Log. Ein Timeout mit anschließendem Neustart erzählt eine andere Geschichte als ein fehlgeschlagener Handshake.

Prüfen Sie, wann die Neustarts im Verhältnis zu einem zweiten Gerät begannen. Ein neues Notebook, ein Telefon oder ein auf eine Ersatzmaschine kopiertes Profil sind die üblichen Auslöser, und der Zeitpunkt passt meist zu dem Tag, an dem jemand es eingerichtet hat.

Schreiben Sie Intervall und Grund auf. Beides ist ein Beweis, und beides ist billig zu erheben.

Lesen Sie, was der Server zum zweiten Login gesagt hat

Auf einem Server, den Sie kontrollieren, nennt das Log den Common Name und zeigt eine zweite eintreffende Verbindung. Ohne duplicate-cn ersetzt dieses Eintreffen die bestehende Sitzung für denselben Namen, und die Meldung sagt das meist deutlich. Mit duplicate-cn existieren beide Sitzungen nebeneinander, und das Symptom ändert sich: Die Clients bleiben oben, teilen sich aber einen Satz von Einstellungen pro Client und eine Widerrufsentscheidung. Lesen Sie beide Einträge zusammen, denn die Ersetzung ist nur in der Reihenfolge sichtbar.

Bei einem gehosteten Dienst haben Sie vielleicht gar kein Server-Log. Der Hinweis ist dann der Zeitpunkt: ein stabiler Tunnel, der bei jeder Verbindung einer anderen Maschine abfällt, und im Client-Log nichts außer dem Timeout.

Vergleichen Sie die Zertifikat- und Schlüsselblöcke in beiden Profilen, nicht nur den entfernten Hostnamen. Kopierte Profile unterscheiden sich meist nur im Dateinamen.

Trennen Sie die Identität auf der Serverseite

Stellen Sie ein Zertifikat pro Gerät über die CA aus, die für diesen Server signiert. Mit Easy-RSA bedeutet das einen eigenen Client-Namen für jedes Gerät, und das Profil wird dann aus diesem Zertifikat und seinem Schlüssel gebaut. Der Common Name wird zur Geräteidentität, und genau das fehlte dem Server. Benennen Sie sie nach dem Gerät statt nach der Person, damit ein Austausch einen neuen Namen erzeugt.

Der gemeinsame Steuerkanal-Schlüssel ist etwas anderes. tls-crypt oder tls-auth schützt den Steuerkanal für jeden Client und ist zum Teilen gedacht. Er ist keine Client-Identität, und ihn zu ersetzen behebt kein doppeltes Zertifikat.

Halten Sie Zertifikat, Schlüssel und jede Client-Konfigurationsdatei unter demselben Common Name, sonst bricht die Zuordnung bei der nächsten Verbindung. Eine Abweichung dort erzeugt einen Client, der sich authentifiziert und dann nichts empfängt.

Halten Sie Adressen und Einstellungen nach der Trennung im Gleichklang

Feste Adressen führen zu einer zweiten Art der Kollision. Wenn der Server sie über ifconfig-pool-persist oder eine Datei pro Client vergibt, zeigen diese Einträge noch auf den alten Namen. Zwei Geräte können dieselbe Tunneladresse bekommen, selbst nachdem die Zertifikate getrennt sind, und dieser Fehler sieht anders aus als die ursprüngliche Schleife.

Aktualisieren Sie die Zuordnung gleichzeitig mit dem Zertifikat, verbinden Sie dann beide Geräte neu und vergleichen Sie ihre zugewiesenen Adressen. Eine doppelte Adresse zeigt sich als aussetzender Verlust statt als saubere Wiederverbindung.

Schieben Sie Einstellungen, die sich pro Gerät unterscheiden sollen, über die eigene Datei dieses Geräts, nicht über eine gemeinsame Vorlage. Eine gemeinsame Vorlage macht auch das nächste Duplikat schwerer zu erkennen.

Mustern Sie die alte Identität ordentlich aus

Widerrufen Sie das Zertifikat, wenn Hardware ausgemustert wird oder fehlt, statt das Profil von der alten Maschine zu löschen. Der Widerruf erzeugt eine neue CRL, und der Server braucht diese Datei dort, wohin crl-verify zeigt. Mit dieser Direktive an Ort und Stelle lässt eine fehlende oder unlesbare CRL den Server jeden Client ablehnen, testen Sie also nach jeder Aktualisierung ein bekanntes Konto.

Führen Sie ein Verzeichnis, das jedes Zertifikat mit einer Person oder einem Gerät verbindet, samt Ausstellungs- und Widerrufsdatum. Dieses Verzeichnis beantwortet, wer noch Zugang hat, ohne Dateinamen zu lesen, und es hält das nächste kopierte Profil davon ab, die Schleife neu zu starten.