[gelöst] VPN Einrichtung mit *.ovpn Dateien ?

[lespaul]

Hallo,

ich habe eine *.ovpn Datei bekommen, diese besteht aus Klartext
+ <key> // 1. private key
+ <cert> // 2. certificate
+ <ca> // 3. certificate
+ <tls-auth>
+--> 2048 bit OpenVPN static key Anteil // 4.

Kommilitonen von mir benutzen ihre *.ovpn Dateien mit dem Programm tunnelblick auf ihren MACs. Ich habe Debian und weiß nicht wie ich diese Dateien einbinden kann?

Ich könnte unter diese *.opnv Datei in 3/4 Dateien zerstückeln und dann
Netzwerkeinstellungen --> Kabelgebunden --> Optionen --> 803.1x Sicherheit --> Legitimierung TLS
Benutzerzertifikat <== 2. von oben
CA-Zert <== 3.
Geheimer Schlüssel <== 1.
Passwort des geheimen Schlüssels <== 4.

Weiterhin müsste ich irgendwo angeben: remote openvpn.myserver.com 1234 udp ?

--------------
Gehe ich jedoch in die Netzwerkeinstellungen und füge mit "+" ein neues hinzu, kann ich die Schnittstelle für einen neuen Dienst auswählen: hier VPN
Jedoch kommt dann : fehler beim Erstellen der Verbindung --> Es sind keine VPN Plugins installiert

[DeletedUserReAsG]

fehler beim Erstellen der Verbindung --> Es sind keine VPN Plugins installiert

Wenn du nun noch verraten würdest, welches Programm diesen Fehler wirft, könnte man auch schauen, ob und wie sich die geforderten Plugins installieren ließen.

[lespaul]

Netzwerkeinstellungen heißt es. War Standardmäßig mit dabei.

[TRex]

GUIs sind manchmal sehr anstrengend. Auf der Konsole geht das so:

Code: Alles auswählen

# openvpn foobar.ovpn

Und dann ist die Verbindung im Optimalfall aufgebaut.

Du kannst die Dinger auch mit systemd steuern, allerdings fehlt mir da selbst noch das Feintuning. Die Unit heißt dann openvpn@foobar.service.

[DeletedUserReAsG]

War Standardmäßig mit dabei.

Bei mir nicht, wahrscheinlich bei vielen anderen auch nicht. Das ist der Grund, warum man grundlegende Systemdaten angeben sollte: damit Leute wissen, worum’s überhaupt geht.

[TomL]

Das Programm heisst OpenVPN... und das musst Du installieren, wenn es noch nicht installiert ist. Bedauerlicherweise hat das Debian-Repo nur die Version 2.3.4 . Die aktuelle Version ist die 2.3.12. Wenn Du das kannst, würde ich die empfehlen.... runterladen und selber kompilieren, ansonsten installierst Du die aus dem Repo via "apt-get install".

Die von dir gelisteten Dateien sind für den Zugriff auf den entfernten Server erforderlich, die Dein PC als Client zur Authentifizierung bzw. Identifizierung benötigt. Das sind quasi die Eintrittskarten für die Tür des Servers, ein Zertifikat zur Identifikation, eine Schlüsseldatei für den verschlüsselten Traffic. Das MAC-Programm ist auch nur ein OpenVPN-Client, du kannst aber dafür eben direkt das originale OpenVPN nutzen.

Ich würde Dir folgende Schritte nach dem Install empfehlen.
1. Unbedingt den automatisch eingerichteten Start des Dienstes bei Systemstart als Daemon deaktivieren. Du willst ja keinen Server installieren und benötigst den Dienst vermutlich auch nur temporär.
2. Entscheiden, ob Du den temporären VPN-Connect in einem permanenten Terminal (für die Dauer der Sitzung) herstellen möchtest, oder als "unsichtbaren" Dienst. Beides geht, beides ist gleich gut.

Wenn Du den Connect als "unsichtbaren" Dienst installieren möchtest, verwendest Du eine Service-Unit. Ich habe hier eine Beispiel-Unit für TCP und Port 443. Du wirst vermutlich UDP und den Port 1194 nutzen..... das muss dann eben angepasst werden.

Code: Alles auswählen

[Unit]
Description=thlu:openvpn.service   OpenVPN Client TCP/443

[Service]
Type=forking
PIDFile=/var/run/openvpn/client_tcp_443.pid
ExecStartPre=/bin/mkdir -p /var/run/openvpn
ExecStart=/usr/local/sbin/openvpn --daemon --writepid /var/run/openvpn/client_tcp_443.pid --status /var/run/openvpn/client_tcp_443.status 60 --cd /home/thomas/.keys/openvpn --config /home/thomas/.keys/openvpn/client_tcp_443.conf
KillMode=process

[Install]
WantedBy=multi-user.target

Du startest die Verbindung mit

Code: Alles auswählen

 systemctl start openvpn_client_tcp_443;sleep 3;systemctl status openvpn_client_tcp_443

und stoppst sie am Ende mit

Code: Alles auswählen

systemctl stop openvpn_client_tcp_443;sleep 3;systemctl status openvpn_client_tcp_443

Wenn Du die Verbindung allerdings in einem permanenten Terminalfenster starten möchtest, dann mit diesem Aufruf:

Code: Alles auswählen

openvpn  --config "/home/thomas/.keys/openvpn/client_tcp_443.conf"

Die Besonderheit hier ist, dass ich in meiner Conf eine Logfile-Vorgabe gemacht habe. Und zwar:

Code: Alles auswählen

log-append /run/openvpn/client_tcp_443.log

In der Service-Unit wird dafür das entsprechende Verzeichnis vorbereitet. Für den Start im Terminal muss das deaktiviert werden. Ebenso benötigt man direkt im Terminal kein Pid-File und keinen Laufzeit-Status... man sieht ja alles direkt im Terminal. Wenn du es also direkt im Terminal startest, sollte Log-Ausgabe nicht in eine Datei umgeleitet werden, sondern direkt im Terminal erscheinen. Dazu muss dann in der conf der Log-Eintrag deaktiviert werden.

Die Client-OpenVPN-Conf für den Zugriff muss du auf Deinem PC erstellen. In diese Conf trägst du die Server-Verbindung ein, vermutlich ein DynDNS-Name. Da steht drin, welches Protokoll und welchen Port du verwenden möchtest... hier in meinem Beispiel war das TCP und 443. Und es steht der Pfad zu den Zertifikaten und Schlüssel drin. In meinem Beispiel liegen die Files im Verzeichnis "/home/thomas/.key/openvpn". Bei mir ist da die Besonderheit, dass es USB-Stick-Files sind, die beim Einstecken des Sticks so gemountet werden. Aber die können überall liegen. Du musst die Pfade dann eben entsprechend anpassen. Ich würde nur darauf achten, dass ausser root niemand lese- und schreibrechte hat. Du startest die Verbindung sowieso als root, weil nur root ein virtuelles tun-NIC generieren darf.

Ein Hinweis noch.... das ganze Brimborium, was das openvpn-Deb-Package mit sich bringt, ist zwar da, aber alles nicht erforderlich. Insbesondere das, was unter /etc/openvpn oder /etc/init.d hinterlegt ist. Man brauch sowohl für den Server- als auch den Client-Betrieb NUR das openvpn-Binary. Auf einem Server wirds via systemd gestartet, auf dem Client kann man sich das aussuchen. Die Pfade wo was hinterlegt wird, sind frei wählbar, ebenso die Dateinamen für die Conf-Datei. Du musst das eben nur auf Deine Wünsche anpassen. Mein von mir vorgegebener Pfad für die benötigten Files ist

Code: Alles auswählen

/home/thomas/.keys

Und dort liegt eben die Dateien

Code: Alles auswählen

openvpn/client_tcp_443.conf
openvpn/client_udp_1194.conf

sowie die Zertifikate und das Keyfile

Wenn Du noch spezielle fragen hast... dann raus damit .....

[lespaul]

Auf der Konsole geht das so:

Code: Alles auswählen

# openvpn foobar.ovpn

Und dann ist die Verbindung im Optimalfall aufgebaut.

Danke!

Als letzte Zeile kommt bei mir:

Wed Oct 5 09:12:59 2016 Initialization Sequence Completed

Jedoch kann ich die Seite nicht aufrufen: "Der Server unter vpn.service konnte nicht gefunden werden."

War openvpn noch nicht ganz durchgelaufen? Woran sehe ich dass ich eine VPN benutze? Icon oder sowas?

[TRex]

Ich musste meine Config etwas anpassen. Schau mal nach deinen Nameservern und nach etwaigen Fehlern in der Ausgabe dazu. In meinem Fall kümmert sich resolvconf um die DNS-Konfiguration. Schau mal, ob diese Zeilen bei dir vorkommen:

Code: Alles auswählen

script-security 2

[... die restliche config ...]

up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Die hab ich in der ursprünglichen Datei nicht gefunden und sind beim Windowsclient auch nicht notwendig. Die erste Zeile (die muss AFAIK am Anfang stehen) erlaubt die Funktion der up/down Hooks, die beiden unten rufen ein von openvpn mitgeliefertes Script auf, welches dann wiederum resolvconf instruiert, die Nameserver des VPN zu setzen. Genaueres dazu findest du in man openvpn.

Ansonsten: nach der "initialization complete" Zeile bist du drin. Kannst es ja mal mit ner bekannten IP-Adresse versuchen

Trennen kannst du mit ctrl-c.

[lespaul]

Schau mal, ob diese Zeilen bei dir vorkommen:

Code: Alles auswählen

script-security 2
[... die restliche config ...]
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

In der ovpn Datei kommen sie nicht vor.

Weiterhin sagte ein Kollege, dass u.a. DNS settings (in der tunnelblick software) auf ignore gesetzt sein sollte und Caches entsprechend geflusht:

[TRex]

Ich versteh nichts von Macs, der Vergleich hilft mir entsprechend nicht.

Was ich dir raten kann: füg die drei Zeilen hinzu, installier resolvconf und probiers damit. Wenns dann nicht funktioniert, kannst du auch gern nochmal mit Apfelkollegen sinnieren.

[lespaul]

Was ich dir raten kann: füg die drei Zeilen hinzu, installier resolvconf und probiers damit

Options error: --up script fails with '/etc/openvpn/update-resolv-conf': No such file or directory
Options error: Please correct this error.

Den Ordner /etc/openvpn gibt es nicht, weil ich vermutlich manuell die von Tom empfohlene Version 2.3.12 installiert habe?

[TRex]

Gut möglich Was nicht heißt, dass es da nicht enthalten ist... musst du aber selbst nachschauen, was im tarball war. Gehört vielleicht zum "Brimborium".

Ein Hinweis noch.... das ganze Brimborium, was das openvpn-Deb-Package mit sich bringt, ist zwar da, aber alles nicht erforderlich. Insbesondere das, was unter /etc/openvpn oder /etc/init.d hinterlegt ist.

[lespaul]

@TRex Thanks. Schien am Brimborium zu liegen. Habe das Debianpaket wieder isntalliert, klappt

[TomL]

Ja, klar, das liegt natürlich am Brimborium .... .... das ist im reinen Source-Code-Paket von openvpn natürlich nicht dabei. Wenn man openvpn selber kompiliert, gibts natürlich auch kein Verzeichnis /etc/openvpn. Aber wie gesagt, das ist auch völlig unnötig.

Man lädt sich das Script einfach von Github [1] runter und kopiert es sich an eine beliebige Stelle auf der Platte. Bevorzugt natürlich

• /usr/local/bin

oder auch dorthin, wo das selbstkompilierte openvpn-binary liegt, und zwar

• /usr/local/sbin.

Abschließend die W-Rechte auf das Script unbedingt nur Root vergeben. Dann fügt man die notwendigen und von TRex genannten Zeilen in die Conf ein und fertig... das wars. Man muss natürlich auch hier wieder die Verzeichnisse anpassen... /etc/openvpn geht natürlich nicht... *fg*

[1] https://github.com/jonathanio/update-systemd-resolved

Nachtrag:
Sorry... ein wichtiger Hinweis fehlt noch.... ich nutze natürlich systemd... insbesondere natürlich auch systemd-networkd und systemd-resolved. Eigentlich das, was derzeit aktuell ist. Mit dem herkömmlichen /etc/init.d/networking, der /etc/interfaces und dem alten resolve beschäftige ich mich nicht mehr. Insofern kann es da natürlich noch zu Schwierigkeiten kommen, wenn man das alte Zeugs nutzen möchte. Möglicherweise kanns deshalb auch besser sein, doch die Version aus dem Repo mit Brimborium zu nutzen.... wenn das gut läuft, ist doch alles bestens.... jm2c

[TRex]

TomL: prinzipiell find ich das Setup auch interessant, würde aber doch bei debian-Paketen bleiben (zwecks Updates und "Frickel-Minimierung"). Wenn du dein Setup mit sid oder arch linux oder sonstigen Distris aufbaust, ist das IMHO was anderes, aber man muss sich eben bewusst sein, was man da tut und welche Effekte es hat. Ich hab bei sowas immer Probleme, das reinen Gewissens jemand anderem zu empfehlen, der da nicht selbst drauf gekommen ist. systemd-* Pakete warte ich ab, bis sie in debian aufschlagen.

[TomL]

prinzipiell find ich das Setup auch interessant, würde aber doch bei debian-Paketen bleiben (zwecks Updates und "Frickel-Minimierung"). Wenn du dein Setup mit sid oder arch linux oder sonstigen Distris aufbaust, ist das IMHO was anderes, aber man muss sich eben bewusst sein, was man da tut und welche Effekte es hat. Ich hab bei sowas immer Probleme, das reinen Gewissens jemand anderem zu empfehlen, der da nicht selbst drauf gekommen ist. systemd-* Pakete warte ich ab, bis sie in debian aufschlagen.

Einspruch Euer Ehren ... ... ich halte das in mehrfacher Hinsicht für einen Trugschluss. Hinsichtlich des Updates halte ich OpenVPN für eines der Pakete, die meines Erachtens ähnlich wie SSL oder der Firefox zwingend in aktueller Version genutzt werden sollten. Ganz nebenbei bemerkt, ist es aus Sicht der "Frickelei" und der Notwendigkeit, dass es hinterher funktionieren muss, sowieso völlig unerheblich, welche Version ich mit welchem Setup verwende. Beide Versionen laufen in beiden Setups. Im einfachsten Fall move ich das Repo-OpenVPN-Binary nach *.old und mach an der gleichen Stelle nen Symlink auf das aktuelle Binary in /usr/local/sbin. Damit läuft das alte Setup sofort mit aktueller OpenVPN-Version.

Als zweites halte ich den Frickelaufwand im alten Setup für deutlich aufwendiger im Vergleich zum neuen Setup mit selbst kompilierter Version und systemd-services. Wenn ich nur mal den Umfang auf Dateiebene vergleiche, sieht man schon, was deutlich aufwendiger zu überschauen ist. Die erste Version ist nach apt-get install openvpn, die zweite Variante mit aktueller Version ist von meinem Laptop.

Code: Alles auswählen

# ff *openvpn*
/var/lib/dpkg/info/openvpn.prerm
/var/lib/dpkg/info/openvpn.md5sums
/var/lib/dpkg/info/openvpn.postrm
/var/lib/dpkg/info/openvpn.shlibs
/var/lib/dpkg/info/openvpn.conffiles
/var/lib/dpkg/info/openvpn.config
/var/lib/dpkg/info/openvpn.postinst
/var/lib/dpkg/info/openvpn.list
/var/lib/dpkg/info/openvpn.templates
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/openvpn.service
/var/lib/systemd/deb-systemd-helper-enabled/openvpn.service.dsh-also
/var/cache/apt/archives/openvpn_2.3.4-5+deb8u1_amd64.deb
/run/openvpn
/run/systemd/generator/openvpn.service.wants
/etc/rc4.d/S02openvpn
/etc/bash_completion.d/openvpn
/etc/rc2.d/S02openvpn
/etc/rc5.d/S02openvpn
/etc/default/openvpn
/etc/init.d/openvpn
/etc/rc6.d/K01openvpn
/etc/systemd/system/multi-user.target.wants/openvpn.service
/etc/rc1.d/K01openvpn
/etc/rc3.d/S02openvpn
/etc/rc0.d/K01openvpn
/etc/network/if-down.d/openvpn
/etc/network/if-up.d/openvpn
/etc/openvpn
/etc/openvpn/openvpn_client_tcp_443.ovpn
/usr/sbin/openvpn
/usr/local/sbin/openvpn
/usr/local/share/doc/openvpn
/usr/local/share/Icons/openvpn.jpg
/usr/local/lib/openvpn
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.la
/usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so
/usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.la
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so
/usr/local/include/openvpn-plugin.h
/usr/share/man/man8/openvpn.8.gz
/usr/share/doc/openvpn
/usr/share/doc/openvpn/examples/sample-config-files/openvpn-shutdown.sh
/usr/share/doc/openvpn/examples/sample-config-files/openvpn-startup.sh
/usr/share/openvpn
/usr/lib/tmpfiles.d/openvpn.conf
/usr/lib/openvpn
/usr/lib/openvpn/openvpn-plugin-auth-pam.so
/usr/lib/openvpn/openvpn-plugin-down-root.so
/usr/include/openvpn
/usr/include/openvpn/openvpn-plugin.h
/lib/systemd/system-generators/openvpn-generator
/lib/systemd/system/openvpn@.service
/lib/systemd/system/openvpn.service

Code: Alles auswählen

 ff *openvpn*
/var/lib/dpkg/info/openvpn.list
/var/lib/dpkg/info/openvpn.conffiles
/var/lib/dpkg/info/openvpn.md5sums
/home/thomas/.keys/openvpn/openvpn_client_tcp_443.ovpn
/usr/local/lib/openvpn
/usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.la
/usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.la
/usr/local/include/openvpn-plugin.h
/usr/local/share/Icons/openvpn.jpg
/usr/local/share/man/man8/openvpn.8.gz
/usr/local/share/doc/openvpn
/usr/local/sbin/openvpn
/usr/share/doc/openvpn
/usr/share/doc/openvpn/doc/openvpn.8

Und als letztes möchte ich bemerken, dass systemd in vollem Umfang (mit deinen Worten) in Debian aufgeschlagen ist. Das bedeutet für mich, statt erstmal dafür zu sorgen, dass das Programm mit update-rc.d überhaupt gestartet wird oder nach dem install vertrauensvoll davon auszugehen, dass die runlevels das konfliktfrei so tun, wie ich das gerne hätte (nämlich gar nicht), um dann eine unverständliche Einstellung für den Systemstart in /etc/default/openvpn vorzunehmen, von der ich wissen muss, dass ich sie vornehmen muss, damit er überhaupt weiss, welche Conf und wie viele er starten soll..... starte ich einfach das Binary bei Bedarf mit einer Service-Unit. Und kann dann für mich feststelleen, dass es damit sehr überschaubar und unaufwendig customized ist. Ich nutze Openvpn nur unterwegs mit meinem Notbebook, auf Reisen, aber nicht permanent, sondern bei Bedarf temporär manuell gestartet oder wieder beendet. Ein Überlegung durch das Startsystem oder erst mal Prüfen von diversen Einstellungen, ob da was gestartet werden soll, will ich gar nicht. Auch da glaube ich, dass es mir mein Setup mit den Alternativen da einfacher macht....... *hmmm*... mag sein, dass ich das alte Setup jetzt ungünstiger hingestellt habe, als es in Wirklichkeit ist, aber...

...wie gesagt, ich bin der festen Überzeugung, dass es richtig ist, gerade solche Dienste mit systemd-services zu starten. Das ist genau der Weg, um endlich von der Frickelei wegzukommen. Ganz neben beibemerkt.... vor dem Hintergrund, dass systemd derzeit "Default" ist, ist es sowieso meine Überzeugung, keine Gelegenheit auszulassen, die alten sysvinit-Setups rigoros über Board zu werfen und keinen Gedanken mehr daran zu verschwenden.

Aber ganz am Ende zählt natürlich nur eines... Recht hat der, der es ans Laufen gebracht hat. Und wenn es klappt, ist das alte Setup über die Runlevels mit einer alten Version (vielleicht) genauso gut, wie ein neues Setup mit aktueller Version und Nutzung von systemd-services.

J.m.2.c.

[TRex]

Und als letztes möchte ich bemerken, dass systemd in vollem Umfang (mit deinen Worten) in Debian aufgeschlagen ist.

Dann war ich beim letzten Mal suchen wohl einfach nur blind. Wie ich bereits geschrieben hatte, verwende ich systemd zum starten/stoppen meines VPNs, die anderen Dienste nur eben nicht, weil das im Auslieferungszustand nicht der Standard zu sein scheint. Und wenn hier jemand aufschlägt und eine Frage stellt, die von der Komplexität her aussieht wie "wie mach ich eine Konfigurationsdatei mit dem Programm X auf", dann werd ich demjenigen garantiert nicht ein selbst zu wartendes binary an den Hals binden (bei Sicherheitsupdates - woher kriegt derjenige die denn überhaupt mit?).

um dann eine unverständliche Einstellung für den Systemstart in /etc/default/openvpn vorzunehmen,

Das ist nur eine ziemlich bescheuerte Konvention, mit dem "ENABLE=1"... init-files konnte man ebenso deaktivieren.

[TomL]

Wie ich bereits geschrieben hatte, verwende ich systemd zum starten/stoppen meines VPNs, die anderen Dienste nur eben nicht, weil das im Auslieferungszustand nicht der Standard zu sein scheint.

Welche andere Dienste meinst Du...?...es geht doch hier NUR ums VPN.... oder?

Und wenn hier jemand aufschlägt und eine Frage stellt, die von der Komplexität her aussieht wie "wie mach ich eine Konfigurationsdatei mit dem Programm X auf", dann werd ich demjenigen garantiert nicht ein selbst zu wartendes binary an den Hals binden (bei Sicherheitsupdates - woher kriegt derjenige die denn überhaupt mit?

Ich hatte -mehr oder weniger in einem Nebensatz- geschrieben: "Die aktuelle Version ist die 2.3.12. Wenn Du das kannst, würde ich die empfehlen.... runterladen und selber kompilieren, ansonsten installierst Du die aus dem Repo via "apt-get install". Das bedeutet für mich, ich habe ihm etwas zu entscheiden gegeben.... und wenn er das kann (was er ja sogar erfolgreich geschafft hat), ist ihm klar, dass das als manuell installiertes Paket nicht automatisch upgedatet wird. BTW, so wie ich das einschätze, bekommt OpenVPN sowieso keine Patches, speziell dieses Mini-Binary -das glaube ich- ist statisch. Aber sicher weiss ich das natürlich nicht. Nur deswegen setze ich auf die aktuelle Version von der eigenen Seite.

Das ist nur eine ziemlich bescheuerte Konvention, mit dem "ENABLE=1"... init-files konnte man ebenso deaktivieren.

Und woher weiss man das? Von selber findet man das doch gar nicht. Wenn man jedoch einmal das Prinzip systemd-service-unit verstanden hat, dann gibts solche Geheimnisse nicht mehr, dann läuft alles nach gleichem Schema ab. Ich will ganz sicher niemanden eine Empfehlung geben, die er nicht beherrschen kann, aber nach Möglichkeit vermeide ich auch in die Vergangenheit gerichtete Empfehlungen.

Na ja... ist auch nicht so wirklich wichtig......