139689
28.02.2023, aktualisiert um 17:29:47 Uhr
1488
24
0
VPN Routing Eintrag auf Debian verschwindet
Hallo zusammen,
die Situation
ich nutze einen Wireguard VPN Tunnel, basierend auf "VeeamPN", das wiederum in einer Ubuntu VM ist. Die VM muss mal abgelöst werden, da Veeam das ja nicht mehr weiter entwickelt. Aber das VPN selbst geht.
Am Endgerät wird der OpenVPN client verwendet. Unter Windows kein Problem - einfach die .ovpn importieren. Manuell füge ich der Konfig dann noch einen Eintrag hinzu und es tut wunderbar seinen Zweck. Bei den 3 aktiven usern besteht das darin, sich einfach per RDP auf ein Gerät im Firmennetz zu verbinden.
Daheim möchte ich mehr und mehr auf GNU/Linux wechseln.
Hier habe ich einen PC mit LMDE (Linux Mint Debian Edition)
Wenn ich den Tunnel aufbaue (mittels der grafischen Anwendung eOVPN), ist dieser sofort aufgebaut
Dann setze ich via Terminal noch folgende Einträge ab:
Das sind 2 Netze (einmal für Server Netz für DSN Auflösung, einmal Client Netz, auf das man sich dann verbindet)
Die Ubuntu VM ist in einer DMZ und löst sie DNS Anfragen nicht auf, deshalb das Server Netz dazu
Das Problem
Das Problem ist, dass die Einträge irgendwann wieder verschieden am LMDE Client. Entweder erst nach vielen Stunden, teils aber auch nach einigen Minuten. Muster sehe ich noch keines. Die RDP Verbindung bricht natürlich ab
Sobald ich die beiden Einträge nochmal absetze, kann ich die RDP Verbindung sofort wieder aufbauen
wenn ich testweise den Befehl gleich nochmal absetze, kommt die Meldung:
... weil der Eintrag drin ist. Ich verstehe das also so, als ob nach gewisser Zeit der Eintrag / die Datei von RTNETLINK verschwindet
Wenn ich es als Administrator (also ohne sudo, sonder vorher halt auf su gewecheslt) ausführe, bricht es noch früher ab
Die Frage
Wieso verschwinden sie bzw. kann ich das irgendwie permanent hinterlegen?
10.101.30.0/24 und 10.101.10.0/24 können dauerhaft fix hinterlegt werden. Ich werde die nie anders nutzen...
ich habe mich schon mit Einträgen in der .ovpn Datei gespielt, aber so richtig hat das nur für Windows Clients funktioniert.
Für ein Ipad müsste ich auch noch was machen, aber da bin ich völlig Land unter, welche Optionen / Syntax nötig ist
Zusätzliche Info
Ich weiß, dass es geschickter wäre, das Server Netz nicht dazu zu nehmen, v.a. wenn es nur für die DNS Auflösung ist.
Bei einem user, der sich nur auf 1 PC verbindet, werde ich es so machen, dass nur das Client Netz geroutet wird und der PC halt eine fixe (reservierte) IP bekommt und man sich auf die IP verbindet...
Aber das ist das Apfelgerät....
Danke im Voraus!
die Situation
ich nutze einen Wireguard VPN Tunnel, basierend auf "VeeamPN", das wiederum in einer Ubuntu VM ist. Die VM muss mal abgelöst werden, da Veeam das ja nicht mehr weiter entwickelt. Aber das VPN selbst geht.
Am Endgerät wird der OpenVPN client verwendet. Unter Windows kein Problem - einfach die .ovpn importieren. Manuell füge ich der Konfig dann noch einen Eintrag hinzu und es tut wunderbar seinen Zweck. Bei den 3 aktiven usern besteht das darin, sich einfach per RDP auf ein Gerät im Firmennetz zu verbinden.
Daheim möchte ich mehr und mehr auf GNU/Linux wechseln.
Hier habe ich einen PC mit LMDE (Linux Mint Debian Edition)
Wenn ich den Tunnel aufbaue (mittels der grafischen Anwendung eOVPN), ist dieser sofort aufgebaut
Dann setze ich via Terminal noch folgende Einträge ab:
sudo ip route add 10.101.30.0/24 via 10.210.0.1 dev tun0
sudo ip route add 10.101.10.0/24 via 10.210.0.1 dev tun0Das sind 2 Netze (einmal für Server Netz für DSN Auflösung, einmal Client Netz, auf das man sich dann verbindet)
Die Ubuntu VM ist in einer DMZ und löst sie DNS Anfragen nicht auf, deshalb das Server Netz dazu
Das Problem
Das Problem ist, dass die Einträge irgendwann wieder verschieden am LMDE Client. Entweder erst nach vielen Stunden, teils aber auch nach einigen Minuten. Muster sehe ich noch keines. Die RDP Verbindung bricht natürlich ab
Sobald ich die beiden Einträge nochmal absetze, kann ich die RDP Verbindung sofort wieder aufbauen
wenn ich testweise den Befehl gleich nochmal absetze, kommt die Meldung:
root@linux-mint:/home/user# ip route add 10.101.30.0/24 via 10.210.0.1 dev tun0
**RTNETLINK answers: File exists**... weil der Eintrag drin ist. Ich verstehe das also so, als ob nach gewisser Zeit der Eintrag / die Datei von RTNETLINK verschwindet
Wenn ich es als Administrator (also ohne sudo, sonder vorher halt auf su gewecheslt) ausführe, bricht es noch früher ab
Die Frage
Wieso verschwinden sie bzw. kann ich das irgendwie permanent hinterlegen?
10.101.30.0/24 und 10.101.10.0/24 können dauerhaft fix hinterlegt werden. Ich werde die nie anders nutzen...
ich habe mich schon mit Einträgen in der .ovpn Datei gespielt, aber so richtig hat das nur für Windows Clients funktioniert.
Für ein Ipad müsste ich auch noch was machen, aber da bin ich völlig Land unter, welche Optionen / Syntax nötig ist
Zusätzliche Info
Ich weiß, dass es geschickter wäre, das Server Netz nicht dazu zu nehmen, v.a. wenn es nur für die DNS Auflösung ist.
Bei einem user, der sich nur auf 1 PC verbindet, werde ich es so machen, dass nur das Client Netz geroutet wird und der PC halt eine fixe (reservierte) IP bekommt und man sich auf die IP verbindet...
Aber das ist das Apfelgerät....
Danke im Voraus!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6162248609
Url: https://administrator.de/forum/vpn-routing-eintrag-auf-debian-verschwindet-6162248609.html
Ausgedruckt am: 08.04.2025 um 09:04 Uhr
24 Kommentare
Neuester Kommentar
Du nutzt ein Wireguard VPN mit einem OpenVPN Client? Respekt! Das muss dir erstmal einer nachmachen.
Tip:
Wenn du mehr mit Linux machen willst warum nutzt du als VPN nicht einfach IPsec, dann kannst du mit jedem Endgerät, egal welches OS die bordeigenen VPN Clients benutzen und ersparst dir die Frickelei mit (überflüssigen) externen Clients und deren Zugangsdaten auf den Endgeräten! Siehe zu dem Thema HIER. Einfacher gehts nicht.
Tip:
Wenn du mehr mit Linux machen willst warum nutzt du als VPN nicht einfach IPsec, dann kannst du mit jedem Endgerät, egal welches OS die bordeigenen VPN Clients benutzen und ersparst dir die Frickelei mit (überflüssigen) externen Clients und deren Zugangsdaten auf den Endgeräten! Siehe zu dem Thema HIER. Einfacher gehts nicht.
Hab ich was irreführend beschrieben? Tatsächlich wird für VeeamPN auf Clientseite der OpenVPN Client installiert.
siehe auch:
https://aventistech.com/2020/04/12/site-to-site-vpn-with-veeampn/
@aqui
Mit Linux will ich mehr daheim machen. Das ist meine persönliche Sache. Das VPN ist aber Firmensache und hier geht es um Windows Clients bzw. das eine Ipad...
Und es geht ja schon und ich werde da nicht wieder was ganz neues aufrollen
siehe auch:
https://aventistech.com/2020/04/12/site-to-site-vpn-with-veeampn/
Veeam PN is a simple tool for establishing VPN between all parts of a distributed infrastructure: the headquarters, remote and branch offices, employees working remotely, etc. This solution is based on the OpenVPN technology.@aqui
Mit Linux will ich mehr daheim machen. Das ist meine persönliche Sache. Das VPN ist aber Firmensache und hier geht es um Windows Clients bzw. das eine Ipad...
Und es geht ja schon und ich werde da nicht wieder was ganz neues aufrollen
Mit anderen Worten: Veeam nutzt dann ganz simpel OpenVPN.
Das Tutorial erklärt dir anhand von Live Beispielen wie das Routing zu setzen ist wenn man mit dem Client auch ein Site-to-Site Design macht.
Von OpenVPN solltest du für zukünftige VPN Projekte wegen dessen mieser Performance und Skalierbarkeit besser die Finger lassen.
Das Tutorial erklärt dir anhand von Live Beispielen wie das Routing zu setzen ist wenn man mit dem Client auch ein Site-to-Site Design macht.
Von OpenVPN solltest du für zukünftige VPN Projekte wegen dessen mieser Performance und Skalierbarkeit besser die Finger lassen.
hier geht es um Windows Clients bzw. das eine Ipad...
Funktioniert mit dessen onboard IKEv2 VPN Client bei beiden Geräten deutlich besser als das schlecht skalierende OpenVPN. Siehe Tutorial.
Nein, VeeamPN nutzt Wireguard in den letzten Updates, außer ich hab das alles ganz falsch verstanden:
https://forums.veeam.com/veeam-tools-for-microsoft-azure-f36/latest-patc ...
Und die Performance ist überhaupt kein Thema.
Mein Problem (und der Grund des Threads) ist das Linux-seitige Problem, wieso der Routingeintrag verschwindet. Mit dem VPN bin ich happy (auch wenn es da sicher mal eine andere Lösung geben wird)
https://forums.veeam.com/veeam-tools-for-microsoft-azure-f36/latest-patc ...
Und die Performance ist überhaupt kein Thema.
Mein Problem (und der Grund des Threads) ist das Linux-seitige Problem, wieso der Routingeintrag verschwindet. Mit dem VPN bin ich happy (auch wenn es da sicher mal eine andere Lösung geben wird)
1
Was nutzt du denn nun Wireguard oder OpenVPN?? Deine Beschreibung ist wirr. Mal redest du von dem, dann wieder von dem. Was denn nun?? 
Beide, WG und OVPN, benötigen für eine reine Client Anbindung keinen Routing Eintrag!
Beide, WG und OVPN, benötigen für eine reine Client Anbindung keinen Routing Eintrag!
Hier ist die Info vom Hersteller. Da steht es in einem, dass BEIDES verwendet wird:
https://helpcenter.veeam.com/archive/veeampn/21/userguide/overview.html
besser kann ich es nicht beschreiben
und ja, die Lösung ist abgekündigt und bekommt keine Updates mehr, das ist mir bewusst. Es wird sicher *bald* durch was anderes ersetzt, wenn ich weiß, wohin das Business will
Veeam PN lets you set up VPN connections between Microsoft Azure or AWS networks and on-premises networks. The solution is based on the WireGuard®* and OpenVPN technology and features a web-based interface that simplifies VPN configuration and administration.https://helpcenter.veeam.com/archive/veeampn/21/userguide/overview.html
besser kann ich es nicht beschreiben
und ja, die Lösung ist abgekündigt und bekommt keine Updates mehr, das ist mir bewusst. Es wird sicher *bald* durch was anderes ersetzt, wenn ich weiß, wohin das Business will
Da steht es in einem, dass BEIDES verwendet wird:
Ahhhsooo... OK, trotzdem braucht es dann keine Routing Einträge, denn das machen die VPN Protokolle automatisch. Am Client kannst du das mit ip r bei aktivem VPN Client auch immer selber sehen.und bekommt keine Updates mehr, das ist mir bewusst.
Warum machst du dich denn davon abhängig?? Für IPsec, WG oder OpenVPN an sich braucht es keine solche Software!Kann ich das irgendwie permanent hinterlegen?
Klar nutze iroute entries in den ccd files, oder lass die Routen pushen oder trägst sie mit route in die Client-Config ein dann brauchst du da auch nicht manuell Routen anlegen, das ist überflüssig.=> Lans behind OpenVPN
3Klar nutze iroute entries in den ccd files, oder lass die Routen pushen
Steht beides im o.a. Tutorial und dessen weiterführenden Links. Man muss es als TO nur mal lesen und umsetzen... 😉
Ja, Tutorials lesen, alles umsetzen, machen...
das Meiste bei mir leider immer nur in der Freizeit. Und das geht einfach nur noch selten.
Soll natürlich nicht auf Lasten der anderen Teilnehmer hier sein, die mir helfen wollen. Drum versuche ich doch, vieles zusammen zu fassen.
Die vielen Tutorials @aqui hab ich mir 'gebookmarked' und immer wieder versucht, Infos aus Teilen raus zu lesen
Das mit der Route pushen hab ich versucht. bzw. einfach in der .ovpn fix zu hinterlegen
Für Windows hat es geklappt. Linux und Ipad leider nicht...
kann ich das nicht fix in die .ovpn am Client eintragen? ist ja kein Aufwand...
Beim Windows Client hab ich zb. das funktional im Einsatz (beide netze in einem)
Ipad und Linux scheinen es zu ignorieren.
iroute sagt mir (noch) gar nichts und hätte ich auch nicht gefunden
ccd files... sorry, wo, was?
jedenfalls wenn ich die Route NICHT mache, geht gar nix. Kann natürlich an der Konfig liegen (die sicher nicht lückenlos ist)
sorry, wenn da wieder was verwirrend ist...
das Meiste bei mir leider immer nur in der Freizeit. Und das geht einfach nur noch selten.
Soll natürlich nicht auf Lasten der anderen Teilnehmer hier sein, die mir helfen wollen. Drum versuche ich doch, vieles zusammen zu fassen.
Die vielen Tutorials @aqui hab ich mir 'gebookmarked' und immer wieder versucht, Infos aus Teilen raus zu lesen
Das mit der Route pushen hab ich versucht. bzw. einfach in der .ovpn fix zu hinterlegen
Für Windows hat es geklappt. Linux und Ipad leider nicht...
kann ich das nicht fix in die .ovpn am Client eintragen? ist ja kein Aufwand...
Beim Windows Client hab ich zb. das funktional im Einsatz (beide netze in einem)
...
cipher AES-256-CBC
route 10.101.0.0 255.255.0.0 10.210.0.0
push "dhcp-option DNS 10.101.30.102"
push "dhcp-option DNS 10.101.30.103"
push "dhcp-option domain.local"
tls-client
...Ipad und Linux scheinen es zu ignorieren.
iroute sagt mir (noch) gar nichts und hätte ich auch nicht gefunden
ccd files... sorry, wo, was?
jedenfalls wenn ich die Route NICHT mache, geht gar nix. Kann natürlich an der Konfig liegen (die sicher nicht lückenlos ist)
sorry, wenn da wieder was verwirrend ist...
Das mit der Route pushen hab ich versucht. bzw. einfach in der .ovpn fix zu hinterlegen
Das geht gar nicht, denn das ist einen Funktion des OpenVPN Servers und seiner Konfig, nicht des Clients!!! OpenVPN Tutorial lesen und verstehen. 
push "dhcp-option domain.local"
Der nächste Fehler! .local Domains sind intern bekanntlich Tabu!Hinweise zur Verwendung der Domäne .local in DNS und mDNS
Ipad und Linux scheinen es zu ignorieren.
Nein, stimmt so natürlich nicht! Besonders für Linux stimmt es nicht. Nicht wenn man es richtig einrichtet auf dem Server. Deine .conf Datei von dort wäre sicher hilfreicher als hier weiter zu kristallkugeln.iroute sagt mir (noch) gar nichts
O.a. Tutorial lesen und OpenVPN Doku lesen!! https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4 ... --> --irouteccd files... sorry, wo, was?
Oha...du hast dich nicht wirklich mit OpenVPN beschäftigt, oder? Lies den dir oben geposteten Thread zu dem Thema! Da ist doch nun wirklich alles explizit beschrieben. Mehr als appellieren das du es liest und verstehst kann man ja nicht über ein Forum...
jedenfalls wenn ich die Route NICHT mache, geht gar nix
Weil deine Server- und vermutlich auch die Client Konfig falsch oder fehlerhaft ist!1
Danke. RTFM ist natürlich eine korrekte Antwort. Wird aber nicht komplett passieren. Und das Forum soll das natürlich nicht kompensieren.
Der Hinweis mit iroute (und dass das ein OPVPN Parameter ist und wo ich es finde) hilft mir. Auch, dass das push in der serverseitigen konfig sein muss, nicht clientseitig. Ja, mehr hab ich durch querlesen noch nicht raus bekommen.
RFC6762 zu domain.local war zb. noch nicht bei meiner Nachtlektüre dabei, da stimmen mir viele andere IT-Allrounder, die nebenbei noch Einkauf und Bewerbermanagement machen, sicher zu...
Dennoch war meine Eingangsfrage:
wieso verschwindet der Routingeintrag bei meinem LMDE Client? Ich finde, das andere ist alles Off-topic
Weil wenn ich die Befehle absetze, geht alles, wie es soll.
Aber sie verschwinden wieder.
Der Hinweis mit iroute (und dass das ein OPVPN Parameter ist und wo ich es finde) hilft mir. Auch, dass das push in der serverseitigen konfig sein muss, nicht clientseitig. Ja, mehr hab ich durch querlesen noch nicht raus bekommen.
RFC6762 zu domain.local war zb. noch nicht bei meiner Nachtlektüre dabei, da stimmen mir viele andere IT-Allrounder, die nebenbei noch Einkauf und Bewerbermanagement machen, sicher zu...
Dennoch war meine Eingangsfrage:
wieso verschwindet der Routingeintrag bei meinem LMDE Client? Ich finde, das andere ist alles Off-topic
Weil wenn ich die Befehle absetze, geht alles, wie es soll.
Aber sie verschwinden wieder.
Zitat von @6017814589:
=> Lans behind OpenVPN
Kann ich das irgendwie permanent hinterlegen?
Klar nutze iroute entries in den ccd files, oder lass die Routen pushen oder trägst sie mit route in die Client-Config ein dann brauchst du da auch nicht manuell Routen anlegen, das ist überflüssig.=> Lans behind OpenVPN
Kannst du mir erklären, wie du das mit der 3. Aussage "oder trägst sie mit route in die client-config ein" gemeint hast?
weil genau das hab ich versucht und ja gemacht, oder?
wenn du damit meinst, dass ich damit das "route" in die clientseitige .opvn eintragen soll - auch das hab ich natürlich versucht. Vielleicht mit falscher Syntax...
Edit.
Ich versuche das: mit einem manuellen Eintrag in der client-seitigen .ovpn
route 10.101.30.0 255.255.255.0
route 10.101.10.0 255.255.255.0mal sehen, ob das hält.
Du solltest vielleicht erstmal klären WAS du genau erreichen willst?!
Soll der VPN Client nur als einfacher VPN Client auf dem Server arbeiten und auf Endgeräte im lokalen LAN der Servers?
Wenn ja sind keinerlei Routing sei es route oder iroute Einträge erforderlich!
Wichtig sind dann lediglich 2 simple Dinge in der Server Konfig Datei:
Anders sieht die Sache aus wenn du mit dem Client auch das lokale LAN der Client Seite routen willst. Quasi also eine Site-to-Site VPN Kopplung dann, und nur dann, musst du mit route und Client spezifischen iroute Kommandos am Server arbeiten.
Bei dir ist das, versteht man dich richtig, aber nicht der Fall. Folglich benötigst du dann auch diese Kommandos NICHT sondern schlicht und einfach nur das "push route" Kommando und gut iss.
Ob die Routen bei aktivem Client sauber injiziert wurden kannst du unter Linux immer mit ip r sehen. Auf einem Windows Client mit route print und auf iOS Geräten braucht du Apps dafür wie z.B. die HE.NET Tools.
Soll der VPN Client nur als einfacher VPN Client auf dem Server arbeiten und auf Endgeräte im lokalen LAN der Servers?
Wenn ja sind keinerlei Routing sei es route oder iroute Einträge erforderlich!
Wichtig sind dann lediglich 2 simple Dinge in der Server Konfig Datei:
- Mit topology subnet und push "topology subnet" das moderne Subnet Verfahren für das interne VPN IP Netz erzwingen. Das veraltete net30 Verfahren sollte NICHT mehr verwendet werden!
- Mit push "route 192.168.100.0 255.255.255.0" injiziert man das lokale Server LAN in die Routing Tabelle des Clients. (Beispiel hier das der VPN Server im lokalen LAN 192.168.100.0/24 liegt) Damit wird dann automatisch das lokale OpenVPN IP Netz und das lokale Server LAN in die Routing Tabelle des VPN Clients injiziert.
- Fertisch
Anders sieht die Sache aus wenn du mit dem Client auch das lokale LAN der Client Seite routen willst. Quasi also eine Site-to-Site VPN Kopplung dann, und nur dann, musst du mit route und Client spezifischen iroute Kommandos am Server arbeiten.
Bei dir ist das, versteht man dich richtig, aber nicht der Fall. Folglich benötigst du dann auch diese Kommandos NICHT sondern schlicht und einfach nur das "push route" Kommando und gut iss.
Ob die Routen bei aktivem Client sauber injiziert wurden kannst du unter Linux immer mit ip r sehen. Auf einem Windows Client mit route print und auf iOS Geräten braucht du Apps dafür wie z.B. die HE.NET Tools.
Um auf deine Frage zu antworten - nein, ich will keine Site-to-Site Kopplung sondern nur rein den Client auf das Firmennetz (und hier auch nur diverse Ziele, die via RDP erreicht werden sollen) zugreifen lassen.
Ich bin mir sicher, dass es in der VPN (VeeamPN) Konfig Fehler gibt. Aber es läuft und auch diese Lösung hat lange genug gedauert. Leider fehlen mir viele Basis-Kenntnisse und eben auch die Zeit, mich da noch weiter rein zu arbeiten.
Wie man im VeeamPN Forum liest, haben das auch andere als ihre Lösung gebracht:
https://forums.veeam.com/veeam-tools-for-microsoft-azure-f36/remote-clie ...
(Beitrag von lauberth: https://forums.veeam.com/veeam-tools-for-microsoft-azure-f36/remote-clie ... )
Jedenfalls braucht es die die route Befehle Clientseitig. Anders hat es bei mir nicht funktioniert.
Und auf LMDE braucht es eben eine ständige Wiederholung des Kommands.
Nochmal bekräftigend
Wenn ich keine Zeit habe, mich da einzulesen, erwarte ich natürlich nicht, dass das Forum das für mich aus meiner Bequemlichkeit raus kompensiert. In den Worten eines Freundes: Für ein Stück Code, das nicht ganz funktioniert, poste oder lese ich auf StackOverflow. Aber ich kann nicht erwarten, dass sie meine Sotware für mich schreiben.
So sehe ich das hier. Ich habe eine Lösung, die funktioniert (aber natürlich für Experten wie aqui befremdlich ungenügend ist). Und da hab ich eine Frage dazu (wieso LMDE das immer wieder verliert. Und bei Gelegenheit könnt ihr mir auch sagen, wie es auf ipad funktioniert :-p )
Danke für die Anteilnahme bisher
Ich bin immer wieder erstaunt, wie viel du, aqui, hier erklärst und beschreibst. Direkt unermüdlich - Danke auch in meinem Fall!
Ich bin mir sicher, dass es in der VPN (VeeamPN) Konfig Fehler gibt. Aber es läuft und auch diese Lösung hat lange genug gedauert. Leider fehlen mir viele Basis-Kenntnisse und eben auch die Zeit, mich da noch weiter rein zu arbeiten.
Wie man im VeeamPN Forum liest, haben das auch andere als ihre Lösung gebracht:
https://forums.veeam.com/veeam-tools-for-microsoft-azure-f36/remote-clie ...
(Beitrag von lauberth: https://forums.veeam.com/veeam-tools-for-microsoft-azure-f36/remote-clie ... )
Jedenfalls braucht es die die route Befehle Clientseitig. Anders hat es bei mir nicht funktioniert.
Und auf LMDE braucht es eben eine ständige Wiederholung des Kommands.
Nochmal bekräftigend
Wenn ich keine Zeit habe, mich da einzulesen, erwarte ich natürlich nicht, dass das Forum das für mich aus meiner Bequemlichkeit raus kompensiert. In den Worten eines Freundes: Für ein Stück Code, das nicht ganz funktioniert, poste oder lese ich auf StackOverflow. Aber ich kann nicht erwarten, dass sie meine Sotware für mich schreiben.
So sehe ich das hier. Ich habe eine Lösung, die funktioniert (aber natürlich für Experten wie aqui befremdlich ungenügend ist). Und da hab ich eine Frage dazu (wieso LMDE das immer wieder verliert. Und bei Gelegenheit könnt ihr mir auch sagen, wie es auf ipad funktioniert :-p )
Danke für die Anteilnahme bisher
Ich bin immer wieder erstaunt, wie viel du, aqui, hier erklärst und beschreibst. Direkt unermüdlich - Danke auch in meinem Fall!
Ich bin mir sicher, dass es in der VPN (VeeamPN) Konfig Fehler gibt.
Dann wäre DAS dein erster Anlaufpunkt um das zu fixen!Leider fehlen mir viele Basis-Kenntnisse und eben auch die Zeit, mich da noch weiter rein zu arbeiten.
Normal holt man sich da dann Hilfe an die Hand...Jedenfalls braucht es die die route Befehle Clientseitig
Nein, das ist definitiv Quatsch bzw. zeigt dann von einer völlig falschen oder fehlerhaften Server Konfig. Siehe oben!
Hi,
mir ist das inzwischen hier zu unübersichtlich geworden und es lässt sich kaum noch geordnet nachvollziehen, nur ein paar Tipps.
Der OpenVPN-Client, hier wohl auf dem Debian-PC, braucht keine Routingeinträge und mich wundert nicht, das er die händisch eingetragenen, wieder vergisst.
Das Routing muss alles auf dem Server passieren.
Wichtig ist nur, das eine CCD auf dem Server existiert, die die Routing-Anweisungen an den Client weiter gibt.
Auf den Client gehört nur die OpenVPN-Software installiert und unter...
/etc/openvpn
die client.conf und die ovpn.ca, client.ca, client.key und ta.key installiert.
Mit "openvpn /etc/openvpn/client.conf" kannst Du den Tunnel händisch initiieren und die Ausgabe in der Konsole sehen.
Vorausgesetzt natürlich, es handelt sich auch um OpenVPN.
Im übrigen gibt es bei der Erstellung der "client.conf" zu beachten, das es Versionsunterschiede bei OpenVPN gibt und man schon dabei Fehler einbauen kann.
Ob Du das ganze dann automatisch starten lässt, oder im NW-Manager, ist Dir überlassen.
Das Routing übernimmt Dein OpenVPN-Server.
Hier mal ein Bsp. einer client.conf.....
Die Einträge solltest Du anpassen an Deine Server.conf und beachte, das diese Einträge je nach OpenVPN-Versionen variieren können.
Gruß orcape
mir ist das inzwischen hier zu unübersichtlich geworden und es lässt sich kaum noch geordnet nachvollziehen, nur ein paar Tipps.
Der OpenVPN-Client, hier wohl auf dem Debian-PC, braucht keine Routingeinträge und mich wundert nicht, das er die händisch eingetragenen, wieder vergisst.
Das Routing muss alles auf dem Server passieren.
Wichtig ist nur, das eine CCD auf dem Server existiert, die die Routing-Anweisungen an den Client weiter gibt.
Auf den Client gehört nur die OpenVPN-Software installiert und unter...
/etc/openvpn
die client.conf und die ovpn.ca, client.ca, client.key und ta.key installiert.
Mit "openvpn /etc/openvpn/client.conf" kannst Du den Tunnel händisch initiieren und die Ausgabe in der Konsole sehen.
Vorausgesetzt natürlich, es handelt sich auch um OpenVPN.
Im übrigen gibt es bei der Erstellung der "client.conf" zu beachten, das es Versionsunterschiede bei OpenVPN gibt und man schon dabei Fehler einbauen kann.
Ob Du das ganze dann automatisch starten lässt, oder im NW-Manager, ist Dir überlassen.
Das Routing übernimmt Dein OpenVPN-Server.
Hier mal ein Bsp. einer client.conf.....
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
persist-tun
persist-key
data-ciphers AES-128-GCM:AES-256-GCM
data-ciphers-fallback AES-256-CBC
auth SHA256
client
tls-auth /etc/openvpn/ta.key 1
resolv-retry infinite
remote xxxyyyy.spdns.de 1195 udp4
nobind
verify-x509-name "egon" name
remote-cert-tls server
explicit-exit-notifyGruß orcape
2
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Ganz fertig getestet sehe ich es nicht, aber ich denke, ich kann es mal so als gelöst markieren:
- Die Frage, wieso der Eintrag verschwindet, ist nicht geklärt. Aber es liegt wohl daran, dass diese Routen so nicht gedacht sind.
Wie von mehreren hingewiesen, ist die OpenVPN Konfig / die Routen nicht sauber und es gehört am Server richtig eingestellt
Nachdem ich es am Server in die Endpoint.ovpn eingetragen hatte (hatte ich vorher schon, aber wohl nicht korrekte Syntax), sieht es aktuell so aus, als ob das Routing am LMDE Client bleibt
Auch am Ipad scheint es übernommen worden zu sein.
- Die Frage, wieso der Eintrag verschwindet, ist nicht geklärt. Aber es liegt wohl daran, dass diese Routen so nicht gedacht sind.
Wie von mehreren hingewiesen, ist die OpenVPN Konfig / die Routen nicht sauber und es gehört am Server richtig eingestellt
Nachdem ich es am Server in die Endpoint.ovpn eingetragen hatte (hatte ich vorher schon, aber wohl nicht korrekte Syntax), sieht es aktuell so aus, als ob das Routing am LMDE Client bleibt
Auch am Ipad scheint es übernommen worden zu sein.
ist die OpenVPN Konfig / die Routen nicht sauber und es gehört am Server richtig eingestellt
Das ist aber auch eine seit Jahrzehnten bekannte Binsenweisheit. Wenn du das nicht beachtet hast ist es ja dann auch klar das Dinge nicht so laufen wie sie sollen. Einfache Logik! Das es nun rennt wie es soll unterstreicht dies.
Wie geschrieben, man muss es wissen. Um es zu wissen, muss man sich damit beschäftigen. Beschäftigen braucht Zeit und die muss man nach Prioritäten investieren. Bei mir war und ist es leider nicht gewesen, drum bitte ich immer wieder mal um Rat. Ich gebe zu, es ist nicht meine Stärke und wird es auch nicht werden.
Soweit hat die VPN-Lösung funktioniert, nur eben nicht auf Linux Clients und auf dem Ipad. Zwei Einzelgeräte.
Danke für die Hilfen!
Im Prinzip sind mehrere Posts die Lösung / Teil der Lösung
Soweit hat die VPN-Lösung funktioniert, nur eben nicht auf Linux Clients und auf dem Ipad. Zwei Einzelgeräte.
Danke für die Hilfen!
Im Prinzip sind mehrere Posts die Lösung / Teil der Lösung
Im Prinzip sind mehrere Posts die Lösung / Teil der Lösung
So wie das zumindest hier dargestellt ist, gibt es aber nur eine Lösung.... Also KeineFrickeLei ?
1
Kurzes Update noch dazu, weil ich mir einfach blöd vorkomme...
Ich hatte auf der LMDE Kiste zusätzlich ein GUI installiert ( nennt sich "EOVPN", wie eingangs beschrieben und fand ich über die Paketsuche)
Dabei kann man eine VPN Konfig nativ einfach über die Netzwerkverwaltung importieren... und seit ich das nutze, stürzt auch keine Verbindung mehr ab....
Wusste ich nicht und hätte ich sofort genutzt. Unter Windows ist man halt gewohnt, für alles was zu installieren...
RTFM im Grunde, ja, aber wer hat so viel Zeit sich immer hunderte Seiten Handbücher durchzulesen?
Zweite Randbemerkung:
auf dem Ipad geht es auch einwandfrei. Das durch einen Dienstleister extra eingerichtete Cisco VPN mit Zertifikat aber nicht. Laut dem DL wohl so eine Apple-Sache, dass die sich nicht an Standards halten...
Vielleicht helfen meine Fehler ja jemandem.
EOL, Feierabend...
Ich hatte auf der LMDE Kiste zusätzlich ein GUI installiert ( nennt sich "EOVPN", wie eingangs beschrieben und fand ich über die Paketsuche)
Dabei kann man eine VPN Konfig nativ einfach über die Netzwerkverwaltung importieren... und seit ich das nutze, stürzt auch keine Verbindung mehr ab....
Wusste ich nicht und hätte ich sofort genutzt. Unter Windows ist man halt gewohnt, für alles was zu installieren...
RTFM im Grunde, ja, aber wer hat so viel Zeit sich immer hunderte Seiten Handbücher durchzulesen?
Zweite Randbemerkung:
auf dem Ipad geht es auch einwandfrei. Das durch einen Dienstleister extra eingerichtete Cisco VPN mit Zertifikat aber nicht. Laut dem DL wohl so eine Apple-Sache, dass die sich nicht an Standards halten...
Vielleicht helfen meine Fehler ja jemandem.
EOL, Feierabend...
Laut dem DL wohl so eine Apple-Sache, dass die sich nicht an Standards halten...
Das ist natürlich völliger Quatsch, denn Apple hält sich hier an die üblichen Standards.Die fehlerlos funktionierenden üblichen IKEv2 oder L2TP VPNs mit Apple Endgeräten und Zertifikaten zeigen das ja eindeutig! Sogar mit einem 15 Euro Raspberry Pi als VPN Server arbeiteten alle Apple Clients fehlerlos. Aber egal...case closed.
