OpenVPN ERROR Linux route add comand failed...

Status
Für weitere Antworten geschlossen.

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Hi Leute,

habe ein Problem mit dem Verbinden des Clients zum OpenVPN Server und kann einfach keine Lösung dafür finden.
Client ist ein Raspberry Pi 3.
Firewall des DS1817+ ist eingestellt: einmal der VPN Port für alle IPs zugelassen und außerdem (weiß nicht, ob das sein muss oder etwas bringen kann) verschiedene Anwendungen bzw. deren Ports, von denen ich mir vorstellen kann, dass sie vom Client gebraucht werden könnten, für den IP-Bereich des OpenVPN Servers (10.0....).
Meine Fritzbox leitet den OpenVPN Port an mein NAS weiter.
Die Fritzbox des Haushaltes in dem sich der Client befindet ist ebenfalls darauf eingerichtet. Ebenso die örtliche Firewall.
VPNServer ist aktuell.

hier meine Client Config:

dev tun
tls-client
remote x.synology.me 1194
#float
redirect-gateway def1
#dhcp-option DNS DNS_IP_ADDRESS
pull
proto udp
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth RSA-SHA512
auth-user-pass
auth-nocache
<ca>
-----BEGIN CERTIFICATE----- ...
</ca>

Hier das OpenVPN Log (Client-seitig):

TCP/UDP Preserving recently used remote address: [AF_INET] "öffentl. IP-Adresse":1194
UDP link local (bound): [AF_INET] [undef]:1194
UDP link remote: [AF_INET] "öffentl. IP-Adresse":1194
["DDNS"] Peer Connection Initiated with [AF_INET] "öffentl. IP-Adresse":1194
TUN/TAP device tun0 opened
do_ifconfig, tt->did_ifconfig_ipv6_setup=0
/sbln/ip link set dev tun0 local 10.8.0.6 peer 10.8.0.5
ERROR: Linux route add comand failed: external program exited with error status: 2
Initialization Sequence Completed

Die Verbindung wird als erfolgreich angegeben, es wird die richtige IP angezeigt, aber ich kann nicht per NFC auf mein NAS zugreifen.
Entsprechende Ordner sind für die IP des Clients freigegeben.

Der Fehler ERROR: Linux route add comand failed: external program exited with error status: 2 spricht meinen Recherchen nach für einen Fehler in der Server Config, konkret ist von gepushten routen die Rede und von reduntanten Zeilen im Code.

Nur kann ich die Server Config nicht einsehen bzw. ändern... oder doch?
Vll hat das aber auch ganz andere Ursachen?

Hat jemand Erfahrung mit diesem Fehler oder eine Ahnung was das sein könnte?

Vielen Dank im Voraus für jeden Hinweis!

Gruß

noobo
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Gibt es das Log noch etwas ausführlicher?

Verschwindet der Fehler wenn du "redirect-gateway def1" auskommentierst?
Dann wird vermutlich versucht eine Route zu setzen die schon existiert.
Oder es gibt ein Konflikt bei den Routen oder Netzwerken.

Das VPN Tunnelnetz ist ja 10.8.0.x.
Welche IP Netze kommen im LAN des VPN Servers und im LAN des VPN Clients zum Einsatz?
Beim Server vermutlich 192.168.178.x (Fritzbox Standard)?
Beim Client sollte 192.168.178.x NICHT zum Einsatz kommen in dem Fall.
Client, Server und Transportnetz sollten nach Möglichkeit immer aus verschiedenen Netzbereichen stammen.

Die VPN Server config ist unter
/var/packages/VPNCenter/etc/openvpn/openvpn.confq
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Hi Fusion,

danke für Deine Antwort!

Das Log gibt es nicht ausführlicher, das ist alles was mir angezeigt wurde. Ich werde aber mal suchen, ob ich da was finde.

Ich weiß leider nicht wie ich "redirect-gateway def1" ausformuliere. Ich mache meinem Namen alle Ehre, ich weiß ;)

Das Server- und das Client Netz liegen beide imselben Bereich 192.178.168.xx, darin könnte hier natürlich das Problem liegen. Reicht es denn an der Client-IP einfach nur aus der 192 eine 193 zu machen?
Ich probiere es auf jeden Fall aus und werde berichten.

WIe komme ich denn auf den von dir angegeben Pfad /var/packages/VPNCenter/etc/openvpn/openvpn.confq ? Habe in der Benutzeroberfläche gründlich hesucht... ich nehme an per ftp?

Danke!
 

tproko

Benutzer
Sehr erfahren
Mitglied seit
11. Jun 2017
Beiträge
2.101
Punkte für Reaktionen
253
Punkte
129
Nicht ausformuliere, sondern in der Config "auskommentieren" - also # davor oder ganz löschen.

Dein Client ist ein Linux System?
Ich kann mein OpenVPN auf meinem Fedora nur mit sudo (also root Rechte starten).
sudo openvpn --config VPNconfig-linux.ovpn --auth-nocache
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Auskommentieren geht via # am Anfang der Zeile

Als erstes würde ich nun aber mal eines der Netze ändern.
Sprich ein LAN läßt du einfach auf 192.168.178.x und die Fritzbox auf 192.168.178.1
Das andere LAN setzt du z.B. auf 192.168.188.x und die Fritzbox auf 192.168.188.1
Die Subnetz-Masken können dabei auf 255.255.255.0 verbleiben.

Die IP Netze ändern müsste man ebenfalls machen, wenn man z.B. die Fritzboxen direkt per LAN-to-LAN VPN Kopplung betreibt.

An die vpn config würdest du per Telnet/SSH kommen.
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Habe die IP am Standort des Clients geändert. Die Fehlermeldung im Log ist nun verschwunden bzw. die letzten drei Zeilen haben sich nun verändert:

TCP/UDP Preserving recently used remote address: [AF_INET] "öffentl. IP-Adresse":1194
UDP link local (bound): [AF_INET] [undef]:1194
UDP link remote: [AF_INET] "öffentl. IP-Adresse":1194
["DDNS"] Peer Connection Initiated with [AF_INET] "öffentl. IP-Adresse":1194
TUN/TAP device tun0 opened
do_ifconfig, tt->did_ifconfig_ipv6_setup=0
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 local 10.8.0.6. peer 10.8.0.5
Initialization Sequence Completed

Soweit so gut, alles scheint zu funktionieren.

Leider kann ich dennoch nicht über NFS auf den freigegeben Ordner zugreifen. Habe ihn testweise für sämtliche in Frage kommenden IPs freigegeben. Die lokale und die öffentliche am Standort des Clients, sowie die IP, die vom VPN Server selbst für den verbundenen Client angezeigt wird.

Am sudo liegt es wohl nicht, da ich eh root Rechte am Linux Gerät habe (zeigt mir der OpenVPN manager am Gerät auch an).

Irgendetwas scheine ich zu übersehen oder falsch zu machen...
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Testweise Firewall deaktivieren, um einzugrenzen woran es liegt.

Ist die Option "Clients den Server LAN Zugriff erlauben" im VPN Server gesetzt?
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
an der Firewall scheint es nicht zu liegen. Habe sie bereits ausgeschaltet, leider ohne Erfolg.

DIe Option "Clients den Server LAN Zugriff erlauben" am VPNServer ist aktiv.

Wenn ich übrigens "redirect-gateway def1" auskommentiere, schlägt die Verbindung fehl.
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Dann stimmt aber was nicht, weil die Option nur dafür sorgt, dass sämtlicher traffic über das VPN geht, oder wenn auskommentiert eben nur jener der auch für das Netz auf der anderen Seite des Tunnels gedacht ist.

Wie versuchst du denn nach Aufbau des VPN den Zugriff? Mit nfs://nas-ip (also z.B. 192.168.178.20, oder wo auch immer die erreichbar ist)?
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
@Fusion

Habe noch etwas damit rumgespielt. Nachdem ich den Raspi neu gestartet hatte, ging es dann auch mit auskommentiertem redirect, da hing also anscheinend irgendwas anderes quer.

Ich verwende für die VPN Verbindung das Addon "VPN manager for OpenVPN" und versuche nach dem Verbinden dann eine neue Medienquelle hinzuzufügen. Dafür klicke ich einfach in dem entsprechenden Menü auf NFS. Dann lädt er eine Weile, aber es passiert leider gar nichts. Wenn ich dasselbe am Serverstandort versuche, gelange ich ins Heimnetz, kann da dann die Server IP auswählen und gelange dann zu den freigegeben Ordnern.

Müsste es nicht genau so auch funktionieren, wenn ich über VPN verbunden bin? Habe auch noch bisschen mit den Portfreigaben und -Weiterleitungen am Router experimentiert, aber leider nichts...
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Mit dem Discovery gibt es teils Probleme. Hast du die Medien quelle mal direkt unter Angabe von IP etc hinzugefügt?
Portangaben im Router sind außen vor sobald du per VPN verbunden bist.
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Du meinst über "Netzwerkfreigabe hinzufügen"?

Habe ich versucht, aber ehrlich gesagt etwas halbherzig, weil ich dachte das müsste, wenn dann direkt funktionieren.
Ich werde es sobald ich kann nochmal probieren. Ist immer etwas doof, wenn ich nur zeitweise vor Ort des Clients bin.

Nur, damit ich es schonmal richtig verstehe: ich wähle dort also NFS und als Server die lokale IP des Servers, also 192.168.178.x und den Port lasse ich frei?
Habe eventuell einen Port angeben wollen bei meinem Versuch... kann mich nicht konkret erinnern.

Vielen Dank!

edit: und bei der Ordnerfreigabe fürs NFS gebe ich auch die lokale IP des Clients nach Verbindung an oder? Also auch die 192.168.178.x , nur eben mit richtiger, anderer letzter Ziffer?
 
Zuletzt bearbeitet:

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Ja, denke dieser Punkt war es. Also nicht nfs, smb oder ähnliches sondern direkt der letzte Punkt in der Liste beim hinzufügen einer Quelle, "Netzwerkfreigabe hinzufügen".
Dort dann direkt nfs://nas-ip/<freigabe> eintippen, mit/ohne Freigabe weiß ich jetzt nicht mehr.

Ja, die IP/Netzfreigaben für NFS müssen natürlich alle IPs/Netze umfassen woher Clients zugreifen wollen.
Würde erstmal beide Netze komplett freigeben und erst wenn es funktioniert dann weiter einschränken
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Alles klar. werde ich genau so nochmal probieren, wenn ich Ende der Woche wieder dort bin.
Und auch sämtliche mögliche IPs werde ich noch einmal großzügig freigeben.

Vielen Dank soweit!
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
@Fusion

Hallo erstmal.
Habe die NFS Verbindung noch einmal wie von dir beschrieben über Netzwerkfreigabe hinzufügen versucht. Leider klappt es nicht. Habe es mit nfs:// und ohne versucht, habe den Pfad komplett ausgeschrieben 192.168.178.x/volume1/... und um den Ordnernamen abgekürzt. Leider tut sich gar nichts.

Auf der Suche nach weiteren möglichen IPs, die ich evtl. noch in der NFS-Freigabe eintragen muss, ist mir allerdings folgendes aufgefallen:
Ich habe mir die IP vor Verbinden mit dem VPN-Server angeschaut. Also die, die mir der VPN manager ausgibt. Das ist die externe IP. Nach Verbinden mit dem VPN manager ändert sich diese dort dann in die korrekte externe IP am Standort des Servers.
Beide habe ich freigegben.
Dasselbe habe ich mit der in den Systeminformationen von LibreElec angezeigten IP gemacht. Dort wird die lokale IP angezeigt. DIese bleibt allerding vor- und nach Verbinden mit dem VPN Server ein und diesselbe :/ , also die des Heimnetzes am Client-Standort.
Evtl. bietet das einen Ansatzpunkt?

Außerdem habe ich die IP freigegeben, die der VPN Server unter "verbundene Benutzer", also als verbunden anzeigt.

Bin echt ratlos...
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Für die NFS Freigabe würde ich erst mal die 192.168.178.0/24 und 192.168.188.0/24 oder welches Netz du auf Client-Seite verwendest in den NFS Einstellungen des Gemeinsamen Ordners angeben.
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Es hat jetzt funktioniert. Kann nicht sagen warum jetzt plötzlich... schätze das Discovery hat die Probleme verursacht, wie du auch schon geschrieben hast.
Hatte bereits für einen Testordner sämtliche mögliche IP Bereiche für NFS freigegeben. Genauso auch an der Firewall.
Habe dann mit den anderen Funktionen der Freigabe experimentiert. Statt nur Lese- auch eine Schreibberechtigung erteilt, da ich "alle Benutzer zu Admin" aktiv hatte dann auch dem Admin sämtliche Berechtigungen gegeben (zuvor nicht, da ich keinen Benutzer als admin aktiv habe) und noch ein paar weitere Dinge und eben nach jeder Änderung erneut mit dem Discovery versucht den VPN anzupingen.
Irgendwann ging es dann plötzlich. WIe sich dann aber rausgestellt hat, hatte alles was ich eben beschrieben habe nichts damit zu tun. Habe dann alles Schritt für Schritt wieder ausgeschlossen und theoretisch hätte es auch vorher schon funktionieren können.

Die IP bzw. der IP-Bereich, die freigegeben werden muss ist diejenige, die im VPN-Server als dynamische Adresse angegeben ist. Standard ist hier glaube ich 10.8.0.1. Als letzte Ziffer dann eben die, die dem Client zugewiesen wird.
In der FIrewall reicht die Freigabe des VPN Ports. DIeser muss an beiden Routern dann auch freigegeben und weitergeleitet sein. Mehr ist nicht notwendig. Leseberechtigung reicht in der NFS-Freigabe auch.
Im DIscovery reicht bei "Netzwerkverbindung hinzufügen" unter NFS die EIngabe der lokalen Server IP, ohne nfs:// oder weiterer Pfad.

Vielen Dank für Deine Hilfe und schönen Sonntag noch!
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Schön.

Die IP des Clients aus dem entfernten Netz funktioniert nicht für die NFS Freigabe?
Weil IP aus dem VPN-Bereich ist unschön, aber nun gut ....

Gleichfalls schönen Abend...
 

noobo

Benutzer
Mitglied seit
13. Okt 2017
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Jetzt hast du mich doch nochmal neugierig gemacht :)

Die IP des Clients aus dem entfernten Netz funktioniert leider nicht für die NFS Freigabe... War für mich auch das naheliegendste.

Warum meinst du denn ist IP aus dem VPN-Bereich unschön? Bringt das irgendwelche Nachteile mit sich?
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Nachteil per se nicht.
Die IPs sollten normal auf das Transfernetz beschränkt bleiben. Aber ich bin da auch nicht der ultimative Experte für.
u.a werden sie dynamisch vergeben, was bei mehreren Clients schnell unschön sein kann, wenn man für spezifische IPs davon Zugriffsregeln oder ähnliches einrichtet und dann plötzlich ein anderer Client der diese Rechte nicht haben sollte übernimmt. Nur so als Beispiel.
In deinem beschränkten Einsatzszenario dürfte das nicht so kritisch sein.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat