Hi.
Hier kommt die Lösung zu einem echten Luxus-Problem:
Bisher habe ich meine OpenVPN-Verbindung zum IPFire immer per Konsole aufgebaut. Nachteil: Man musste dazu root sein und es war immer etwas Tipparbeit notwendig
Nun habe ich mir nochmal unter KDE/Plasma bzw Kubuntu 17.04 den Network-Manager angesehen und siehe da: Endlich hat es ganz einfach geklappt, die OpenVPN-Verbindung per NetworkManager aufzubauen!
Dennoch waren zuvor 2-3 Schritte notwendig, die ich hier kurz aufschreibe, damit sie nicht verloren gehen:
1.) User zur Gruppe netdev hinzufuegen, damit auch als User das Device tun0 erzeugt werden darf:
sudo usermod -a -G netdev <username>
id <username> (zeigt dann die Mitgliedschaft in der Gruppe an)
2.) Fehlendes Paket für den Network-Manager installieren (für GNOME gibt es offenbar ein anderes Paket??)
sudo apt-get install network-manager-openvpn
3.) Im Netzwerkmanager eine neue Verbindung erstellen:
(+) drücken
--> ganz unten: VPN -Verbindung importieren ...
--> .ovpn-Datei vom IPFire auswählen
--> OpenVPN-Passwort wenn gewünscht eingeben und abspeichern lassen
--> Erweitert --> [X] Virtuellen Gerätetyp erstellen: TUN wählen (falls nicht automatisch aktiv)
Die Verbindung ist jetzt erstellt und müsste per Knopfdruck aktivierbar/deaktivierbar sein!
Zusatz:
Im Moment wird bei aktivierter Verbindung noch nicht alles durch den Tunnel geroutet. Ich kann daher im Moment zwar bequem auf den Server und das Netzwerk 10.16.1.0/12 aber sonst kann ich keine Verbindung “nach draußen” aufbauen. Das Problem hatte ich irgendwann schon mal und es liegt vermutlich an den Routen, die man dort aber auch noch einstellen kann.
wenn du im Netzwerkmanager in deinem VPN Profil mal unter den Punkt iv4 schaust gibt es hier den Punkt Roten.
In der Regel sollte hier der Punkt “Diese Verbindung nur für Ressourcen dieses Netzwerks verwenden” gesetzt sein.
Ansonsten baut der Netzwerkmanager dir eine Route welche deinen gesamten Traffic über die VPN Verbindung leitet. Dies ist gewollt falls man sich an einem offenen Hotspot einwählt, setzt aber voraus, dass die Gegenseite auch den Traffic ins Internet routet.
Ja, gesehen und ausprobiert hatte ich diesen Punkt auch schon … doch wenn das gesetzt ist, ist es hier so, dass dann zwar die Verbindung ins Internet klappt, doch dafür keine Verbindung mehr zum Netzwerk 10.16.1.0/12 zustande kommt (auch kein PING). Da fehlt also offenbar noch ein weiterer Eintrag…
lass dir mal deinen Routing Table nach dem Verbinden ausgeben (Haken gesetzt). Da sollte eigentlich eine Route für das entsprechende 10.16er Netz über das tun Interface auftauchen.
Und zuletzt noch, wenn ich es herkömmlich über die Konsole mache (hier ist alles richtig!)
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 100 0 0 enp0s25
10.16.1.0 172.16.18.21 255.255.255.0 UG 0 0 0 tun0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s25
172.16.17.0 172.16.18.21 255.255.255.0 UG 0 0 0 tun0
172.16.18.1 172.16.18.21 255.255.255.255 UGH 0 0 0 tun0
172.16.18.21 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.178.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s25
Da fehlt offenbar was?! Die Verbindung via Terminal funktioniert jedoch.
Übrigens kann ich als User weithin den Konsolen-Befehl trotz Mitgliedschaft in der Gruppe netdev nicht aufbauen. Scheinbar will das OpenVPN auf der Konsole noch andere Rechte als der NetworkManager?! Perfekt läuft es also leider noch nicht. Evtl kann man die fehlenden Routen aber noch manuell hinzufügen…
in dem Fenster nach Routen… machst du das Häckchen bei “Diese Verbindung nur für Ressourcen dieses Netzwerks verwenden” UND trägst eine Route in der Liste darüber ein.
Bei mir sieht das so aus.
Bei dir müsste als Gateway 172.16.18.21 stehen. Die Route auf 10.16.0.0 reicht. Die andere Route ist historisch
Als zusätzlichen DNS-Server habe ich 10.16.1.254 eingetragen. Damit funktioniert bei mir alles wunderbar mit einem Klick.
Achso: ich verwende das Standard-Ubuntu und Ubuntu-Gnome.
Ja, das funktioniert. Sehr gut!
Woher hast du bei dir den Eintrag unter Metrik?
Wikipedia meint dazu:
“Die Metrik spielt erst dann eine Rolle, wenn mehrere über dasselbe Routing-Protokoll gelernte Routen für dasselbe Zielnetz existieren; in diesem Fall ist die beste Route die mit dem kleinsten Metrik-Wert. Bei mehreren Routen mit identischem Metrik-Wert erfolgt in der Regel eine Verteilung von IP-Verbindungen über die gleichwertigen Routen (“Session-by-Session-Loadbalancing”)…”
Von daher müsste da ja eine möglichst kleine Zahl auftauchen?
