WireGuard is an open-source VPN protocol implementation which is quickly gaining its popularity due to its speed, ease-of-use and well-designed codebase. This tutorial focuses on setting up WireGuard VPN client with NetworkManager GUI.
— Direct link
WireGuard is an open-source VPN protocol implementation which is quickly gaining its popularity due to its speed, ease-of-use and well-designed codebase. This tutorial focuses on setting up WireGuard VPN client with NetworkManager GUI.
At work I have to use a VPN connection. Currently there is set up a (so called) SSH jump-host, that only accepts connections from outside the internal/VPN network.
Problem with that: If the VPN connection is up it’s not possible to SSH to the jump-host anymore, because my local machine (with the VPN connection) has an internal IP address and is not allowed to connect to the jump-host.
I created a udev rule for the VPN interface tun0
.
That rules worke like this: Create a new route (to the jump-host) over my default network interface if the VPN connection is up and delete that rule if tun0
wents down.
And here are this udev rules for you – and myself … 🙂
root
(you can freely name the file as you want): /etc/udev/rules.d/99-tun0.rules
2.2.2.2
with the jump-host IP1.1.1.1
your local gateway IPdefault_interface
with your local/default network interface (for me it’s wlp2s0
; you can use ip addr
to see all interfaces)root
) the udev service: systemctl status udev
KERNEL=="tun0", ACTION=="add", RUN+="/sbin/ip route add 2.2.2.2 via 1.1.1.1 dev default_interface"
KERNEL=="tun0", ACTION=="remove", RUN+="/sbin/ip route delete 2.2.2.2 via 1.1.1.1 dev default_interface"
Thanks (for hints and inspiration) to
Seit gut zwei Jahren habe (nicht nur) ich große Schwierigkeiten bei der Benutzung des WLAN/VPN der Fachhochschule Potsdam unter Linux (Kubuntu & Ubuntu).
Zuerst lag es daran, dass die Installation des – seit einigen Jahren nicht mehr offiziell von Cisco Systems (weiter-)entwickelten – VPN-Clients recht problematisch war. Dies scheint glücklicherweise nun seit geraumer Zeit (auch für Nicht-Geeks) gelöst zu sein. Wie im Wiki des StuRa FB5 dokumentiert, pflege ich z.Z. ein git repository in das ich (für neue Kernelversionen) notwendige Änderungen für den (großartigen!) VPN-Client von tuxx-home.at einpflege. Somit habe ich pers. immer einen laufenden vpnclient und kann diesen auch noch anderen Usern zur Verfügung stellen.
Im letzten Semester nahmen die Probleme jedoch (subjektiv) zu. – Ständig brach die VPN-Verbindung zusammen und dann kam es teilweise zur Nichterreichbarkeit des VPN-Servers. Der Clou jedoch bestand darin, dass nach drei Reconnects der VPN-Zugang mit meinen Logindaten für eine geraume Zeit (ca. 20 Minuten) überhaupt nicht mehr möglich war…
Letzte Woche war ich dann wiedermal kurz vor dem Verzweifeln, weil selbst an Positionen, die bisher recht stabile VPN-Verbindungen zuließen, obige Probleme auftraten. Nach etwas Recherche musste ich dann jedoch feststellen, dass wohl gar nicht der VPN-Client schuldig ist/war, sondern der NetworkManager (unter Ubuntu).
In (fast) minütlichen Abständen fand ich folgende Meldung in den System-Logdateien:
Feb 25 16:16:47 axolotl NetworkManager[749]:
Feb 25 16:16:59 axolotl NetworkManager[749]:
Somit war also nicht die VPN-Verbindung durch Probleme in dem vpnclient wackelig, sonder die VPN-Verbindung brach ständig zusammen, weil die WLAN-Verbindung immer wieder neu (und manchmal auch mit einem neuen/weiteren AccessPoint) hergestellt wurde.
Gründe:
Für obige Instabilität habe ich einen (offiziellen Ubuntu) Fehlerbericht gefunden → https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/291760. Allerdings findet sich in den 123 Kommentaren leider keine eindeutige Begründung und auch keine Lösung.
Lösungsversuch:
Ich habe mich für Schritt 1 und 2 entschieden und werde diese Woche mal ausprobieren, ob es etwas geholfen hat.
Auf Grund der Tatsache, dass an der FH Potsdam für das VPN – ohne dieses funktioniert der Zugang ins Internet (leider) nicht – Hardware der Firma Cisco Systems benutzt wird und die Verbindung/Verschlüsselung (IPsec) nur über TCP funktioniert, sind die NutzerInnen auf die Verwendung des “Cisco Systems VPN Client” angewiesen. (Der “AnnyConnect” von Cisco kann kein IPsec und alle alternativen Clients können kein IPsec über TCP, sondern ’nur’ über UDP… *damn*)
Tja und den “Cisco Systems VPN Client” gibt es leider nicht für 64-bitige Betriebssysteme (BS). – ‘Nichteinmal’ für Windoofs 7!
Und so bekommt man dann bei unserer DV-Abteilung beispielsweise die freundliche Auskunft, dass man sich doch ein unterstütztes BS besorgen und parallel/alternativ installieren ’soll’. *tzzz*
Aber heute habe ich beim Stöbern folgende Aussage eines Cisco-Angestellten in den Cisco-Foren gefunden:
The VPN Client is supported on 32-bit systems. A 64-bit IPSec VPN cleint is also being worked on for sometime this year.
AnyConnect SSL VPN has aways supported 32-bit and 64-bit systems. The next generation version of the AnyConnect being worked on will also include IPsec component (using IKE-V2).
Somit steigt die Spannung bzgl. der Zeitangabe “sometime”, der Weiterentwicklung von “AnnyConnect” und deren Einflüsse auf den Linux-Client (der offiziell keinen ‘aktuelleren’ Kernel, als einen 2.4.18 unterstützt).
Glücklicherweise gibt es auf tuxx-home.at immernoch eine Version des Cisco VPN Clients, die halbwegs aktuell ist und mit Kerneln der Version 2.6.x funktioniert. Glücklicherweise deshalb, weil es (nämlich) nicht allen VPN-Benutzern möglich ist auf vpnc umzusteigen – bspw. denen, deren VPN-Gegenstelle den VPN-Zugang mittels IPSec over TCP betreibt.
Da das Projekt allerdings eine one-man-show ist und die Kommunikation der community nur über ein registrierungspflichtiges Forum läuft, habe ich die aktuellste Version (4.8.02.0030) mal auf github gepackt: http://github.com/sokai/vpnclient.
Außerdem gibt es dort unter http://github.com/sokai/vpnclient/tree/2.6.31 einen branch, in den die aktuellen Patches für den Kernel 2.6.31 (zu finden im oben erwähnten Forum) eingespielt wurden.
Ich werde versuchen das git-Repo aktuell zu halten. Dies wird mir sicher auch eine Weile gelingen, da ich den vpnclient für das Netz der FH Potsdam benötige.
Wer also Lust und Laune hat, kann seine Verion von obigen URLs runterladen oder einen Fork des Projekts/Branche auf github machen und seine Änderungen/Verbesserungen machen. Ich bin dann gern bereit diese unter Kubuntu zu testen und ggf. in den Master einfließen zu lassen.
sofar|sogood|sokai
zur Verfügung gestellte Programm vpnclient krankt momentan etwas daran, dass die