Wie openVPN auf Client für "on demand" einrichten?

[dirk11]

Guten Morgen?

Ich glaube, ich muss meine openVPN-Installation auf meinem mobilen Laptop mal komplett neu einrichten.
Die Anforderungen:
Ich benötige eine VPN-Verbindung auf meinen Heimserver eher selten, deshalb "on demand". Es gibt zwei Varianten, die ich benötige:
1. Ich brauche nur Verbindung zu meinem Heim-LAN
2. Jeglicher Traffic soll über mein Heim-LAN geroutet werden.

"Früher", als es noch init.d war, habe ich openVPN auf dem Laptop installiert, den init.d-Starter deaktiviert und die Verbindung dann per /etc/init.d/openvpn start|stop|restart gehandhabt.
Das habe ich so schon sehr lange (mehrere Jahre) nicht mehr benutzt, aber es hat bis zuletzt funktioniert.
Das funktioniert jetzt mit systemctl start openvpn irgendwie nicht mehr. Es wird zwar behauptet, dass der Dienst läuft, ein status zeigt das auch an, aber ich kann meinen Heimserver nicht anpingen, sprich das Netz ist hier überhaupt nicht "up".

Da das alles, wie man sieht, ziemlich alt ist, möchte ich es komplett neu aufsetzen. Also, Bedarf:
- default-Status inaktiv
- openVPN-Verbindung auf Anforderung starten
- zwei Start-Möglichkeiten: nur Verbindung in's Heim-LAN oder komplette traffic-Durchleitung

Wie realisiere ich das?

[mat6937]

Es wird zwar behauptet, dass der Dienst läuft, ein status zeigt das auch an, aber ich kann meinen Heimserver nicht anpingen, sprich das Netz ist hier überhaupt nicht "up".

Wie sind die Ausgaben von:

Code: Alles auswählen

ip a
ip r
ip r g <IP-Adresse-Heimserver>
iptables -nvx -L -t nat

?

[MSfree]

Wie sind die Ausgaben von:

Code: Alles auswählen

ps augx | grep openvpn

[QT]

Ich würde sowas per se mit dem Network Manager machen und mir dort 2 Profile (nicht automatischer Start) anlegen mit 1) nur zum Heim LAN und 2) alles durch VPN routen und dann bei Bedarf das eine oder andere Profil aktivieren. Alle systemweiten Ansätze wären mMn und für mich nicht schick. Ich habe hier auch einige VPN Profile im Network Manager zu unterschiedlichen Zielen und starte sie bei Bedarf. Läuft 1a

[dirk11]

Wie sind die Ausgaben von:

Code: Alles auswählen

ip a
ip r
ip r g <IP-Adresse-Heimserver>
iptables -nvx -L -t nat

Code: Alles auswählen

ps augx | grep openvpn

Alles Ausgaben nach systemctl start openvpn - aber eigentlich sagt der letzte Befehl ps alles: der läuft überhaupt nicht? Verstehe ich nicht.

Code: Alles auswählen

# systemctl status openvpn
● openvpn.service - OpenVPN service
     Loaded: loaded (/lib/systemd/system/openvpn.service; enabled; preset: enabled)
     Active: active (exited) since Wed 2024-01-31 14:57:53 CET; 4min 18s ago
    Process: 973 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
   Main PID: 973 (code=exited, status=0/SUCCESS)
        CPU: 2ms

Jan 31 14:57:53 7210 systemd[1]: Starting openvpn.service - OpenVPN service...
Jan 31 14:57:53 7210 systemd[1]: Finished openvpn.service - OpenVPN service.

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 50:26:90:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    altname enp4s0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 04:f0:21:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    altname wlp20s0
    inet 192.40.71.217/19 brd 192.40.95.255 scope global dynamic noprefixroute wlan0
       valid_lft 3313sec preferred_lft 3313sec

# ip r
default via 192.40.64.1 dev wlan0 proto dhcp src 192.40.71.217 metric 600 
192.40.64.0/19 dev wlan0 proto kernel scope link src 192.40.71.217 metric 600 

# ip r g 192.168.1.10
192.168.1.10 via 192.40.64.1 dev wlan0 src 192.40.71.217 uid 0 
    cache 

# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.40.64.1      0.0.0.0         UG    600    0        0 wlan0
192.40.64.0      0.0.0.0         255.255.224.0   U     600    0        0 wlan0

# iptables -nvx -L -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 MASQUERADE  0    --  *      eth0    0.0.0.0/0            0.0.0.0/0           
       0        0 MASQUERADE  0    --  *      ppp+    0.0.0.0/0            0.0.0.0/0           
       0        0 MASQUERADE  0    --  *      ippp+   0.0.0.0/0            0.0.0.0/0           

# ps augx | grep openvpn
root        3287  0.0  0.0   7952  2124 pts/1    S+   15:04   0:00 /usr/bin/grep --color=auto openvpn

[MSfree]

aber eigentlich sagt der letzte Befehl ps alles: der läuft überhaupt nicht?

Code: Alles auswählen

ip a

sagt das indirekt auch schon. OpenVPN sollte ein tap oder ein tun Device (je nachdem ob bidged oder routed) erzeugen.

[mat6937]

Es wird zwar behauptet, dass der Dienst läuft, ein status zeigt das auch an, ...

Nein, "status" aus dem 1. Befehl sagt u. a. auch:

Code: Alles auswählen

Jan 31 14:57:53 7210 systemd[1]: Starting openvpn.service - OpenVPN service...
Jan 31 14:57:53 7210 systemd[1]: Finished openvpn.service - OpenVPN service.

[dirk11]

Ja, ihr habt Recht, hätte mir auch schon auffallen müssen. Aber: warum ist das so? Es gibt keinerlei Meldung irgendwo, weder im syslog noch sonstwo unter /var/log
Für mich sieht es so aus, als ob der gestartet und sofort wieder gestoppt wird.

[MSfree]

Es gibt keinerlei Meldung irgendwo, weder im syslog noch sonstwo unter /var/log

Es wird seit über 9 Jahren (Jessie) in ein Journal gelogt, das man mit journalctl abfragen muß. Die Journals stehen übrigens unter /var/log/journal

Code: Alles auswählen

journalctl | grep openvpn

Abgesehen davon sollte man den Verboselevel in der ovpn-Datei hochdrehen.

[dirk11]

Es gibt keinerlei Meldung irgendwo, weder im syslog noch sonstwo unter /var/log

Es wird seit über 9 Jahren (Jessie) in ein Journal gelogt, das man mit journalctl abfragen muß. Die Journals stehen übrigens unter /var/log/journal

Code: Alles auswählen

journalctl | grep openvpn

Danke! Das habe ich in der Tat noch nie gebraucht, bisher habe ich in syslog & Co alles gefunden, was ich brauchte.
Aber auch da steht nichts drin, die letzten Einträge sind von Juni (keine Jahresangabe). Wird Juni vor fünf Jahren oder so sein, das Gerät wurde sehr lange ausschließlich im LAN benutzt und openvpn war nicht notwendig.

Abgesehen davon sollte man den Verboselevel in der ovpn-Datei hochdrehen.

Mhmm. Der steht schon auf "3", geht es noch höher? Bzw. was hätten's denn gerne?

[mat6937]

Für mich sieht es so aus, als ob der gestartet und sofort wieder gestoppt wird.

Gibt es diese Dateien:

Code: Alles auswählen

ls -la /etc/default/openvpn
ls -la /etc/init.d/openvpn

(auch mit systemd) noch?

[MSfree]

Mit

Code: Alles auswählen

log /var/log/openvpn.log
verb 3

in der OpenVPN Konfiguration sollte in die Datei /var/log/openvpn.log gelogt werden.

[dirk11]

Ja, die Dateien gibt es und
ja, verb 3 steht schon in der conf. Es wird nur nichts ausgespuckt.

[mat6937]

Ja, die Dateien gibt es und

OK,dann poste dieAusgaben von:

Code: Alles auswählen

cat /etc/default/openvpn
systemctl cat openvpn.service

Siehe dazu auch den workaround aus dem UU-Wiki bzgl. der Probleme mit systemd: https://wiki.ubuntuusers.de/OpenVPN/#Pr ... it-systemd

[dirk11]

Ok, danke!

Das wird jetzt hier etwas "schleppend" voran gehen, weil ich gerade wenig Zeit habe. Also nicht wundern, wenn ich nicht so "gierig-zeitnah" reagiere wie sonst. Ich bleibe da aber dran, weil ich die Verbindung brauche.

Mir sind schonmal zwei Dinge aufgefallen: ich habe auf mein "mittelneues" Notebook gewechselt, dabei ist mir aufgefallen, dass ich vergessen habe, auf dem alten Notebook die Keys zu aktualisieren. Mein Fehler, wird nachgeholt (aber dafür muss ich erstmal wieder zu Hause sein).
Auf dem "mittelalten" Notebook, von welchem ich jetzt schreibe, ist die Konfiguration aber identisch, deshalb ist das Problem das Gleiche (trotz aktueller Keys).
Was mir schonmal auf-/eingefallen ist:
Ich habe damals per
# update-rc.d -f openvpn remove
den Autostart von openvpn auf den Laptops deaktiviert. Das init.d-Script ist aber selbstverständlich noch vorhanden - ich habe damals dann einfach via /etc/init.d/openvpn start das openvpn aufgerufen. So ähnlich, so dachte ich, mache ich es jetzt weiterhin unter systemctl.

Beim Start durch systemctl scheint es aber ein Problem zu sein, dass ich den VPN-Key noch mit der Eingabe eines Schlüssel gesichert habe, sprich bei Verbindungsaufbau muss ein Schlüssel eingegeben werden. Die Abfrage kommt nicht - sie kommt in der entsprechenden Kommandozeile erst viel später, meist kurioserweise beim stop.

Ich werde mir erstmal noch Deinen link zu Ubuntu durchlesen, denn dass sich bei openvpn was geändert hat mit Configs im Unterverzeichnis /client und /server ist vollkommen an mir vorbeigegangen. Der openvpn-Server zu Hause läuft wie früher, mit zwei Config-Dateien in /etc/openvpn (eine für TCP und eine für UDP, denn TCP läuft auf den Laptops besser, während UDP für die Handys genutzt wird). Die Unterverzeichnisse /server oder /client sind gar nicht in Verwendung.

Nochmal zu Erinnerung, was ich erzielen möchte: Aufbau der VPN-Verbindung nur auf Anforderung, sprich wenn ich das starte, dabei muss Berücksichtigung finden, dass ich bei Verbindungsaufbau einen Key eingeben muss.

Code: Alles auswählen

# cat /etc/default/openvpn
AUTOSTART="dp771-tcp"
OPTARGS=""
OMIT_SENDSIGS=0

und

Code: Alles auswählen

# systemctl cat openvpn.service
# /lib/systemd/system/openvpn.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

[Unit]
Description=OpenVPN service
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn

[Install]
WantedBy=multi-user.target

[debilian]

und was passiert, wenn du mittels

Code: Alles auswählen

openvpn --config configname.ovpn

auf dem clienten startest?

[mat6937]

Nochmal zu Erinnerung, was ich erzielen möchte: Aufbau der VPN-Verbindung nur auf Anforderung, sprich wenn ich das starte, ...

Code: Alles auswählen

# cat /etc/default/openvpn
AUTOSTART="dp771-tcp"
OPTARGS=""
OMIT_SENDSIGS=0

Wenn OpenVPN manuell gestartet werden soll, müsste

Code: Alles auswählen

AUTOSTART="none"

in der "/etc/default/openvpn" konfiguriert sein, oder?

[dirk11]

Ja, das war wohl damals schon ein Fehler meinerseits, ist mir auch schon aufgefallen. Ich werde das anpassen.

[MSfree]

Auf der Serverseite muß OpenVPN auf jeden Fall nicht mit "none" gestartet werden sondern entweder mit "all" oder dem Namen der Konfigurationsdatei.

Clientseitig ist es wahrscheinlich besser, das über den Networkmanager zu realisieren. On demand geht mit systemd nicht. Da müßetst du jedesmal, wenn Bedarf besteht, die Datei /etc/default/grub ändern. root-Rechte setzt das ebenfalls voraus.

Mit dem Networkmanager kann man die VPN-Verbindung in der GUI auswählen, ähnlich wie die Auswahl eines WLAN-Netzes.

[dirk11]

Wieso grub?
Ich wollte das "wie früher" machen, als ich einfach per root /etc/init.d/openvpn start gemacht habe und dann das Passwort für den Key. Das war für die wenigen Male, die ich das damals brauchte, funktional und simpel.

Network-Manager ist sicherlich die komfortabelste Idee, die hatte ich auch schon. Aber was muss ich dafür aktuell an Voraussetzungen schaffen? Muss ich den init.d-Starter wieder reaktivieren? Muss ich bestimmte Voraussetzungen bei den Config-Dateien schaffen? ich denke nicht, dass das mit meiner übernommenen/mitgeschleppten Umgebung funktionieren wird, die funktioniert ja schon so nicht...

[mat6937]

Wieso grub?
Ich wollte das "wie früher" machen, ...

BTW: Von Server war hier nie die Rede. Es war schon klar, dass Du den OpenVPN-Client, (bei Bedarf) manuell starten willst.
Das geht auch mit systemctl manuell, denn eine service-unit muss man nicht zwingend aktivieren (enabled) und kann nach dem booten auch manuell gestartet/ausgeführt werden. BTW: Wenn man dafür eine timer-unit (nur als Beispiel) benutzt ist es auch nicht anders, die service-unit ist dann auch deaktiviert (disabled).

[MSfree]

Wieso grub?

Im Hirn war openvpn, die Finger haben dann grub draus gemacht.

Network-Manager ist sicherlich die komfortabelste Idee, die hatte ich auch schon. Aber was muss ich dafür aktuell an Voraussetzungen schaffen? Muss ich den init.d-Starter wieder reaktivieren?

Wenn du nicht ausgerechnet Devuan benutzt, ist init.d irrelevant. Das geht heutzutage (fast) alles über systemd-units. Nur Software, die noch keine Units mitbringt und statt dessen init.d-Skripte, wird noch über die Kompatibilitätsschicht von systemd laufen gelassen.

Muss ich bestimmte Voraussetzungen bei den Config-Dateien schaffen?

Deine OpenVPN-Konfigurationen sollte direkt funktionieren.

ich denke nicht, dass das mit meiner übernommenen/mitgeschleppten Umgebung funktionieren wird, die funktioniert ja schon so nicht...

Das kann aber auch an der aktuellen Version von OpenVPN liegen, wenn deine Konfigurationen schon einige Jahre alt sind. Einige Verschlüsselungsmethoden wurden aus Sicherheitsgründen entfernt und die DH-Keys müssen länger sein als früher. Ich mußte auch schon den ganzen Klimbim mal neu generieren, weil eine neuere OpenVPN-Version sich geweigert hat, mit alten (nicht abgelaufenen) Schlüsseln zu arbeiten. Aber das steht dann eigentlich alles im Server-Log.

[dirk11]

Nein, das liegt schon an den Laptops/Clients. Ich habe im Zuge des Upgrade auf Bookworm auf meinem Heimserver alle VPN-Keys neu gemacht, weil die alten mittlerweile auch 10 Jahre alt waren und die ersten ungültig wurden. Serverseitig steht auch "all" in der default - wie gesagt, serverseitig war hier keine Rede von.
Von den Handys und dem Windows-Laptop in der Familie klappt der Zugriff, zur Zeit haken nur meine zwei Bookworm-Laptops.

Ich habe halt noch nicht verstanden, wieso die Key-Abfrage nicht beim openvpn-Start via systemctl kommt.

[MSfree]

Ich habe halt noch nicht verstanden, wieso die Key-Abfrage nicht beim openvpn-Start via systemctl kommt.

systemd ist nicht interaktiv, kann also nie etwas vom Benutzer abfragen.

[mat6937]

Ich habe halt noch nicht verstanden, wieso die Key-Abfrage nicht beim openvpn-Start via systemctl kommt.

Das wird nicht implementiert bzw. nicht so konfiguriert sein.
Möglich sollte das sein, mit z. B. systemd-ask-password:

systemd-ask-password may be used to query a system password or passphrase from the user, using a question
message specified on the command line. When run from a TTY it will query a password on the TTY and print it to
standard output. When run with no TTY or with --no-tty it will use the system-wide query mechanism, which
allows active users to respond via several agents, listed below.

The purpose of this tool is to query system-wide passwords -- that is passwords not attached to a specific user
account. Examples include: unlocking encrypted hard disks when they are plugged in or at boot, entering an SSL
certificate passphrase for web and VPN servers.

Quelle: manpage für systemd-ask-password