26.03.2020, aktualisiert am 25.09.2024

70324

Merkzettel: VPN Installation mit OpenVPN

Inhaltsverzeichnis

Einleitung

VPN Designfragen

Einstellungen Router bzw. Firewall

IP Adressierung OpenVPN Server

Interne OpenVPN IP Adressierung

Port Forwarding oder auch Port Weiterleitung bzw. Freigabe im Router

Statische Route auf internes VPN IP Netz

OpenVPN Server und Client Konfiguration

Generieren der OpenVPN Zertifikate und Schlüssel

IP Forwarding (Routing) im OpenVPN Server aktivieren

Konfiguration OpenVPN Server

⚠️ Split Tunneling oder Gateway Redirect?

Konfiguration OpenVPN Client

VPN Verbindung checken

Weiterführende Links

Alternative VPN Routing Protokolle:

Einleitung

Durch die steigenden Anforderungen an VPNs, ist auch im hiesigen Forum die Zahl der technischen Fragen zum Thema VPN und insbesondere auch OpenVPN gestiegen. Mit dem Klassiker OpenVPN kann man schnell und unkompliziert einen VPN Zugang in einem existierenden, einfachen Netzwerk realisieren ohne das bestehende Netz umkonfigurieren zu müssen. So ist mit wenig Aufwand schnell und kostenschonend ein VPN Zugang für remote Mitarbeiter realisiert oder auch eine Standort VPN Kopplung möglich.
OpenVPN ist dabei nicht wählerisch was die Hardware und Betriebssystem angeht. Mit einem alten ausrangierten PC, einem preiswerten Raspberry Pi 4, einem NAS mit OpenVPN App oder was auch immer ist das schnell umgesetzt.
Ebenso haben eine Vielzahl von Routern und Firewalls sowie das alternative Router Betriebssystem OpenWRT und DD-WRT von sich aus OpenVPN schon an Bord und ersetzen hier den VPN Server.
Ob es Linux wie beim Raspberry Pi, Ubuntu, Windows, Mac OS oder der Router selber ist, spielt dabei keine Rolle. Ein weiterer Vorteil bei OpenVPN ist, das die Server und Client Konfiguration über alle Plattformen hinweg identisch ist. Ein Grund für die große Verbreitung von OpenVPN.
Zweifelsohne gibt es auch noch andere VPN Protokolle, wie das auch von der FritzBox benutzte, standartisierte und weit verbreitete IPsec. Desweiteren WireGuard. Alles zu behandeln würde aber den Rahmen dieses kurzen, rein auf OpenVPN bezogenen, "Merkzettels" sprengen und ist Thema weiterer VPN Tutorials hier im Forum. Die weiterführenden Links am Ende verweisen darauf.

VPN Designfragen

Dieses VPN Design ist wie alle Designs, bei denen der VPN Server im internen LAN betrieben wird, nicht ideal. Best Practise ist hier immer das VPN direkt auf der Netzwerk Peripherie wie Router oder Firewall zu betreiben. VPN Traffic muss auf diese Weise nicht durch Löcher in der Firewall ins interne, geschützte LAN und es erhöht massiv die Sicherheit wenn das VPN in der Peripherie terminiert ist.
Ein weiterer Nachteil ist das VPN Traffic über ein gemeinsames Interface zum und vom VPN Server muss, was Performance und Skalierbarkeit erheblich einschränkt. Kurzum... VPNs gehören bei guten Design immer auf Internet Router oder Firewall! Das sollte man bei guten VPN Designs immer beachten.

In kleineren Netzen oder Heimnetzen sind diese VPN fähigen Router oder Hardware Firewalls aber oft nicht vorhanden oder es fehlt entsprechendes KnowHow um so etwas umzusetzen. Oder was leider oft passiert... es ist Zeitdruck bei der Realisierung.
Das Tutorial versucht mit den folgenden Installations Tips diesen Spagat zwischen Sicherheit, Realisierung und Installation um so ggf. auftauchende Probleme schon im Vorwege zu klären.
Basis dieses "Merkzettels" ist deshalb ein einfaches lokales Netzwerk mit den klassischen Komponenten. Professionelle Firmen VPNs sollten aber nicht diesem Design folgen, sondern immer in der Peripherie terminieren.

Oder als klassische Site to Site Installation zur Kopplung mehrere IP Netze:

(Wobei hier auch einer oder beide Router solche mit OpenVPN an Bord sein können. Dann entfallen natürlich OVPN Server und Client im lokalen LAN !)

Internet Router Einstellungen werden hier stellvertretend für andere, einfache Router Hardware anhand einer einfachen FritzBox beschrieben. Einmal abgesehen davon das die FritzBox per se ein VPN Router ist und billige Consumer Router in Firmennetzen generell nichts zu suchen haben. Die recht anschaulichen Setups der AVM Router geben aber ein gutes Beispiel stellvertretend für ALLE verwendeten Router Modelle !
Das lokale LAN im Beispiel arbeitet mit der IP Netzwerk Adresse 192.168.188.0 /24 und das interne OpenVPN Netzwerk mit 172.17.77.0 /24.

Noch etwas zum NAT/Masquerading am Server:
Im eigenen, internen LAN ist eine IP Adress Translation (NAT) kontraproduktiv und führt dazu das kein transparentes Routing möglich ist. Einige Anleitungen im Internet gehen häufig von öffentlichen VPNs aus um Geo Location Grenzen (Streaming usw.) zu überwinden. So ein Design führt in einem Standort oder Client VPN wie hier oft zur Fehlfunktion.
Es gilt also: KEIN NAT/Masquerading am Tunnelinterface aktivieren (iptables oder nftables) !!
Ein NAT/Maquerading im Tunnel kann dennoch in einigen Designs sinnvoll sein. Z.B. ein Firmen VPN wo Clients immer nur zentral auf einen Server arbeiten. Hier ist bidirektionales Routing nicht gewollt und auch nicht erforderlich und aus Security Sicht kann das dann von Vorteil sein. Final also immer eine Frage der eigenen Security Policy!
Wichtige Tips zur VPN Adressierung findet man HIER !
Los gehts...!

Einstellungen Router bzw. Firewall

Das Tutorial geht von einer klassischen OpenVPN Installation aus mit dem Default Port UDP 1194. Hat man das geändert, muss dies in den Konfig Dateien entsprechend angepasst werden.
Wer aus Sicherheitsgründen nicht den Standard Port verwenden will, sollte aufgrund der weltweit fest genormten Port Zuweisungen durch die IANA immer auf die sog. freien Ephemeral Ports im Bereich 49152 bis 65535 ausweichen. Diese Ports werden in der Regel von Angreifern wenig bis gar nicht gescannt. UDP 51194 oder UDP 61194 z.B. wären dann eine sinnvolle Wahl.
Oft limitieren auch vorgeschaltete Firewalls den Port. Hier kann man dann auf UDP oder auch TCP 443 (HTTPS) wechseln. TCP Enkapsulierung gilt es aber, wenn immer möglich, generell zu vermeiden, da dies meist mit erheblichen Performance Verlusten im VPN durch den größeren Paket Overhead und das aufwändigere Session Handling einher geht. UDP ist bei OpenVPN also immer primär das Protokoll der Wahl !

IP Adressierung OpenVPN Server

Der OpenVPN Server kann generell auch dynamisch eine IP Adresse aus dem DHCP Bereich des Routers an seinem lokalen LAN Interface bekommen. Das hat aber einen Nachteil der sich gravierend auswirken kann.
Da eine feste, statische IP Route im Internet Router auf die lokale OpenVPN Server IP Adresse zeigt, ist es sinnvoller dem VPN Server immer eine feste und damit verlässliche IP Adresse zu vergeben. Sollte die dynamische DHCP IP Adresse sich einmal ändern läuft folglich die Route ins Leere und das VPN verliert die Verbindung. Etwas, das es zu vermeiden gilt.
Es ist also immer eine gute Idee dem VPN Server eine statische IP Adresse zu vergeben. Er ist gewissermaßen VPN Router und Router bekommen generell Prinzip bedingt immer statische IP Adressen an ihren Interfaces.
Das kann natürlich manuell am Server selbst in dessen Netzwerk Setup gemacht werden. Einfacher ist es aber über die Hardware MAC Adresse der verwendeten Server Hardware (Netzwerkkarte), dem DHCP Server im Router (Fritz Box) eine feste IP zuzuweisen.
So kann der Server flexibel auf DHCP Betrieb verbleiben (was meist Default in allen OS ist), bekommt aber so dennoch immer eine feste IP Adresse.
Das Screenshot Beispiel zeigt dies an einem FritzBox DHCP Server:

Welche Hardware Adresse (Mac) der Server verwendet verrät auf dem Server das Kommando ipconfig -all (Windows) oder ifconfig (Linux, MacOS). Man kann es aber oft je nach Router Modell in dessen grafischem Übersichtsmenü sehen.

Interne OpenVPN IP Adressierung

Der VPN Tunnel selber ist im OpenVPN ein eigenes IP Netzwerk und wird mit dem Konfig Kommando (Beispiel) server 100.64.64.0 255.255.255.0 in der Server Konfurations Datei bestimmt.
Diese interne Adressierung muss einzigartig sein im gesamten VPN Netz und ist deshalb nicht trivial, denn es gilt hier eine Überschneidung mit den zahllosen HIER.
Eine sehr elegante Alternative ist immer die Verwendung von IP-Adressen (100.64.0.0/10), die für Carrier-Grade-NAT (RFC 6598) reserviert sind. Damit ist zu jeder Zeit sichergestellt, dass die Tunnel-IPs nie mit den obigen privaten Adressbereichen der zahllosen privaten Consumer Router kollidieren können.
Es ist nicht zwingend und es können auch private hier.

Port Forwarding oder auch Port Weiterleitung bzw. Freigabe im Router

Damit VPN Clients von außen den internen OpenVPN Server überhaupt erreichen können, müssen diese die Firewall des Routers überwinden. Die Router Firewall schützt ja normalerweise ein dahinter liegendes lokales LAN wasserdicht vor solchen ungewollten Verbindungsversuchen von außen ! Ohne ein entsprechens Port Forwarding (Weiterleitung) würde die Router Firewall solche Verbindungen immer sicher verhindern mit dem Effekt das kein VPN Client den Server erreichen kann.
Man "sagt" also mit der Port Forwarding Freigabe der Router Firewall das sie doch bitte UDP 1194 auf die interne IP Adresse (192.168.188.50 = OpenVPN Server) passieren lassen soll:

Diese Einstellung lässt dann am Router Internet Port dort eingehenden OpenVPN Verkehr mit UDP 1194 (und NUR diesen Verkehr !) auf die interne OpenVPN Server IP 192.168.188.50 passieren.
Daraus folgt das die VPN Ziel IP, die im Client zu konfigurieren ist immer die WAN Port/Internet IP des Routers sein muss und nicht die lokale LAN IP des VPN Servers !

Dazu auch später mehr im Client Setup.
An diesem Punkt erkennt man auch sofort den oben schon angespochenen Nachteil einer solchen internen VPN Lösung ! Wäre der VPN Server direkt auf dem Internet Router oder Firewall onboard, müsste man keine solchen "Löcher" in die Firewall bohren und das VPN Konzept wäre in sich sicherer.

Statische Route auf internes VPN IP Netz

Der OpenVPN Server spannt intern ein eigenes IP Netz auf. Dieses muss einzigartig sein im gesamten Netz und darf nirgendwo sonst vorkommen. (Siehe Tips zum VPN IP Adressdesign oben).
Damit VPN Clients von extern alle Endgeräte, die im lokalen LAN den Internet Router als Default Router (Gateway) konfiguriert haben, per VPN erreichbar sind, muss der Router natürlich wissen wie er das interne OpenVPN IP Netz erreichen kann. Das übernimmt eine statische Route im Internet Router die allen Traffic für das OpenVPN IP Netz (hier 172.17.77.0 /24) dann an den VPN Server (192.168.188.50) sendet (siehe dazu Netzwerk Skizze oben):

Damit sind dann alle Einstellungen auf der Router und Netzwerkseite erledigt. Der Rest dreht sich nur noch um das Setup des OpenVPN Servers und der Clients.

OpenVPN Server und Client Konfiguration

Das Tutorial setzt voraus das die entsprechende OpenVPN Software auf Clients und Server installiert ist.

Windows: https://openvpn.net/community-downloads/
Apple MacOS: https://tunnelblick.net
Linux: Unter Debian basierten Linux wie z.B. Raspberry Pi (Raspian) oder Ubuntu geht das mit sudo apt install openvpn. Ein Grundsetup des Raspberry Pi findet man HIER. Beim Raspberry reicht das Raspian Buster Lite Image vollkommen aus: https://www.raspberrypi.org/downloads/raspbian/ Wer es dennoch mit GUI haben möchte nimmt das Desktop Image ohne Software.
Smartphone / Pad OVPN Client für Apple iPhone_iPad
Smartphone / Pad OVPN Client für Android

Generieren der OpenVPN Zertifikate und Schlüssel

Das am meisten herausfordernde ToDo bei einer OpenVPN Installation ist sicher das Erzeugen der Zertifikate und Schlüssel. Laien fühlen sich damit oft überfordert, was aber mit den entsprechenden Tools nicht der Fall sein muss.
Natürlich kann man OpenVPN auch mit einem simplen, statischen Passwort verwenden (sog. Preshared Key). Davon ist zumindestens in Firmennetzen aber dringenst abzuraten, denn diese statischen Schlüssel kann man durch einfache, ungeschützte Weitergabe sehr einfach kompromittieren.
Das hat dann zwingend eine Erneuerung dieses Passwortes für alle User mit einem erheblichen Arbeitsaufwand zur Folge, will man die Sicherheit eines VPN Zugangs bewahren.
Mit individuellen User Keys werden nur diese individuell ungültig, nicht aber das gesamte VPN. Trotz der etwas größeren Mühe lohnen sich also sichere Schlüssel.
Es gibt mehrere mögliche Wege wobei drei die meist genutzten sind bei einer fehlenden PKI:

Mit dem jeder OpenVPN Software beigepackten, textbasierten Easy-RSA Tool was im CLI bzw. Eingabeaufforderung zu bedienen ist.
Mit einem grafischen Tool wie z.B. XCA
Online, wie z.B.: http://www.mobilefish.com/services/ssl_certificates/ssl_certificates.ph ...

Letzteres ist zwar sehr bequem, birgt aber das Risiko der Unsicherheit, da man bei einem fremden Anbieter irgendwo im Web Daten hinterlässt und dieser theoretisch damit auch alle Schlüssel hat.

Die Handhabung des Easy-RSA Tools beschreibt ein anderes_OpenVPN_Tutorial hier im Forum. Es ist für alle Betriebssysteme vorhanden und in der einfachen Bedienung immer gleich.
Alle erzeugten Schlüssel sind, egal mit welchem Tool erstellt, immer über alle Betriebssystem Plattformen einsetzbar.
Man sollte allerdings im Hinterkopf behalten das die mit Easy-RSA erstellten Schlüssel eine Gültigkeit von 3 Jahren haben. Danach müssen neue Schlüssel generiert werden. Andere Tools wie XCA oder OpenSSL bieten die Option die Gültigkeitsspanne (Ablaufdatum) selbst zu definieren.

Dieses Tutorial geht nur auf die grafische XCA Variante ein um den Rahmen der vielfältigen Erstellungsmöglichkeiten für die OpenVPN Schlüssel nicht zu sprengen:
XCA findet man zum Downloaden für alle Betriebssysteme hier: https://hohnstaedt.de/xca/
Unter Windows installiert man idealerweise die portable Version die man dann immer bequem und sicher ohne Installation auf z.B. einem USB Stick verwahren kann.

Nach dem Starten des XCA Tools erstellt man eine Datenbank und generiert eine Vorlage mit seinen Daten:

Im zweiten Step setzt man in der Vorlage die Gültigkeitsdauer der Zertifikate. (Es reichen hier sicher auch erstmal 5 Jahre wem die hier gesetzten 10 doch zu lang erscheinen.)

Danach speichert man die Vorlage und erzeugt der Reihe nach eine Root CA und auf Basis der Root CA Vorlage, dann die OpenVPN Server und Client Zertifikate und die Schlüssel.
Die Art der Verschlüsselung und das Hashing Verfahren wählt das XCA Tool wie auch Easy-RSA Tool automatisch.

Zum Schluss werden die Zertifikate und Schlüssel exportiert:

Detaillierte Hilfe bietet die XCA Webseite per Video, YouTube und auch HIER

Diese exportierten Schlüssel und Zertifikate kopiert man dann in die entsprechenden OpenVPN Verzeichnisse auf Server und Client mittels USB Stick oder bei Linux, Raspberry z.B. außer USB Stick online mit WinSCP.

IP Forwarding (Routing) im OpenVPN Server aktivieren

Der Server ist gewissermaßen auch ein Router, denn er routet ja immer zwischen dem lokalen LAN und dem internen OpenVPN Tunnel IP Netz (hier im Beispiel 172.17.77.0 /24).
Normalerweise ist aber das Routing (IP Forwarding) auf Servern, egal mit welchem Betriebssystem immer per Default deaktiviert !
Damit der Server nun IP Pakete vom lokalen LAN ins VPN IP Netz und umgekehrt senden kann muss dafür das Routing auf dem OpenVPN Server Rechner im Betriebssystem aktiviert werden.
Bei Windows geschieht das über einen Eingriff in die Registry oder die Dienste Verwaltung.
(IPEnableRouter Parameter auf 1) siehe auch: https://www.edv-lehrgang.de/ip-routing-aktivieren/

Unter Linux/Raspberry editiert man mit dem nano Editor die Datei /etc/sysctl.conf und entkommentiert dort den Eintrag:

 # Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1 

indem man das "#" vor der Zeile net.ipv4.ip_forward=1 entfernt und somit das IP Forwarding/Routing aktiviert.
Danach muss der Linux Rechner rebootet werden.

Konfiguration OpenVPN Server

Vorab ein wichtiges Wort zur Tunnel Enkapsulierung:
Hier sollte in jedem Fall UDP als Enkapsulierungs Protokoll verwendet werden ! TCP erzeugt einen sehr großen Overhead was zu erheblichen Performance Verlusten und weiteren potentiellen Problemen wie Fragmentierung bei MTU/MSS Mismatch usw. führen kann ! Es gibt also sehr gute Gründe hier, wenn immer möglich, UDP zu verwenden ! Auch die offizielle OpenVPN Dokumentation weisst eindringlich auf das Preferieren von UDP hin !
Weitere Punkte die zu beachten sind:

Nicht mehr das veraltete net30 Verfahren in der Client Adressierung verwenden sondern das modernere und aktuelle subnet Verfahren.
Compression immer wegen des Security_Bugs (Voracle) und möglicher Konflikte bei der Verschlüsselung deaktivieren! Der Effekt ist so oder so sehr gering.
Entsprechende VPN_IP_Adressierungstips beim Netzdesign beachten ! Wichtig: Das interne IP Netz des OpenVPN Servers ("server 172.17.77.0 255.255.255.0" Kommando i.d. Konfig) muss einzigartig sein und darf sich mit keinem anderen lokalen IP Netz doppeln ! Hier also intelligenterweise IP Adressen aus dem vorab genannten Tip wählen. Eine gute Wahl ist immer der 172.16.0.0 /12er oder 10.0.0.0 /8er Bereich und dort ein einzigartiges IP netz mit einem /24er Prefix statt dem häufig verwendeten 192.168er Bereich da dort die Gefahr der Netzdopplung und damit Fehlfunktion droht.

Zudem ist es empfehlenswert immer die modernere Subnet Topology Verfahren zu verwenden als das alte NET30, was alle OVPN Clients in virtuelle /30er Subnetze zwingt.

Weiterhin zu beachten ist das die übliche Standard Namenserweiterung (Suffix) der Konfigurationsdatei .conf bei Verwendung unter Windows in .ovpn umbenannt werden muss. Das Windows Programm Icon wechselt dann auch sofort auf das typische OpenVPN Logo.
Unter allen unixoiden Betriebssytemen (Linux, Raspberry usw.) bleibt der typische .conf Datei Suffix.
Ein abschliessendes Wort zu den Namenserweiterungen (Suffix) der Schlüsseldateien (hier .pem):
In vielen Tools enden diese auf .key. Das ist von Tool zu Tool unterschiedlich und nur ein Name und Kosmetik. Man muss lediglich in der Konfigurations Datei genau darauf achten das diese Endungen immer mit den dort angegebenen Dateinamen übereinstimmen damit sie gefunden und ausgeführt werden.

Die einfache Konfig Datei des Servers sieht so aus.
Die hier verwendeten Crypto Algorithmen entsprechen dem üblichen Standard. Wer etwas modernere und stärker verschlüsselnde Algorithmen verwenden möchte findet in den weiterführenden Links ein Update. (Dank an den Kollegen @6376382705 an dieser Stelle!)

dev tun
proto udp4
port 1194
ca /etc/openvpn/server/CA.crt
cert /etc/openvpn/server/OVPN_Server.crt
key /etc/openvpn/server/OVPN_Server.pem
dh /etc/openvpn/server/dh2048.pem
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
server 172.17.77.0 255.255.255.0
topology subnet
push "topology subnet"
ifconfig-pool-persist ipp.txt
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
status-version 3
# client-to-client
# push "redirect-gateway def1 bypass-dhcp"
push "route 192.168.188.0 255.255.255.0"
# push "dhcp-option DNS 192.168.188.x"
keepalive 10 120
explicit-exit-notify 1 

Diese Datei muss mit der Endung .ovpn (Windows) oder .conf (Linux) zusammen mit den Zertifikaten im Konfig Verzeichnis abgespeichtert werden. Also z.B. server.ovpn (Windows) oder server.conf (Linux).
Das o.a. Beispiel zeigt eine Konfig Datei mit Pfad Angaben unter Linux. Pfadangaben sind bei Windows zu ändern in die entsprechenden Windows Konfig Verzeichnisse bzw. unter Windows entfällt dies, denn bei Import der Konfig Datei über das OpenVPN Taskleisten Symbol werden die Pfade entfernt.

⚠️ Split Tunneling oder Gateway Redirect?

Alle mit "#" auskommentierten Server Kommandos sind nicht aktiv und haben die folgende Bedeutung:

client-to-client = Erlaubt eine Client zu Client Komunikation. Im Default ist diese nicht erlaubt sondern nur Client zu Server.
push "redirect-gateway def1 bypass-dhcp" = Schickt statt nur den Traffic des lokalen LANs den gesamten Client Traffic in den VPN Tunnel ! Wenn dies aktiviert wird muss man dann zwingend den Eintrag push "route 192.168.188.0 255.255.255.0" mit "#" einkommentieren oder löschen ! ⚠️ Niemals dürfen beide Push Optionen zusammen in der Server Konfig stehen !! Ein grober Fehler der leider oft gemacht wird. Es geht entweder nur Split Tunnel oder Gateway Redirect.
push "dhcp-option DNS 192.168.188.<dns_server>" = Schickt einen lokalen DNS Server zum Client wenn man z.B. lokale DNS Namen im lokalen LAN auflösen möchte.

Die Konfig Kommandos müssen bei Bedarf aus- oder einkommentiert werden indem man das "#" davor entfernt oder einfügt.

Nach Änderung dieser Parameter ist der OpenVPN Server neu zu starten.
Unter Linux geschieht das mit dem Kommando systemctl restart openvpn-server@server wobei das server hinter dem "@" den Namen der Konfig Datei ohne die ".conf" Extension (hier server.conf) im Verzeichnis etc/openvpn/server bezeichnet. So kann man bequem mehrere Konfig Dateien vorhalten.
Analog geschieht das auf der Linux Client Seite mit systemctl restart openvpn-client@client1 im Verzeichnis etc/openvpn/client
Unter Windows rechtsklickt man das OpenVPN Symbol in der Taskleiste und wählt: Konfiguration importieren.

Wer z.B. einen Linux basierten Server wie RaspberryPi u.ä. als OVPN Server betreibt sollte ebenso daran denken das dort das IPv4 Forwarding (Routing) aktiviert werden muss. Klar, denn der Server ist ja in diesem Falle auch Router zwischen lokalem LAN und internem OpenVPN IP Netz. Das erledigt man mit der Zeile net.ipv4.ip_forward=1 die in der Datei /etc/sysctl.confentkommentiert ( "#" entfernen) werden muss.
Gleiches gilt für einen Windows Rechner wo dies über_die_Registry gemacht wird.
Danach müssen die Server rebootet werden um es zu aktivieren.

Natürlich kann man mit OpenVPN auch das gesamte Client Netz ins Server Netz routen. Das erfordert eine kleine Anpassung der Server Konfig Datei wurde hier aber bewusst aus Gründen der Übersichtlichkeit weggelassen !
In den weiterführenden Links am Schluß findet man ein solches Konfigurationsbeispiel.

Konfiguration OpenVPN Client

Auch hier gilt unter Windows die Standard Namenserweiterung der Konfigurationsdatei .conf in .ovpn umbenennen !

Die zum Server korrespondierende Client Konfig Datei sieht dann so aus:

dev tun
proto udp4
remote <router_wan_ip> 1194 # Remote OpenVPN Servername oder IP Addresse
ca   CA.crt
cert Client1.crt
key  Client1.pem
cipher AES-256-CBC
auth SHA256
auth-nocache
tls-client
remote-cert-tls server
persist-tun
persist-key
mute-replay-warnings
pull 

Der Platzhalter <router_wan_ip> steht hier für die WAN bzw. Internet IP am WAN/Internet Port des Routers (siehe Übersichts Screenshot oben !) hinter dem der OpenVPN Server betrieben wird. Oder, falls der Server öffentlich ist, der direkten Server IP.
Das kann natürlich auch eine ggf. vorhandene DynDNS Hostadresse über einen der zahlreichen freien DynDNS Dienstleister sein wie z.B. myFritz! oder noip.com usw.
So bekommt man auch mit einer wechselnden IP Adresse am Router immer einen festen Zugriff auf den OpenVPN Server !

Wer redundante OpenVPN Server oder solche auf Dual WAN Balancing Routern mit mehreren ISP Anschlüssen betreibt kann die Client Konfig mit mehreren "Connection" Statements darauf anpassen. Der Client nimmt bei Ausfall des ersten Eintrages dann sukzessive die folgenden Server Einträge.

...
proto udp4
<connection>
remote <router_wan_ip_1> 1194
</connection>
<connection>
remote <router_wan_ip_2> 1194
</connection>
ca   CA.crt
... 

Das folgende Client Beispiel ist die Windows Konfigurations Datei. Man erkennt das hier die Pfad Angaben durch den Import über den Windows OpenVPN Client entfernt wurden:

Unter Linux sind diese aber zwingend erforderlich und sähe dann so aus:
ca /etc/openvpn/client/CA.crt
cert /etc/openvpn/client/Client1.crt
key /etc/openvpn/client/Client1.pem

Dann steht einem finalen Test nichts mehr im Wege...

VPN Verbindung checken

Mit einem Doppelklick auf das VPN Symbol in der Windows Taskleiste startet man den VPN Tunnel und aktiviert auch die Log Anzeige:

Die Meldung Initialization Sequence Completed am Schluß zeigt das alles glatt gegangen ist und der Tunnel aktiv ist. Klappt alles kann man später immer mit einem Rechtsklick auf das Symbol und "Verbinden" den VPN Tunnel aufbauen.
Entsprechend wird dann auch das Taskleisten Symbol der VPN Verbindung grün:

Unter Linux startet systemctl restart openvpn-client@client1 die Client Verbindung. (Konfig Datei heisst client1.conf im Client Verzeichnis)

Stimmen statische Route und ist das IP Forwarding im OVPN Server aktiv verläuft ein Ping Check vom aktiven VPN Client

auf den OVPN Server intern: 172.17.77.1
auf den OVPN Server extern: 192.168.188.50
auf die lokale LAN IP des Routers 192.168.188.1,
und hier z.B. auf die Management IP Adresse des LAN Switches .22

dann ebenso erfolgreich wie auch der Aufruf z.B. des Web GUIs von Router und Switch über die remote VPN Verbindung.

Weiterführende Links

OpenVPN Grundlagen Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Gesamtes Client Netzwerk routen (LAN zu LAN Kopplung):
"One armed" Lösung:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Kaskaden Lösung:
Zugriff auf Gerät an LTE Router via VPN

Mikrotik Router als OpenVPN Server:
Clientverbindung OpenVPN Mikrotik

Handhabung der OpenVPN Konfig Dateien auf Debian basierten Linux Systemen (Ubuntu etc.):
OpenVPN-Verbindung

DS-Lite Anschluss und VPN: Lösung mit Vermittlungsserver und fester IP:
Jumphost mit vServer und Fritzbox
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Feste IPs zuhause in pfsense via WireGuard Tunnel
Feste IPs zuhause in pfsense via GRE Tunnel
Hilfe gesucht bei Routing Einstellungen OpenVPN
Tücken bei remotem Port Forwarding in den OpenVPN Tunnel via Jump Host beachten:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren

Grundlagen IP Routing:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Routing Fehler vermeiden !:
OpenVPN virtuelles Netz von LAN erreichen

OpenVPN Server App auf Synology NAS:
https://idomix.de/synology-diskstation-openvpn-server-einrichten-windows ...

OpenVPN Zugang mit Radius Server und 2FA absichern:
PfSense, openVPN und FreeRadius -Anfängerfrage
Freeradius Management mit WebGUI
https://www.youtube.com/watch?v=a1F03UY1xKg

OpenWRT / DD-WRT OpenVPN: NAT Probleme mit der LAN zu LAN VPN Anbindung sicher umschiffen:
Problem mit site 2 site VPN
Drucken über VPN - CCD Files

OpenVPN Server Zertifikats Check:
OpenVPN Server auf QNAP: keine Verbindung

Alternative OpenVPN Linux Anleitung (Ubuntu):
https://ctaas.de/OpenVPN_Server_Ubuntu_howto.htm

Alternative VPN Routing Protokolle:

VPN Server für alle Windows, Apple onboard VPN Clients und Smartphones:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi

VPN "Merkzettel" Wireguard:
Merkzettel: VPN Installation mit Wireguard

Tücken der Fritzbox Wireguard Konfiguration mit nicht AVM Hardware lösen:
S2S-Wireguard: AVM zu Mikrotik

VPN User mit den bordeigenen VPN Clients (IPsec) und pfSense/OPNsense ins Netz bringen:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

L2TP VPN für alle onboard VPN Clients auf pfSense Firewall:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer

L2TP VPN für alle onboard VPN Clients auf Mikrotik RouterOS:
L2TP VPN Server mit Mikrotik

Preiswerte OpenVPN und Wireguard Router Hardware:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...

Raspberry Pi 4 Hardware:
https://www.reichelt.de/raspberry-pi-4-b-4x-1-5-ghz-2-gb-ram-wlan-bt-ras ...
https://www.reichelt.de/raspberry-pi-4-b-4x-1-5-ghz-4-gb-ram-wlan-bt-ras ...
Netzteil:
https://www.reichelt.de/raspberry-pi-netzteil-5-1-v-3-0-a-usb-type-c-eu- ...
Passendes Gehäuse mit passiver Kühlung:
https://www.amazon.de/iuniker-Raspberry-Gehäuse-Kühlkörpe ...

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 561052

Url: https://administrator.de/contentid/561052

Ausgedruckt am: 19.12.2024 um 05:12 Uhr

39 Kommentare

Neuester Kommentar

Danke für deine Arbeit!

Du bist so krass :O

Hallo,

Typisch @aqui! Super Arbeit!

Brammer

Danke für eine weitere deiner vielen konkreten und spezifischen Anleitungen.

So schreibt man Anleitungen die eineindeutig sind!
Versuche Ich auch unseren Azubis beizubringen

Mein Senf
Thomas

danke auch von mir, für die nächste Revision:

indem man das "#" vor der Zeile net.ipv4.ip_forward=1 entfernt.
Danach muss der Server rebootet werden.

nein, wenn Du da 'eh auf moderne Distries verweist, kann man doch ebensogut nur noch dazu schreiben:

echo "1">/proc/sys/net/ipv4/ip_forward

und auf den reboot verzichten.

Ich wollte die wasserdichte Anfänger Methode vorziehen.

Bzw. Winblows muss man de facto rebooten.
Du hast aber natürlich Recht. Danke für den Hinweis !

Hut ab, sehr schöne Anleitung. Habe ich gestern mal testweise danach für einen Laptop gemacht (nutze sonst IPSEC für VPN). Bis auf Timeout-Probleme, resultierend aus Anbindung über Funk, ging das prima.

So sollte es auch sein mit der Umsetzung ! Danke für die Blumen...

Ich ziehe den Hut vor der Arbeit, die du geleistet hast. Anleitungen zu schreiben ist meist anstrengend, zeitaufwändig und oft undankbar.

Falls es nicht zu frech ist, füge ich noch hinzu, dass die pfSense (wer sie ohnehin im Einsatz hat) einen Wizard für OpenVPN hat und man das Paket "OpenVPN Client Export" zum exportieren von fertigen Client-Paketen (Cert, OpenVPN-Installer und Konfiguration) hinzuladen kann. Gerade als Laie ist das nützlich, da man recht leicht eine zertifikatbasierte VPN Verbindung bekommen kann und nicht aus Bequemlichkeit oder Frust beim "preshared Key" landet, weil es das Einzige ist, was man hinbekommen hat.

Nein, ist natürlich nicht frech.

Danke für den Hinweis !
Diese Option steht auch im oben zitierten generellen OpenVPN_Tutorial.
Sie ist allerdings nur für die Nutzer hilfreich die es mit einer pfSense Firewall umsetzen. Wer es mit Windows (Server), Linux, Raspberry Pi, OpenWRT oder irgend einer anderen Plattform nimmt dann meist die anderen erwähnten Tools.
Mit der pfSense hat man alternativ noch die etwas elegantere Option ganz ohne extra VPN Client auszukommen und alles mit den jeweils bordeigenen VPN Clients zu erledigen wie es in diesem_Tutorial erklärt ist.

Besten Dank für die Tolle Anleitung,

Klar macht es Sinn, das ganze auf einem Gerät zu installieren.
Ich finde es schade, dass es AVM bisher immer noch nicht auf die Kette bekommen hat, Openvpn zu implementieren.

Die haben Angst vor den dann massiv aufkommenden Support Fragen. Stell dir mal völlige IT DAUs vor die Zertifikate erstellen. Das kostet massiv Geld und bei einer billigen Plastik Consumer Box liegt sowas wirtschaftlich niemals drin.
Was ggf. kommen könnte ist das sie das neue Wireguard implementieren wenn es dann nun fest im Linux Kernel verankert ist. Denn wie jedermann weiss werkelt in der FritzBox auch ein Linux.
Das wird aber sicher noch etwas dauern bis das soweit ist und vor allem DAU massentauglich ist.
Generell rennt ja auch IPsec Native sauber und fehlerfrei und ist zudem auch in fast allen Betriebssystemen und Smartphones enthalten so das man dann auch mit der jetzigen VPN Funktion auf der FritzBox gut klar kommt sofern man mit dem mickrigen Durchsatz leben kann.
Man darf eben auch nicht vergessen das das ein billiges Massenprodukt sein soll und kein Business Router. Unter dieser Prämisse macht sie den Job ja sehr gut.

Wir haben zudem Routerfreiheit in der ganzen EU. Steht ja jedem frei der mehr will sich dann einen "richtigen" Router oder Firewall zu beschaffen.

Die haben Angst vor den dann massiv aufkommenden Support Fragen.

Ich finde mit der pfSense wird es doch genial vorgemacht. Ein Wizzard, der nur ein paar Fragen stellt und am Ende hat man ein Installationspaket für den Mac, Windows 7/8/10 und ggf. für den "Profi" die Konf mit Cert so. Meiner einer würde das sehr begrüßen. Einfacher geht es doch nicht mehr. Wer damit dann nicht zurecht kommt, der weiß auch nicht, dass es VPNs gibt.

Ich finde mit der pfSense wird es doch genial vorgemacht.

Da hast du natürlich Recht ! Wäre so kinderleicht.
Aber wer weiss was AVM da Marketing technisch bewegt ?!

Aber wer weiss was AVM da Marketing technisch bewegt ?!

Auch wieder wahr.

Spät, aber dennoch: Auch von mir ein richtig fettes Danke für diese Arbeit!

Ist in dieser Zeit mit angrenzender Sicherheitswahrscheinlichkeit perfekt im Rennen ...

Munter bleiben!

War auch die Intention. Danke für die Blumen.

Coole Anteilung !!
Das hätte ich damals auch gebraucht!

Auch ich danke dir für die tolle Anleitung. Ich habe schon nach vielen Anleitungen gearbeitet, aber eine Client - Server - Verbindung noch nie hinbekommen. Zuerst über Internet auf einen DD-WRT-Server, zuletzt auf einem Windows10-PC, wobei Client und Server auf der selben Maschine sind. Den Server kann ich problemlos starten.
Beim Verbinden des Clients kommt der Abbruch immer mit dem gleichen Fehler:

2021-01-05 17:22:17 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-01-05 17:22:17 TLS Error: TLS handshake failed
2021-01-05 17:22:17 SIGUSR1[soft,tls-error] received, process restarting 

Leider passiert das auch nach deiner Anleitung.
Wo liegt da nur der Fehler?
Ich versuche das schon seit Monaten, bin am Verzweifeln.
Hast du vielleicht die entscheidenden Hinweise für mich?
Viele Grüße
Harald

wobei Client und Server auf der selben Maschine sind.

Wie macht man denn sowas ?? Das ist gar nicht supportet und kann niemals klappen. Du kannst ja niemals auf derselben Maschine gleichzeitig eine Client und Server Konfig betreiben, wie sollte das gehen ??
Ausnahme natürlich da rennt ein Virtualisierer ala VirtualBox oder sowas...
Oder meinst du das du mal den einen oder mal den anderen startest ? Das ginge dann natürlich.

Der Fehler ist mit an Sicherheit grenzender Wahrscheinlichkeit die Windows Firewall bzw. das Firewall Profil. Diese blockt UDP Port 1194 Pakete und das ergibt dann den Negotiation Timeout.
Du musst also dafür sorgen das die VPN Pakete auch die lokale Firewall passieren können sonst wird das natürlich nicht klappen.
Windows Firewall Einstellungen für OpenVPN Tunnel

Danke für deine Antwort. Ich werde das mal auf zwei verschiedenen PC's im selben Netzwerk versuchen und mich um die Windows-Firewall kümmern.

Danke für die Hinweise, es klappt jetzt - Client -> Server im gleichen Netz und auch Client aus dem Internet zum Server.
Jetzt habe ich noch ein Problem, welches du auch schon mal behandelt hast.
Ich betreibe einen Asus RT-AC68U mit neuester DD-WRT-Firmware als OpenVPN-Server hinter einem Speedport Hybrid (zu diesem gibt es leider keine Alternative). In dem Speedport Hybrid kann man keine statischen Routen eintragen. Du hast dazu u.a. folgenden Hinweis gegeben:

"Unter Linux/Raspberry editiert man mit dem nano Editor die Datei /etc/sysctl.conf und entkommentiert dort den Eintrag:

Uncomment the next line to enable packet forwarding for IPv4

(zu diesem gibt es leider keine Alternative)

Das ist, wie immer, technischer Quatsch, denn das was der kann kann jeder vernüftige Dual WAN Balancing Router auch. Aber andere Baustelle und anderes Thema !

In dem Speedport Hybrid kann man keine statischen Routen eintragen. Du hast dazu u.a. folgenden Hinweis gegeben:

Das ist sehr schlecht aber kein KO Kriterium. Das bedeutet dann nur das du auf jedem einzelnen Host im lokalen Netzwerk den du via VPN ereichen willst eine eigen statische Route eintragen musst. Logisch, denn die globale Netzwerk Route kann man ja dann nicht konfigurieren wenn das in billigen Schrottroutern nicht supportet ist.
Bei einem Windows Rechner geht das dann so:
route add <internes_OVPN_netz> mask <maske> <ip_adresse_OVPN_server> -p

Du hast dazu u.a. folgenden Hinweis gegeben:

Das ist hier aber technischer Unsinn und gar nicht relevant, denn damit wird auf einem unixoiden Server (z.B. Linux) selber das IP Forwarding (Routing) aktiviert also das der OVPN Server selber routen kann.
Da du aber schon per se einen Router betreibst ist das ja vollkommen überflüssig denn das dort IP Forwarding aktiviert ist ist evident.
Abgesehen davon hat IP Forwarding nix mit statischen Routen zu tun. Zeigt eher das du nicht so wirklich verstanden hast worum es geht, kann das sein ?!

So oder so ist der gesamt Einwand auch etwas wirr. Versteht man dich richtig dann betreibst du die Speedport Gurke mit dem Asus in einer Router_Kaskade. Sprich der Speedport forwardet per eingetragenem statischen Forwarding alle UDP 1194 Pakete an den Asus und der ist selber OVPN Server, sprich er HAT also schon die Route ins interne OpenVPN Netz. Alle Clients hinter dem Asus also an seinem lokalen LAN kommen also so zentral ins OpenVPN netz weil es ja direkt am Asus Router dran ist. Eine statische Route ist also völlig überflüssig.
Dein Kaskaden Design wird also so out of the Box fehlerlos funktionieren.

Danke das Du den Artikel laufend weiter pflegst!
"Beharrlichkeit ist eine Tugend"

Danke für die 💐 !

Hallo aqui,

dieser Artikel von dir ist wirklich klasse.

Verrätst du mir mit welcher Software du den Netzwerkplan erstellt hast?

Mir gefallen die Netzwerksymbole sehr gut.

LG

Immer gerne, das ist kein Geheimnis...
Die Software ist Visio (Windows) oder dia (Win, Mac, Linux) oder Omni Graffle (Mac) oder LibreOffice Draw. Welches man da nimmt ist persönliche Geschmackssache.
Dazu verwende ich die freien Cisco Topology Icons. Es gibt aber auch ne Menge anderer, freier Visio ISO Netzwerk Icons im Netz die man, je nach eigenem Geschmack, auch verwenden kann.

Hallo @aqui,

dev tun
proto udp4
port 1194
...

wird Zeit, die Config etwas zu überarbeiten. Mit 2.4 hat sich einiges getan.

Folgendes würde ich ergänzen:
Ab Version 2.4 (Serverconfig)

auth SHA512

tls-version-min 1.2

ncp-ciphers AES-256-GCM:AES-192-GCM:AES-128-GCM

tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

und ganz klar:

tls-crypt

Ab Version 2.5 (Serverconfig)

tls-crypt-v2

dann ist die Anleitung auch wieder aktuell.

Danke für deine Arbeit!

Gruß

Danke für das Feedback! 👍 Arbeite ich ein!

Noch besser ist es natürlich GAR KEIN OpenVPN mehr zu verwenden.

Wegen der miesen Skalierbarkeit sollte es eigentlich nirgendwo mehr erste Wahl sein. Mit Wireguard und IPsec gibt es ja deutlich besser skalierende VPN Alternativen! Vom Gefrickel mit externen VPN Clients und dem manchmal für Laien anspruchsvollem Zertifikatshandling mal nicht zu reden.

Hallo Aqui

Dann gilt das Argument nicht mehr, dass man OpenVPN nimmt, um SSL zu verwenden?
IPSEC ist ja erheblich komplexer und belastet das Netzwerk stärker.

Dann sind die Experten wie Du also für ein Ende der OpenVPN Nutzung?

Beste Grüsse

IPSEC ist ja erheblich komplexer und belastet das Netzwerk stärker.

Das ist Unsinn, woher hast du das? Der Durchsatz ist mit IPsec und sogar WG deutlich besser und performanter was aber primär an der gruseligen Implementation von OpenVPN in die OS liegt. Mit NAT tRaversal gibts da auch keinen Nachteil im Handling. Siehe auch immer wiederkehrende Diskussionen zu der Thematik wie hier.
Experten nutzen in Business Umgebungen kein OpenVPN wegen der miesen Skalierbarkeit und WG ist auch derzeit noch recht fragwürdig. Was man im heimischen Bastelnetzwerk macht ist ein ganz anderes Thema.
Also Ja, IPsec wäre immer erste Wahl. Für dich als Cisco Profi sowieso!! 😉

Das haben wir in einem Lehrgang 2014 so gelernt.
Zitat aus dem Fachbuch:

Kapitel 6.8
IPsec ist immer noch das bevorzugte Protokoll, um auf der Netzwerkschicht eine
IPsec
Verschlüsselung der Inhalte der Datenpakete vorzunehmen und zugleich die Au-
thentizität der Kommunikationspartner sicherzustellen. Seine (logische) Bindung
an die Public Key Infrastructure macht das Protokoll jedoch schwergewichtig und
anfällig sowohl für Fehlkonfiguration als auch für Manipulation.

Quelle:
Technik der IP-Netze: Internet-Kommunikation in Theorie und Einsatz - Anatol Badach & Erwin Hoffmann

Quellen aus dem Web:
networkworld.com:Big IPSec guns help push forward SSL movement
With Nokia entering the game, this leaves only Cisco among the top IPSec VPN vendors listed by market research firms without SSL remote access support.
Cisco literature says it will support SSL remote access during the second half of this year, but not exactly how.
...
Industry observers predict that within a few years, SSL remote access support will reside in routers. Based on the move of big router vendors and IPSec vendors to get in the game, that time is getting closer.

gridinsoft.com: Difference Between IPSec and SSL
Until recently, OpenVPN/SSL was considered the best VPN combination for most consumer VPN users. It is fast enough, secure, open-source, and can overcome NAT firewalls. It can also support UDP or TCP.

Difference Between IPsec and SSL
As you can see, each type has its own advantages and disadvantages. Security and convenience are two key factors to consider. Because IPsec requires third-party client software, it is more complicated and expensive to set up and maintain.

Cloudfare: Was ist IPsec?
IPsec-Protokolle fügen den Paketen mehrere Header und Trailer hinzu, die alle mehrere Bytes benötigen. Bei Netzwerken, die IPsec verwenden, müssen entweder die MSS und die MTU entsprechend angepasst werden, oder die Pakete werden fragmentiert und leicht verzögert

Enterrprise Networking Planet: SSL VPNs vs. IPsec VPNs: VPN Protocol Differences Explained
SSL VPNs are easier to set up and manage than IPSec VPNs, and they work well for organizations that need to provide remote access to web-based applications.

VPN encryption explained: IPSec vs SSL
The reason is that IPSec operates at the Network Layer of the OSI model, which gives the user full access to the corporate network regardless of application. It is more difficult to restrict access to specific resources. SSL VPNs, on the other hand, enable enterprises to control remote access at a granular level to specific applications.

nstec.com: What’s The Difference Between SSL And IPsec VPNs?
SSL VPNs tend to be easier to set up and use than IPsec VPNs.

IPsec vs. SSL VPN: Which One Is Better for You? (2023 Update)
SSL VPNs are generally faster at negotiating server or web connections — for example, it takes a shorter time to log in to an online portal. Although, the IKEv2/IPsec protocol also has a reputation for negotiating connections faster, for example, switching from phone data to WiFi.

zenarmor.com: What is IPsec VPN and How does it Work? The Complete Guide for IPsec
Troubleshooting Difficulties: IPsec can need a significant amount of network-level troubleshooting. Those that install IPsec but are not properly aware of the possibilities risk not just network interruption but also major security breaches.

Difference between IPSec and SSL

t.b.c.

Ein Bild sagt mehr als 1000 Worte!!

Quelle: https://www.wireguard.com/performance/

Hallo Aqui

Ein Bild ohne Kontext bzw. Quelle ist wertlos.

Selbst wenn die Aussage wahr wäre, dass IPSEC VPN "immer" schneller sei, bleiben die weiteren Kritikpunkte (Komplexität , Security, etc.) aus den Quellen bestehen.

Unter dem Strich ist es egal. Ich behalte im Kopf, dass ein erfahrener Experte wie Du in jedem Fall IPSEC für ein VPN verwenden würde. Best Practice - daran halte ich mich.

Beste Grüsse

Mit der "Komplexität" ist doch Unsinn, das ist bekanntlich immer ein relativer Begriff. Meist reden so Laien weil sie die Prinzipien dahinter nicht verstehen. Analog ist das die Zertifikatserstellung bei OpenVPN. Daran scheitert oft ein Gros der User. Das soll dann weniger "komplex" sein?!
Wireguard hat das für die Massen dann vereinfacht obwohl auch nicht jeder den Sinn und Unsinn von Keys versteht. Das dann als Maßstab einer Beurteilung zu nehmen ist immer eine subjektive Sichtweise.
Schneller als OpenVPN ist also eigentlich alles. Das ist aber auch bekannt weil es generell an der schlechten Integration in den OS liegt. Es ist aber deshalb so populär weil es seit Jahren verfügbar ist und das auch stabil und einige Consumer Boxen es mit Klicki Bunti an Bord haben.
Der Siegeszug des subjektiv einfacher zu konfigurierenden Wireguard und dessen deutlich bessere Integration in den Kernel, wie es auch IPsec mit dem Charon Daemon hat, wird das langfristig gesehen sehr wahrscheinlich aber ändern. Dennoch bleibt IPsec auch wegen der langen und auch breiten Verfügbarkeit in Endgeräten besonders im professionellen Bereich, seiner langen Stabilität und der anerkannten Sicherheit immer die erste Wahl.

Schöner Leitfaden, der auch die Grundfragen klärt.

Man sollte allerdings im Hinterkopf behalten das die mit Easy-RSA erstellten Schlüssel eine Gültigkeit von 3 Jahren haben. Danach müssen neue Schlüssel generiert werden. Andere Tools wie XCA oder OpenSSL bieten die Option die Gültigkeitsspanne (Ablaufdatum) selbst zu definieren.

Auf die vars-Datei bist du hier im Detail nicht eingegangen, doch ließe sich dort der Gültigkeitszeitraum anpassen.

push "redirect-gateway def1 bypass-dhcp" = Schickt statt nur den Traffic des lokalen LANs den gesamten Client Traffic in den VPN Tunnel ! Wenn dies aktiviert wird muss man dann zwingend den Eintrag push "route 192.168.188.0 255.255.255.0" mit "#" einkommentieren oder löschen ! ⚠️ Niemals dürfen beide Push Optionen zusammen in der Server Konfig stehen !! Ein grober Fehler der leider oft gemacht wird. Es geht entweder nur Split Tunnel oder Gateway Redirect.

Hieße das im Umkehrschluss, wenn push "redirect-gateway def1 bypass-dhcp" aktiv ist, ich über einen VPN Client nicht über die Netzwerk-LAN-IP auf andere Geräte zu greifen kann oder wäre dies hier bereits inkludiert. Gibt es eine alternative Lösung? Ich hatte bisher beide Befehle ohne merkliche Konflikte aktiv.

Gibt es eine alternative Lösung?

Nein. Bei Client Dialin VPNs sind immer nur diese beiden Optionen entweder oder definiert. Bei Site to Site verhält es sich etwas anders und ist abhängig vom Protokoll.

Mit der vars Datei hast du recht. Danke für den Hinweis.
Das Tutorial sollte nur einen recht einfachen Überblick für den OpenVPN Start geben, deshalb ist bewusst nicht jede Konfig Nuance erwähnt worden um Anfänger nicht gleich abzuschrecken.

danke für die Arbeit... wie ist das denn aber mit der Umsetzung aufs DS-LITE: Kunden, die bei uns in ihr OPPEN VPN Netz wollen können es nicht weil der Provider der "Gäste-Leitung" nur IPV6 bereitstellt

Was ist denn ein "OPPEN VPN Netz"? 🤔

Die DS-Lite Problematik gilt einzig und allein nur für die VPN Responderseite und IPv4. Also die Seite wo der Responder sprich der VPN Server steht, der die Verbindungsanfragen der Clients annehmen muss.
Dieser MUSS zwingend eine öffentliche IPv4 Adresse haben um eine VPN Verbindung herstellen zu können. An einem DS-Lite Anschluss scheitert sowas da es dort keine öffentliche IPv4 Adresse gibt die von außen (Internet) erreichbar ist (CG-NAT).

Für VPN "Gäste" also die VPN Initiator Seite (Client) ist das völlig irrelevant. Diese können auch an einem DS-Lite Anschluss liegen. Das spielt für diese deswegen keine Rolle weil diese die VPN Verbindung ja initiieren also aktiv ausgehend aufbauen.
Dadurch bekommen die Clients im Falle von DS-Lite im CG-NAT Gateway ihres Providers eine öffentliche IPv4 die dann für diese eine NAT Session temporär gespeichert wird. Rücktraffic vom VPN Server kann so wieder der internen DS-Lite Absenderadresse zugeordnet werden und die VPN Verbindung kommt zustande.
Fazit:
Einzig für die VPN Serverseite ist eine öffentliche IPv4 für den VPN Betrieb zwingend. Für VPN Clients die an einem DS-Lite hängen besteht diese Hürde nicht. Die arbeiten wie jeder andere Client auch.
Wenn man zwingend einen VPN Server (Responder) an einem DS-Lite Anschluss betreiben muss dann bleibt wegen der o.a. CG-NAT Problematik nur die Lösung mit einem Jumphost. Egal welches VPN Protokoll.

Ein IPv6 Tunnel ist generell davon ausgenommen, denn auch am DS-Lite gibt es ja immer öffentliche IPv6 Adressen da NAT generell bei IPv6 inexistent ist.
IPv4 kann natürlich auch in einem IPv6 Tunnel problemlos übertragen werden wie für OpenVPN z.B. HIER im Detail beschrieben.
Ob man dafür dann unbedingt noch das in die Jahre gekommene OpenVPN mit sehr mieser VPN Performance und Skalierbarkeit einsetzt oder auf das modernere Wireguard oder IPsec setzt ist dann eher eine Frage der Anforderung an ein VPN oder eine Geschmacksfrage.

Anleitung Netzwerke Sicherheit Router, Routing VPN

Serie: VPN-Praxistutorials