Der Satz „wir nutzen OpenVPN“ kommt in Tickets, Beschaffungsformularen und Onboarding-Dokumenten vor, und er beantwortet in jedem davon eine andere Frage. Mal bezeichnet er ein Übertragungsprotokoll, mal die Software auf einem Gateway und mal die App, die ein neuer Mitarbeiter installieren soll. Diese drei Tatsachen führen zu unterschiedlichen nächsten Schritten, und zu fragen, welche gemeint ist, dauert weniger als zu raten. Der Rest der Untersuchung folgt aus dieser Antwort.

Trennen Sie zuerst die Rolle von der Marke, denn die Marke deckt alle drei ab.

Der Name deckt drei Rollen ab, die unterschiedlich ausfallen

Als Protokoll beschreibt OpenVPN, wie kompatible Gegenstellen einen Tunnel aufbauen und schützen, was ihn durchquert. Als Software ist es eine Implementierung, die dieses Protokoll in der Client- oder Serverrolle spricht. Als Client ist es eine Anwendung, die jemand installiert, mit eigener Version, eigenem Profilformat und eigenen Eigenheiten der Plattform. Ein Ausfall in einer Rolle bedeutet nicht einen Ausfall in einer anderen, deshalb braucht „OpenVPN ist down“ ein Subjekt.

Fragen Sie, was die meldende Person sehen kann: eine Profildatei, ein installiertes Programm oder ein Gateway, das sie administriert. Dieses eine Detail sagt Ihnen, ob der nächste Schritt ein Client-Log, eine Paketfrage oder eine Listener-Prüfung auf der Serverseite ist.

OpenVPN 2 und OpenVPN 3 sind kein Upgrade-Paar

OpenVPN 2.x läuft sowohl in der Server- als auch in der Clientrolle, und es ist das, was die meisten Gateway-Installationen noch verwenden. OpenVPN 3 ist eine separate, clientorientierte Implementierung mit eigener Konfiguration und eigenem Sitzungsmodell, nicht die nächste Version, die Sie über einen 2.x-Server installieren. OpenVPN Connect ist eine Client-Anwendung, die auf der OpenVPN 3 Engine aufbaut. Die Installation irgendeiner davon schafft keinen Internet-Ausgangsdienst; der Ausgang ist das, was der Betreiber konfiguriert hat.

Kompatibilität auf Protokollebene erstreckt sich nicht auf Profil-Direktiven, daher kann ein Profil, das sauber importiert wird, an einer Direktive scheitern, die der Client nicht implementiert.

Der Transport ist nicht die Anwendung darin

Die äußere Verbindung nutzt einen Transport wie UDP oder TCP, um einen konfigurierten Listener zu erreichen, und alles, was der Tunnel trägt, fährt darin. Eine Webanfrage über das VPN braucht keinen eigenen OpenVPN-Listener und wird auf der Leitung nicht zu einem OpenVPN-Paket. Im TLS-Modus handelt der Kontrollkanal Schlüsselmaterial aus, während der Datenkanal die Nutzlast schützt, und diese Trennung sollte man beim Lesen von Logs richtig halten.

Verwechselt man die Schichten, entstehen Anfragen wie das Öffnen eines Ports für eine Website, die bereits durch den Tunnel funktioniert. Der Port gehört zur äußeren Verbindung, nicht zur Anwendung.

Was ein Profil versprechen kann und was nicht

Ein Profil sagt einem Client, wie er einen Dienst erreicht: Endpunkt, Transport, Identitätsmaterial und oft einige Routing- und DNS-Einstellungen. Es sagt nichts darüber, wer diesen Dienst betreibt oder ob das Konto berechtigt ist. Routen, Resolver-Einstellungen, Weiterleitungsregeln und Zugriffsrichtlinie entscheiden, was die Sitzung tatsächlich erreicht. Ein Profil, das sich erfolgreich importieren lässt, ist der Anfang einer funktionierenden Verbindung, kein Beweis für sie.

Wenn jemand fragt, ob eine Ressource über das VPN erreichbar ist, hängt die Antwort von der Richtlinie des Servers ab und nicht von der Konfigurationsdatei des Clients.

Fragen Sie nach dem, was bereitgestellt werden kann

Machen Sie aus dem weiten Namen drei Konkretes: den Client und seine Version, das autorisierte Profil für diesen Client und die Ressource, die die Person erreichen muss. Damit ist Bereitstellung eine konkrete Aufgabe. Ohne sie ist jede Antwort ein Raten darauf, welches OpenVPN die Frage meinte.

Halten Sie die Antwort in der Anfrage selbst fest. Das nächste Ticket wird dieselbe Frage auf dieselbe mehrdeutige Weise stellen.

Ähnliche Artikel