kodach
Goto Top

OpenVPN Access Server automatisch Verbindung trennen

Guten Abend

Da zwei Verbindungen kostenlos sind habe ich mal OpenVPN Access Server getestet. Für eine private Anwendung reicht das ja. Die Installation ist sehr einfach und alles funktionoert auf anhieb.

Ich suche aber eine Möglichkeit das sich ein Client nach einer gewissen Zeit zwangs trennt, da ich nicht möchte das sich der User angemeldet lässt. Vorallem da man nur zwei Verbindungen hat.
Lässt sich das irgendwie machen? Habe nur eine Lösung bei openvpn mit config File gefunden. Wie dies beim AS funktioniert weiss ich aber nicht.

Sind beim "normalen" openVPN eigentlich quch nur 2 Verbindungen dabei? Sonst nehm ich ggf den auch wenn es keine grafische Oberfläche gibt.

Gruss

Oliver

Content-ID: 564748

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

Ausgedruckt am: 24.11.2024 um 18:11 Uhr

laster
laster 14.04.2020 um 08:33:15 Uhr
Goto Top
Hallo Oliver,

Sind beim "normalen" openVPN eigentlich quch nur 2 Verbindungen dabei? Sonst nehm ich ggf den auch wenn es keine grafische Oberfläche gibt.
ja, die Community Version ist in der Anzahl der gleichzeitigen Verbindungen nicht begrenzt.
Es giebt hunderte Anleitungen im Web, mit denen Du auch ohne GUI zum Ziel kommst...

vG
LS
aqui
aqui 14.04.2020 um 08:55:21 Uhr
Goto Top
Sind beim "normalen" openVPN eigentlich quch nur 2 Verbindungen dabei?
Nein, das ist Quatsch. Dort gibt es keinerlei Limit und du kannst auch 2000 oder 200000 VPN Verbindungen darauf nutzen. Guckst du hier:
Merkzettel: VPN Installation mit OpenVPN
KodaCH
KodaCH 14.04.2020 aktualisiert um 22:27:51 Uhr
Goto Top
Könnte man die Zertifikate auch über eine Windows Server PKI erstellen? Wären dass dann Client Zertifikate für Server und Clients? Oder gibt es spezielle Zertifilatsvorlagen für OpenVPN
Denke wenn man eine eigene Zertifizierubgsstelle hat wäre ja die Verwendung eines weiteren Tools wie XCA schade/Überflüssig

Ich werde das dann mal probieren auch wegen der Zwangstrennung.

Ps. Tolle Anleitung. Danke.

Gruss

Koda
aqui
aqui 15.04.2020 um 09:29:11 Uhr
Goto Top
Oder gibt es spezielle Zertifilatsvorlagen für OpenVPN
Nein, das kann man mit jeder beliebigen PKI erstellen. Ob OpenSSL, Easy-RSA, Windows, XCA, Online im Web oder was auch immer. Das ist völlig Wumpe.
KodaCH
KodaCH 15.04.2020 um 12:25:54 Uhr
Goto Top
Hallo

Danke für die Antwort. Das klappt sehr gut. Auch mit der Windows PKI. Ich habe jedoch noch wenige Probleme, bei denen ich keine Lösung gefunden habe. Ggf hat da ja jemand von euch Tipps für mich.
  • Wie sperre ich einen Client? Ich habe in der Windows PKI das Zertifikat zwar gesperrt und auch eine neue Sperrliste generiert, trotzdem kann der Client noch verbinden. Gibt es ggf eine Liste die ich führen kann um ihn direkt in der OpenVPN Konfiguration zu sperren?
  • Ich bin grösstenteils nach der Anleitung von @aqui gegangen. Ich habe dann eine Statische Route in meinem UniFi Gerät erstellt welche das VPN Subnetz enthält und die IP des VPN Servers. Ebenfalls habe ich in der server.conf noch meine beiden DNS Server eingetragen. Der Zugriff funktioniert auch wie gewünscht. Was ich aber noch nicht herausgefunden habe ist ob/wie ich ein bestimmtes Subnetz sperre. Ich habe die Netzte mal in der server.conf eingetragen:
push "route 10.10.5.0 255.255.255.0"  
push "route 10.20.5.0 255.255.255.0"  
push "route 10.30.5.0 255.255.255.0"  
Aber selbst wenn ich dort eine Zeile z.B. 10.30.5.0 auskommentiere hat der VPN Client Zugriff darauf.
  • Zum Schluss möchte ich noch erreichen das der Client z.B. nach 3 Stunden automatisch getrennt wird und nicht wieder automatisch verbunden wird. Die am meisten verwendete Lösung ist mit die folgende
inactive 300 [10737418240]
ping-restart 0
Der Wert von inactive habe ich bewusst mal auf 10GB gesetzt da der client nie so hoch kommt und ich dies mal für ein Test erzwingen wollte.
Leider geschieht keine Trennung.

Gruss und Danke

Koda
aqui
aqui 15.04.2020 aktualisiert um 15:10:28 Uhr
Goto Top
Aber selbst wenn ich dort eine Zeile z.B. 10.30.5.0 auskommentiere hat der VPN Client Zugriff darauf.
Du hast auf dem Radar das der Client das in seiner Routing Tabelle cacht ?!
Er behält das also nich eine Weile egal ob du es am Server auskommentierst. Das Auskommemntieren bewirkt nur das der Server dieses Subnetz bei Tunnel Verbindungsaufbau nicht in die OS Routing Tabelle pusht.
Die ist auch einzig nur relevant. Wenn du einen Winblows Client hast dann siehe dir immer mit route print dessen Routing Tabelle an. Die ist relevant für das Paket Forwarding in die Zielnetze !
Im Zweifel löschen mit route delete 10.30.5.0 oder Reboot und dann neu checken.

Was das gesperrte Zertifikat angeht musst du eine CRL erstellen, das ist richtig. Du musst das allerdings auch mit dem –crl-verify crl Parameter in der Konfig Datei aktivieren sonst passiert da nix.
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4 ...
Was das inaktive anbetrifft ist das schon richtig. Pings und Tunnel Keepalive triggern den Zeitcounter nicht.
Das 10GB ist aber eher kontraproduktiv, weil das Manual sagt dann gilt wenn weniger als 10G Traffic in 300 Sekunden auftritt dann exit.
Den Volumen Parameter solltest du besser weglassen.
Wenn nach dem Timeout kein Disconnect passiert, dann bedeutet das das noch relevanter Traffic den Counter triggert. Das kann alles mögliche auf dem Client sein an das du nicht denkst wie NTP, oder irgendwelche Apps die im Hintergrund werkeln.
KodaCH
KodaCH 15.04.2020 um 17:40:22 Uhr
Goto Top
Guten Abend

Danke erneut für deine Antwort.

CRL: Ich wollte gerade schreiben das ich da an einem Test bin. Diesen habe ich nun auch durchgeführt. Anscheinend wird die URL der Windows PKI für die CRL nicht überprüft. Ich habe nun ein kleines Shell Script erstellt welches mir regelmässig die CRL der Windows PKI herunter läd und ins PEM Format umwandelt. Dies funktioniert perfekt.

Routing: Irgendwie scheint bei mir alles zu Routen egal was ich dort drin stehen habe. Getestet habe ich es mit einem Android Gerät sowie einem Windows PC. Wenn ich ein route delete versuche kommt die Meldung das kein Eintrag gefunden wurde. Ich weiss nicht ob das an meiner Unifi USG liegen könnte. Hier mal meine server.conf
port 1194
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dhparam.pem
crl-verify /etc/openvpn/server/crl.pem
tls-auth /etc/openvpn/server/ta.key 0
server 10.10.80.0 255.255.255.0
topology subnet
push "topology subnet"  
ifconfig-pool-persist ipp.txt
push "route 10.10.1.0 255.255.255.0"  
#push "route 10.10.5.0 255.255.255.0" 
push "route 10.10.7.0 255.255.255.0"  
push "redirect-gateway def1 bypass-dhcp"  
push "dhcp-option DNS 10.10.1.250"  
push "dhcp-option DNS 10.10.1.251"  
keepalive 10 120
cipher AES-256-CBC
auth SHA512
user nobody
group nogroup
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
verb 4
status-version 2
explicit-exit-notify 1
inactive 300 [10737418240]
ping-restart 0
Vielleicht sagt dir diese ja mehr.
Wenn ich openvpn Starte für ein Livelog, erhalte ich diesen Eintrag der zeigt das mein unerwünschtes Netz nicht drin ist für das routing:
SENT CONTROL [XXXXX]: 'PUSH_REPLY,topology subnet,route 10.10.1.0 255.255.255.0,route 10.10.7.0 255.255.255.0,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.10.1.250,dhcp-option DNS 10.10.1.251,route-gateway 10.10.80.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.10.80.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)  

Zwangstrennung: Die 10GB waren nur Testweise. Da der VPN jeweils maximal 2 oder 3 Stunden benötigt, möchte ich dies einbinden weil der User gerne vergisst die Verbindung selber zu trennen. Aber irgendwie trennt er auch nach 10 Minuten nicht.
aqui
aqui 15.04.2020 aktualisiert um 18:16:21 Uhr
Goto Top
Ich weiss nicht ob das an meiner Unifi USG liegen könnte.
Nein, ganz sicher nicht !
Eigentlich hätte dir das aus selber sofort auffallen müssen !! Sieh dir die Konfig nochmal selber in aller Ruhe genau an !
Dort erkennst du push "redirect-gateway def1 bypass-dhcp" und das ist der böse Buhmann, denn damit machst du einen Default Gateway Redirect, sprich biegst das Default Gateway des Clients auf den Tunnel so das der alles in den Tunnel routet. Auch lokalen Internet Traffic.
Vermutlich hast du nie ein route print gemacht oder Traceroute sondt wäre dir das sicher aufgefallen.
Es ist natürlich (sorry) völliger Quatsch und routingtechnischer Blödsinn ein Split Tunneling und ein Gateway Redirect Kommamndo in einer Konfig zu haben ! Das geht logischerweise so nicht. Zumal das Redirect das letzte Push Stament ist und die anderen damit tötet !
Vergiss also das Redirect und entfernen das !!
Dann wir d auch nur das an lokalen LANs in den Tunnel gesendet was du über das push route... Kommando dort konfigurierst.
Aber irgendwie trennt er auch nach 10 Minuten nicht.
Das ist wegen des o.a. Konfig Fehlers dann auch nicht weiter verwunderlich. Mit dem Redirect sendest du ja sämtlichen Traffic in den Tunnel. Da ist dann irgendwo eine der 1000 Microsoft nach Hause telefonier Apps dabei die dir mit zyklischen Keepalives auf Update Server, Internet Erkennung, NTP oder was auch immer den Tunnel Timer triggert.
Auch sicher eine Folge des fehlerhaften Push Kommandos mit dem Redirect.

Das mit der CRL Liste ist ein pfiffiger Workaround ! 👍
Die URL kann er ja nur prüfen wenn du ihm via Samba ein Share dahin legst. (Sofern dein OVPN Server unixoid ist ?!)
Aber so gehts ja auch und ggf. auch sicherer weil du das PKI Verzeichnis nicht freigeben musst. Machst du die PEM Formatwandlung mit Openssl ? Das Script wäre mal interessant wenn nicht geheim. face-wink
Noch ein kosmetischer Tip:
status-version 3 solltest du auf 3 setzen, dann bekommst du den Status Überblick der aktuell arbeitenden Clients (openvpn-status.log Datei) schöner mit Tabs getrennt.
KodaCH
KodaCH 15.04.2020 aktualisiert um 18:48:41 Uhr
Goto Top
Zitat von @aqui:
Vermutlich hast du nie ein route print gemacht oder Traceroute sondt wäre dir das sicher aufgefallen.
Es ist natürlich (sorry) völliger Quatsch und routingtechnischer Blödsinn ein Split Tunneling und ein Gateway Redirect Kommamndo in einer Konfig zu haben !
Gemacht habe ich es, war aber ehrlich gesagt der Meinung das ich mein Netz 10.10.5.0 sehen müsste wenn es so ist. Aber ich kenne mich im Netzwerk noch immer nicht so perfekt aus und ich bin noch viel am lernen.
Ich habe den Eintrag nun entfernt, und es scheint auch soweit zu funktionieren. Danke dir.

Zitat von @aqui:
Das ist wegen des o.a. Konfig Fehlers dann auch nicht weiter verwunderlich. Mit dem Redirect sendest du ja sämtlichen Traffic in den Tunnel.
Auch ohne diesen Eintrag klappt es nicht. Auch auf den Android Gerät nicht. Und 10 GB ist ja extrem viel. Wenn ich es trenne zeigt er am Schluss eine so kleine Datenmenge an das er hätte trennen müssen. Ich finde eine Zwangstrennung nach einer gewissen Zeit eigentlich sehr sinnvoll. Je mehr ich im Internet dazu lese, je mehr beschleicht mich die Befürchtung das es nicht sauber klappt. Viele berichten von Problemen damit. Aber ggf hast du ja noch eine Idee face-smile

Zitat von @aqui:
Die URL kann er ja nur prüfen wenn du ihm via Samba ein Share dahin legst. (Sofern dein OVPN Server unixoid ist ?!)
Ich habe die Liste auch mit https frei gegeben. Dachte diese kann er prüfen. Und ja es ist ein Debian OpenVPN Server. Aber dem ist wohl nicht so. Er sagt mir auch das er die CRL nicht bekommt "VERIFY WARNING: depth=1, unable to get certificate CRL:". Könnte mir auch vorstellen das OpenVPN das Windows Format der CRL nicht mag. Aber wer weiss. Mit meinem Workaround klappt das für mich perfekt

Zitat von @aqui:
Das mit der CRL Liste ist ein pfiffiger Workaround ! 👍
Aber so gehts ja auch und ggf. auch sicherer weil du das PKI Verzeichnis nicht freigeben musst. Machst du die PEM Formatwandlung mit Openssl ?
Genau. das ganze ist mit einem extrem rudimentären Shell Script gemacht. Hier mal der Code falls jemand Interesse hat. Wüsste auch nicht was geheim daran istface-smile Bin froh wenn ich auch mal etwas zeigen kann was leuten helfen könnte.

Bei wget verwende ich die URL mittels Hochkomas, da ich Sonderzeichen drin habe und es ohne diese nicht klappen würde. Diese habe ich hier daher auch drin gelassen.
#!/bin/bash
DATE=$(date +%Y-%m-%d-%H-%M)
CRL_FILE="/etc/openvpn/server/crl.pem"  
ORIGINAL_CRL_FILE="/etc/openvpn/$DATE-original.crl"  

systemctl stop openvpn@server
rm "$CRL_FILE"  
wget -O "$ORIGINAL_CRL_FILE" 'http://cert.meinedomäne.tld/CertEnroll/Domäne Root CA.crl'  
openssl crl -in "$ORIGINAL_CRL_FILE"  -inform DER -out "$CRL_FILE"  
rm "$ORIGINAL_CRL_FILE"  
systemctl start openvpn@server
Das ganze dann z.B. mit einem cronjob einmal täglich laufen lassen. Ich denke es würde auch ohne das stoppen des Services klappen da die Liste ja auch im Betrieb neu eingelesen werden muss. Da der Service in der Nacht aber nicht benötigt wird kann es sicherlich nicht schaden.

Zitat von @aqui:
Noch ein kosmetischer Tip:
status-version 3 solltest du auf 3 setzen, dann bekommst du den Status Überblick der aktuell arbeitenden Clients (openvpn-status.log Datei) schöner mit Tabs getrennt.
Danke. Das setze ich gleich so um.
aqui
aqui 15.04.2020 aktualisiert um 19:12:44 Uhr
Goto Top
und es scheint auch soweit zu funktionieren.
So sollte es auch sein ! 👍
Ich finde eine Zwangstrennung nach einer gewissen Zeit eigentlich sehr sinnvoll.
Ja, das ist richtig. Ich habe das aber auch noch nie benutzt was aber nix heissen soll. Ich teste das hier auch mal auf einem Winblows und einem Linux Client...
Tip noch zum Script.
Debian konform geht das Starten und Stoppen des OVPN Server Prozesses eigentlich so: "systemctl start openvpn-server@server"
Wobei das "server" hinter openvpn-server@server immer den Namen der Server Konfig Datei ohne das .conf bezeichnet.
Analog dann im Client Mode openvpn-client@client
Du kannst m.E. das Skript auch noch vereinfachen indem du das explizite Starten und Stoppen einfach gegen ein restart nach dem Kopieren der CRL Datei ersetzt.
Also dann einfach systemctl restart openvpn-server@server
Man hat dann zwar die Gefahr eines sehr kurzen Deltas zwischen Kopieren und Restarten wo der Server ohne ist aber wenn nachts eh keiner da mehr werkelt ist das wohl egal... Start, kopieren, stop ist natürlich ablauftechnisch etwas korrekter. face-wink
KodaCH
KodaCH 15.04.2020 um 20:21:09 Uhr
Goto Top
Das ist eine alte Gewohnheit einen Dienst zu stoppen anstelle eines restarts face-smile
Den Dienststart werde ich noch so anpassen. Danke dir für deinen Input. Nehme neues immer gerne an.

Mit der Trennung spiele ich mal noch etwas und melde mich falls ich was finde. Wenn jemand noch Inputs hat nur her damit face-smile
KodaCH
KodaCH 16.04.2020 um 08:51:47 Uhr
Goto Top
Ich habe nun mal versucht den Service anzupassen. Einfach so zur Info falls mal jemand den selben Fehler erhält face-smile

Wenn man nach diversen Tutorials geht, funktioniert der Start nur über
systemctl restart openvpn@server.service

Der Grund ist einfach. Der "parameter" nach openVPN gibt wohl den Ordner für die server.conf an.

Wenn ich also die server.conf von /etc/openvpn nach /etc/openvpn/server verschiebe, kann der Server mittels
systemctl restart openvpn-server@server.service
gestartet werden.

Ich habe dies nun so angepasst, da ich die Übersicht der Dateien so angenehmer finde.

Gruss

Koda
aqui
aqui 25.04.2020 aktualisiert um 09:43:33 Uhr
Goto Top
Ist auch richtig so und der Sinn der Sache !
Alle Server Konfigs sollen ja in /etc/openvpn/server liegen und alle Client Konfigs in /etc/openvpn/client damit alles schön seine Ordnung hat und übersichtlich ist ! face-wink