[iNOB]

Das Filesystem war nach Prüfung ok. Starten lies sich Kiste trotzdem nicht. Erst als ich mit "verbose" startete, kam ein TV-Bild. Hab dann openvpn deinstalliert und voila... schon fluppte es wieder. Da scheint noch was bitter im Argen zu liegen mit dem openvpn-Paket.

Hab eigentlich nur das Paket installiert und meine VPN-Conf nach /etc/openvpn kopiert. Dann das tun Modul unter "Module/Add to force load list" und als Startargument <OPENVPN_ARGS="--config /etc/openvpn/blabla.conf"> in die rc.config eingetragen. Allerdings geht der Rückkanal nicht, da fehlt noch eine IPtables Regel. Der Tunnel kam zwar zustande, aber durch ging nix. Egal booten tat er auch ohne funktionierendes VPN. Ein Tag später ging dann nix mehr.

Anscheinend verhindert openvpn eine vollständige Abarbeitung des Startscripts....

[clausmuus]

Danke für die Beschreibung. Ich glaube ich weiß was da schief lief. Ich hatte versucht dafür zu sorgen, dass das openvpn so gestartet wird, das alle weiteren Dienste die vom netzwerk abhängig sind erst nach dem openvpn gestartet werden. Das funktionierte möglicherweise nicht so wie ich das gemacht hatte.
Bitte mal testen ob das jetzt wieder funktioniert. Falls ja, muss ich mir dafür was anderes einfallen lassen.

Claus

[Wanninger]

Das mit dem "zersägten Filesystem" hatte ich auch nur auf dem RPI3 beobachtet...
Ich werde mal das neue Paket auf dem RPI3 ausprobieren, und dann berichten.

[Wanninger]

Ersten Tests zufolge, läuft das aktuelle openvpn Paket wieder ohne weitere Probleme auf dem RPI3.

-Wanninger

[clausmuus]

OK, dann war der mit der letzten Version lediglich beim Booten hängen geblieben.

Claus

[iNOB]

Muss den Thread hier nochmal aufgreifen.

Ausgangslage: MLD-Client stellt per VPN (Paket openvpn aus MLD5.1 stable) einen Connect zum Wartungsserver her. Der Tunnel wird zwar aufgebaut, allerdings geht nichts durch (egal von welcher Seite), da das automatische Erstellen der Routen fehlschlägt. Die vom Server gepushten erforderlichen Routen, die von openvpn mittels busybox-Befehl z.B. "/sbin/ip route add 193.44.0.50/32 via 192.168.2.1" auf dem Client erstellt werden sollen, ergeben nur eine Fehlermeldung:

Code: [Select]

BusyBox v1.25.0 (2016-06-22 12:53:12 CEST) multi-call binary.

Usage: ip [OPTIONS] {address | link | neigh | } {COMMAND}

ip [OPTIONS] OBJECT {COMMAND}
where OBJECT := {address | link | neigh | }
OPTIONS := { -f[amily] { inet | inet6 | link } | -o[neline] }
Sat Sep 24 10:07:29 2016 ERROR: Linux route add command failed: external program exited with error status: 1
Diese kann man zwar über eine Script in der conf zu openvpn auch nachträglich erstellen, aber das sehe ich eher als temporären Workaround da sich die IP-Adressen der gepushten Routen auch ändern können (z.B. externe IP des Wartungsservers).
z.B. openvpn.conf

Code: [Select]

...
script-security 2
up /etc/openvpn/add_route.sh
...
add_route.sh

Code: [Select]

#!/bin/sh
...
route add -net 193.44.0.50/32 gw 192.168.2.1
...
Meiner Einschätzung nach, liegt der Fehler an der Implementierung des ip-Befehls in der busybox, dem das [OBJECT] {route} fehlt (siehe ManPage zu ip). Kann man das bitte korrigieren?

[clausmuus]

OK, ist jetzt im Testing Zweig mit enthalten.

Claus

[iNOB]

Prima... danke!

Hab die aktualisierte busybox mit apt-pinning installiert. Jetzt kommt ein neuer Fehler:

Code: [Select]

Sat Sep 24 14:37:41 2016 /sbin/ip route add 193.44.0.50/32 via 192.168.2.1
ip: RTNETLINK answers: Invalid argument
Sat Sep 24 14:37:41 2016 ERROR: Linux route add command failed: external program exited with error status: 2
Jetzt scheint er sich noch an dem "via" zu stören. Keine Ahnung was der busybox da noch fehlt

[clausmuus]

Ich kenne mich mit vpn leider gar nicht aus. Da muss sich jemand anderes zu äußern, oder Du musst ein wenig recherchieren.

Claus

[iNOB]

Das hat nichts mit openvpn zu tun, sondern eher damit was die busybox kann oder auch nicht. openvpn benutzt nur die verfügbaren Systembefehle, um den Tunnel mit den vom Server vorgegebenen Routen zu erstellen. In dem Fall kennt der Systembefehl"/sbin/ip route add" den Zusatz "via" eben nicht und schmeisst den Fehler raus.

[clausmuus]

Und ohne geht's nicht? Andere User kamen bisher ohne aus...

Einzige Alternative wäre ansonsten das iproute2 Paket für die MLD zu bauen. Oder das ip tool einfach vom Debian (oder aus dem Debian Paket) auf die MLD Kopieren.

Claus

[iNOB]

Wenn ich mir den Sourcecode vom ip-Befehl der busybox ansehe, gibt es dort den Parameter "via" nicht den openvpn verwendet. Insofern wäre es nicht dumm, iproute2 in ein Paket zu packen. Dann funktioniert das auch wie angedacht und schmeisst beim Start von openvpn keine Fehler mehr raus.

Man kann die Routen auch mit dem vorgenannten Script adden. Allerdings mit dem Nachteil, dass die Fehlermeldungen nicht verschwinden und bei wechselnder externer IP (Dyn-Adresse) das Ganze in die Hose geht.

[clausmuus]

Nur mal interessehalber. Ist das was Du da machst etwas exotisches, oder eher der Regelfall?

Claus

[Wanninger]

@claus

Du hast zwar nicht mich gemeint, aber ich kann Dir aus meinem Umfeld sagen,
dass das durchaus der Regelfall ist. Es ist eher exotisch/veraltet über extra
Scripte die über die OVPN Conf definiert werden, das Routing zu beeinflussen.

-Wanninger

[clausmuus]

ne, meine Frage war eher, ob dieses "via" was exotisches ist.

Claus