duplicate-cn gibt zwei Geräten eine Identität, nicht zwei

Kopieren Sie das Profil auf das Tablet, verbinden Sie sich, und der Laptop fällt heraus. Fügen Sie duplicate-cn hinzu, bleiben beide verbunden, und das Problem scheint gelöst — bis sich die zwei Geräte um dieselbe Tunneladresse streiten oder ein verlorenes Tablet das ganze Konto offline nimmt. Die Option ändert eine Sache und nur eine: ob der Server eine zweite Sitzung unter einem Namen zulässt, den er bereits gesehen hat. Alles, was man sich von ihr erwartet — von Geräteunabhängigkeit über Adressierung pro Gerät bis zu selektivem Widerruf — läuft weiterhin über die Identität, und die Identität ist hier das Zertifikat.

Der Mythos: eine zweite Sitzung ist eine zweite Identität

Die Intuition sagt, zwei Verbindungen müssten zwei Clients sein, und zwei Clients sollten zwei Geräte mit eigenen Rechten sein. Der Server modelliert das nicht so. Er sieht einen gemeinsamen Namen und akzeptiert bei aktiviertem duplicate-cn mehr als eine lebende Sitzung mit diesem Namen, wobei jede im Daemon ihren eigenen Sitzungszustand erhält.

Nichts an dieser Annahme berührt die Zertifikatsprüfung. Dasselbe Zertifikat bleibt das Credential, derselbe Schlüssel bleibt der private Schlüssel, und jede auf den Zertifikatsinhaber abgestellte Richtlinie ergibt weiterhin zweimal denselben Wert. Eine zweite Sitzung ist ein zweiter Socket, keine zweite Identität.

Dieser Unterschied ist unsichtbar, solange alles funktioniert. Er wird sehr sichtbar in dem Moment, in dem Sie die beiden Geräte auseinanderhalten müssen — und das ist meist der Tag, an dem eines davon verloren geht.

Was sich wirklich ändert, wenn zwei Sitzungen einen Namen teilen

Ohne die Option verdrängt eine neue Verbindung unter einem gemeinsamen Namen, der bereits verbunden ist, die frühere Sitzung. Deshalb fällt der Laptop heraus, wenn sich das Tablet verbindet, und das ist eine bewusste Absicherung gegen Mehrdeutigkeit, kein Fehler. Mit der Option bleiben beide Sitzungen lebendig, und der Server verfolgt sie getrennt nach Sitzung, nicht nach Gerät.

Jede Sitzung erhält weiterhin ihre eigene äußere Verbindung und ihre eigenen ausgehandelten Schlüssel, sodass gleichzeitiger Durchsatz wirklich gleichzeitig ist. Geteilt wird alles, was aus dem Credential abgeleitet wird: Richtlinienabfragen, klientspezifische Konfiguration, Logidentität und Widerruf. Sitzungszustand gehört zur Verbindung und stirbt mit ihr, während die Fakten auf Credential-Ebene für beide bestehen bleiben. Deshalb kann die Statusausgabe denselben Namen zweimal auflisten, während die Zähler getrennt bleiben.

Prüfen Sie, was Ihr Build tatsächlich tut, bevor Sie darauf aufbauen, denn die Wirkung der Option wird durch die Option selbst bestimmt und nicht durch Hörensagen:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

Die statische Adresse, die Sie vergeben zu haben glaubten

Die Konfiguration pro Client wird über den Namen nachgeschlagen, und darin liegt die Falle. Eine client-config-dir-Datei, die nach dem gemeinsamen Namen benannt ist gilt für jedes Gerät, das diesen Namen verwendet, sodass ein ifconfig-push darin beiden Geräten dieselbe Tunneladresse gibt. Die zweite Sitzung kommt entweder nicht zustande oder kollidiert so, dass es wie ein Routingfehler aussieht.

Ein dynamischer Pool verhält sich zufällig besser, weil jeder Sitzung unabhängig eine Adresse aus dem Pool zugeteilt wird. Das gibt Ihnen noch keine stabile Adresse pro Gerät, und es gibt Ihnen erst recht keine an diese Adresse gebundene Richtlinie pro Gerät.

Nutzt das Deployment username-as-common-name, wird der Nachschlageschlüssel der authentifizierte Benutzername statt des Zertifikatsinhabers, und dieselbe Kollision folgt für jeden, der sich zweimal anmeldet. Der Name, der die Konfiguration steuert, muss pro Gerät eindeutig sein, damit Konfiguration pro Gerät überhaupt etwas bedeutet.

Was eine geteilte Identität beim Entfernen nicht kann

Der Widerruf wirkt auf das Zertifikat, nicht auf den Anzeigenamen und nicht auf die Sitzung. Widerrufen Sie dieses Zertifikat, verlieren alle Geräte mit einer Kopie sofort den Zugang, einschließlich des Rechners im Büro, den niemand stören möchte. Behalten Sie es, arbeitet das verlorene Gerät weiter, weil nichts im Protokoll es von der freigegebenen Kopie unterscheidet.

Die Protokolle erben dieselbe Mehrdeutigkeit. Die Statusausgabe zeigt einen gemeinsamen Namen und eine echte Adresse, und beides kann zu jedem der beiden Geräte gehören. Eine Vorfallanalyse, die wissen muss, welche Maschine was getan hat, kann die Frage aus den eigenen Aufzeichnungen des VPN nicht beantworten, so viele Details die Logstufe auch liefert.

Dagegen gibt es keinen kryptografischen Ausweg. Zwei Geräte, die dasselbe Zertifikat vorlegen, sind für den Server derselbe Teilnehmer zweimal, und jedes Verfahren, das etwas anderes behauptet, ist eine Namenskonvention und keine Kontrolle.

Wann Teilen richtig ist und wie man es begrenzt

Teilen hat legitime Anwendungen: ein Laborkonto, das mehrere Testmaschinen nutzen, oder ein Haushalt, in dem die Geräte gemeinsam verwaltet werden und die Widerrufsgranularität keine Rolle spielt. Aktivieren Sie die Option in diesen Fällen bewusst, halten Sie das geteilte Credential aus der Richtlinie pro Gerät heraus und geben Sie dem Pool Raum, damit Sitzungen nicht auf einer Adresse kollidieren.

Für alles, was getrennte Adressen, getrennte Protokolle oder eine getrennte Entfernung braucht, stellen Sie getrennte Zertifikate über den normalen Registrierungsweg aus. Das gibt jedem nachgelagerten System ein eigenes Objekt, an dem es sich festmachen kann, und die Option verliert an Bedeutung, weil die Namen bereits eindeutig sind.

Welchen Weg Sie auch wählen, testen Sie das Verwaltungsmodell und nicht die Anmeldung. Verbinden Sie beide Geräte, bestätigen Sie, dass sie unterschiedliche Adressen haben, simulieren Sie dann einen Verlust und prüfen Sie, ob Sie genau eines davon entfernen können. Das Handbuch openvpn(8) definiert den Geltungsbereich der Option; Ihr Entfernungsverfahren definiert, ob Teilen tatsächlich akzeptabel ist.