bridge openvpn tap-device udp prob mit autorun.sh

  • Hallo erstmal,


    Trotz diverser Problemberichte in anderen Foren zum Thema qnap und gebridgetes OpenVPN auf Basis eines tap-devices mit udp-Protokoll, habe ich mir ein NAS-TS 110 gekauft und einen OpenVPN-Client zur Anbindung an einen Linux-Server gescriptet.
    Man soll ja nicht nur nehmen, sondern auch geben. Deshalb hier für alle dies interessiert das Ergebnis. Das Ding funktioniert seit Tagen einwandfrei und hält klaglos die Verbindung offen - wies soll ;)


    Bash
    #!/bin/sh##################################################################################################### Startvorbereitung und Start von OpenVPN # auf dem NAS-TS 110. Wird aufgerufen von der autorun.sh# bzw kann in die autorun.sh gelinkt werden.# Liegt in /share/HDA_DATA/.qpkg/Optware/etc/openvpn/start.sh# Bei den derzeitigen Einstellungen wird ein TAP-Device erstellt# und die Verbindung erfolgt gebrückt, d.h. im selben Subnetz wie# der angesprochene Server auf Basis des udp-Protokolls########################################################################################## parameter-declarations## search-pathsPS="/bin/ps"GREP="/bin/grep"MKDIR="/bin/mkdir"RM="/bin/rm"PING="/bin/ping"INSMOD="/sbin/insmod"LSMOD="/sbin/lsmod"IFCONFIG="/sbin/ifconfig"ROUTE="/sbin/route"OPENVPN="/share/HDA_DATA/.qpkg/Optware/sbin/openvpn"BRCTL="/opt/sbin/brctl"## variablesbr="br0"eth="eth0"tap="tap0"eth_ip="10.1.1.101"eth_netmask="255.255.255.0"eth_gateway="10.1.1.200"MNLogDir="/share/HDA_DATA/.qpkg/Optware/etc/openvpn/log"MNLogFile=$MNLogDir"/boot.log"MNDebug=1########################################################################################## Routine zur Logbucherstellung beim Boot des NAS########################################################################################## Function log()log(){	local logtext="$1"    # ether no debug-message or debug-message and debug-flag set    if ( test $# -lt 2 ) || ( ( test $# -eq "2" )  && (($MNDebug)) ); then        # Protokollierung        if !(test $MNLogFile = ""); then            echo -n $(date +%c)' : ' >> $MNLogFile            if (test "$logtext" = ""); then                echo $0				 >> $MNLogFile            elif (test "$logtext" = "-"); then                echo "--------------------------------------------------" >> $MNLogFile            else                echo $logtext		 >> $MNLogFile            fi        fi        # all right to log-file        chmod 777 $MNLogFile    fi}# eoFunction#########################################################################################log "last vpn-check" -debug# create log-dir$MKDIR -p $MNLogDir# und alte log-Datei löschen$RM $MNLogFilelog "preparing boot of openvpn"# wait for DSLlog "waiting for internet connection" -debuguntil ($PING -c 1 www.heise.de > /dev/null 2>&1); do     sleep 5 done log "internet online" -debug# load modul for tun$INSMOD /usr/local/modules/tun.ko > /dev/null 2>&1if ($LSMOD | $GREP tun); then     log "found tun-modul" -debugelse    log "no tun-modul" -debug    exitfi# load modul for bridge$INSMOD /usr/local/modules/bridge.ko > /dev/null 2>&1if ($LSMOD | $GREP bridge); then    log "found bridge-modul" -debugelse    log "no bridge-modul" -debug    exitfilog "system ready all modules present" -debug# create a tap-device if not presentif !($IFCONFIG -a | $GREP tap0); then    # we need a tap-device for a brigded system -> lets do it    $OPENVPN --mktun --dev tap0    # if something went wrong    if [ ! $? ] ; then        log "creating tap-device went wrong!" -debug        exit 1    fi    # check it    until ($IFCONFIG -a | $GREP tap0); do        sleep 1    done    log "tap0 device created" -debugfi# create the bridge if not presentif !($IFCONFIG -a | $GREP br0); then    # add a bridg    $BRCTL addbr $br    log "bridge $br created" -debug    # addd eth in    $BRCTL addif $br $eth    log "eth-device $eth tied to the bridge" -debug    # add tap in    $BRCTL addif $br $tap    log "tap-device $tap tied to the bridge" -debug    # set them to promisc-mode    $IFCONFIG $tap 0.0.0.0 promisc up    $IFCONFIG $eth 0.0.0.0 promisc up    log "both devices set into the promisc-mode" -debug    # put the address back to the bridge    $IFCONFIG $br $eth_ip netmask $eth_netmask    log "given ethernet-ip $eth_ip to the bridge" -debug    # and give default gateway to the bridge    $ROUTE add default gw $eth_gateway $br    log "set default route $eth_gateway to bridge $br" -debugfi # starting OpenVPN$OPENVPN --config /share/HDA_DATA/.qpkg/Optware/etc/openvpn/openvpn.conf --daemon# check the whole thingif ($PS ax | $GREP openvpn | $GREP -v grep > /dev/null 2>&1); then    log "openvpn ready to go" -debugelse    log "openvpn not started" -debugfi############################################ eof start.sh


    Ich habe - wie man sehen kann, peinlich drauf geachtet, daß alle Pfadangaben komplett sind. In der Konsole funktionierts auch ohne - allerdings scheint das Environment während des Bootvorgangs erheblich eingeschränkter zu sein.


    Nun zum Thema meiner Frage:
    Wie gesagt aus der Konsole läufts einwandfrei, starte ich das Script allerding als autorun.sh dann führt er die Zeile

    Code
    $OPENVPN --mktun --dev tap0


    nicht korrekt aus. Übergeht die Abarbeitungsprüfung

    Code
    # if something went wrong    if [ ! $? ] ; then        log "creating tap-device went wrong!" -debug        exit 1    fi


    sang- und klanglos als wäre alles in Ordnung und verläuft sich

    Code
    # check it    until ($IFCONFIG -a | $GREP tap0); do        sleep 1    done    log "tap0 device created" -debug


    dann in der until-Schleife - eigendlich ordnungsgemäss, da das Tap-Device nicht korrekt erstellt wurde . . . .


    Nun bin ich ein leidlicher Scripter unter full-featured Liunuixiden, die abgespeckte Umgebung des NAS ist für mich Neuland. Habs auch als Cron-Job versucht, da tut sich das ganze mit Prüfroutinen wie


    Code
    if !(ps ax -a | $GREP openvpn | grep -v grep); then . . .


    unglaublich schwer . . . hab auch schon an at-jobs gedacht, um eine vernünftige Arbeitsumgebung nach dem Start zu erhalten. Da kann ich - neben der Tatsache ob es at überhaupt fürs nas gibt - nicht einschätzen, ob sich der Installationsaufwand dafür lohnt.


    Vielleicht gibts ja bei Euch einen NAS-hardcore-Spezie, der mir weiterhelfen kann oder es hat jemand eine Idee, die mich weiterbringt. Bin für alle Schandtaten offen ;)

  • Hi David,


    danke für Deine Antwort. Ich möchte die Qualität Deines Genitals nicht in Zweifel ziehen :P und ich bin weiß Gott kein Experte in Sachen qnap, aber ich dachte, ich hätte das durch die Nutzung des Originalpfades sichergestellt :


    Code
    OPENVPN="/share/HDA_DATA/.qpkg/Optware/sbin/openvpn"


    Ich hatte die Geschichte mit der Verfügbarkeit der /opt-Pfade so verstanden, daß nur diese entsprechenden Links erst später während des Boots zur Verfügung ständen. Bezieht sich das auch auf die Ursprungspfade?


    Wenn das so sein sollte, habe ich da einen gewaltigen Gedankenfehler gemacht :shock: . Falls nicht, würde ich Dich bitten, doch mal einen Blick in das Script zu werfen. Hab mir ja nach dem Forenhinweis: "[ Wichtig ] fragen aber wie" von Christian extra die Mühe gemacht so erschöpfend und ausführlich wie möglich alle Informationen als Diagnosehilfen zur Verfügung zu stellen ;)


    Nichtsdestotrotz ist das genau die Stelle wo das zum Tragen käme, insofern war Deine Annahme durchaus logisch :thumb: . Also betrachte meine Stellungnahme nicht als Kritik, sondern als ernstgemeinte Frage . . .


    danke erstmal


    piet

  • Hatte auch mal irgendwo ein Script gehabt, bei dem ich den Absoluten Ursprungspfad Pfad genutzt hatte. Das hatte sich ebenfalls fast genau so seltsam verhalten. (Ist aber auch schon 1 - 2 Jahre her) ;)
    Mit dem wait in der autorun hatte das nachher via /opt sogar funktioniert....


    Probiere es auch mal aus. ;) Wenn es dann nicht funkt, werde ich mir das Script angucken. ;)


    Grüsse, David. ;)

  • Hi David,


    ich hatte gestern schon versucht, entsprechendes einzubauen.


    Code
    # wait for /opt-dir to be ready
    until (grep /opt/bin /etc/profile); do 
        sleep 5
    done


    Jetzt hab ich für mich nicht nachzuvollziehende Effekte, die ich verzweifelt versuche zu durchblicken - bisher ergebnislos. Das Debuggen von Fehlern ist ja wirklich unglaublich aufwändig . . .


    Auf einmal sind bei mir die Suchpfade für /opt/bin etc. verschwunden, so daß die Warteschleife nichts bringt. Dann ist auf einmal /opt eine feste Dateistruktur in der die aufgerufenen Programme ihre Libraries nicht wiederfinden. Dabei könnte ich wetten, daß das gestern noch ein Link war.


    Sag mal, gibts da keine Doku dazu, wo man das mal nachlesen kann? Ich hab mir schon die <unofficial tips& howto guides> runtergeladen, konnte da aber auch nichts wirklich zu dem Thema finden.


    Im Moment bin ich da ein wenig hilflos bzgl. der weiteren Vorgehensweise. Ich bin kurz davor, nochmal das ganze System plattzumachen, denn ich durchschaue ehrlich gesagt noch nicht, wos da hakt . . .


    Für weitergehende Hilfe wäre ich dankbar . . . :|

  • Sorry, wenn ich mich da irgendwie mißverständlich ausgedrückt haben sollte . . .


    Also die Pfade sind weg, die müssen ja aber wahrscheinlich bei jedem Start neu gesetzt werden. Mein Hauptproblem ist, daß die ganze Dateistruktur /opt jetzt offensichtlich kein Link mehr ist, wobei ich wetten könnte, daß das vor ein paar Tagen noch einer war. Die vermutliche Folge davon ist, wenn ich unterschiedliche Programme aufrufe (mc, openvpn . . .) dann melden die beim Start, daß sie ihre Libraries nicht finden können ( . . . und starten dann natürlich nicht, obwohl sie im lib-Verzeichnis vorhanden sind). Da stimmt mit der ganzen Dateistruktur oder den entsprechenden Suchpfaden was nicht - würde ich mit meinem leihenhaften Verständnis vermuten . . . da ich den "Normalzustand" allerdings nicht kenne, fehlen mir da die Ideen für die weitere Vorgehensweise.


    danke für Deine Geduld :)

  • No Prob. ;)


    Poste mal bitte Deine autorun.sh, und mache mal 'nen Directory listening des /opt und des UR-Pfades. ;)
    Das wäre etwas einfacher. (Mal drüberschauen) :thumb:

  • Hi David,


    mhhhh. Irgendwie reden wir aneinander vorbei - denke ich. Meine autorun.sh ist - wie in dem Howto(s.o.) empfohlen - ein Link auf die Datei (s.o.), die Du so wehement vermeidest zu beäugen. Ich könnte sie Dir auch nochmal zumailen, wenn Du möchtest.


    Schlimmer noch scheinen mir die eigenartigen Effekte mit dem /opt-Verzeichnis . . . Wenn ich es normal von der Console aus anzeigen lasse erhalte ich:


    Code
    [~] # ls /optnasconfig_fs.img.tgz


    vom winscp aus verhält sich das etwas anders. winscp zeigt mir nach dem Wechsel in /opt die entsprechenden (zu erwartenden Unterverzeichnisse)

    Code
    binetcincludeliblibexecmansbinsharetmpvar   und die DateiOptware-ipkg.sh


    klar ist aufgrund der Anzeige
    /share/HDA_DATA/.qpkg/Optware des Pfades, daß winscp den Inhalt der Linkquelle anzeigt.


    Selbst mit explizitem Wechsel


    Code
    [~] # cd /opt[/opt] # lsnasconfig_fs.img.tgz


    kommt das allerdings nicht zu Tage.


    Das kann ich irgendwie nicht so ganz nachvollziehen. Das scheint eine Eigenart dieses abgepeckten Systems zu sein oder da ist wie gesagt am Dateisystem was faul . . .


    die Root mit ls aufgelistet zeigt:


    Code
    [/] # ls
    Qmultimedia@ flashfs_tmp/ linuxrc@     php.ini@     sbin/        tmp/
    bin/         hd_root_tmp/ lost+found/  play/        share/       usr@
    dev/         home@        mnt/         proc/        stunnel.pid  var/
    etc/         lib/         opt/         root/        sys/


    und da siehts wieder nicht so aus, als wäre es ein Link . . . :-/


    Wie gesagt ich weiß nicht, was ich davon halten soll. Irgendwo in Eurem Forum meine ich vor Tagen einen Beitrag gelesen zu haben, wo jemand das /opt-Verzeichnis immer wieder gelöscht und dann als Link wieder angelegt hatte. Konnte diesen Beitrag aber nicht wiederfinden. Außerdem würde mich echt interessieren, worin solche Maßnahmen begründet sind und woher solche eigenartigen Verhaltensweisen kommen . . .


    Was für ne verrückte Nummer . . . hoffe Du weißt da mehr . . .

  • Hi Piet,


    Nein, wir reden nicht wirklich voneinander vorbei, hat aber bald nichts mehr mit dem eigentlichen Thema zu tun. ;)
    Zu WinSCP und Co kann ich nix sagen, ich weiss auch nicht, wie WinSCP Symlinks anzeigt / behandelt. Es gilt das was Der SSH Client ausgibt. (Bei Windows also Putty) ;) Also bitte bleiben wir bei einer SSH Session via Putty. ;)


    Bitte lasse mal folgendes ausgeben:

    Code
    ls -l / | grep opt


    Weil so weiss ich immer noch nicht wo das /opt bei Dir hinzeigt.


    Wenn es ein Symlink ist, dann kannst Du den auch mit einem rm löschen und einem ln -s wieder erstellen.

    Code
    rm -rf /opt


    Code
    ln -sf /share/MD0_DATA/optware/opt /opt


    Das kannst Du nach der ausgabe von dem ls -l ebenfalls mal ausprobieren, und danach nochmal ein ls -l hinterher. ;)


    So sollte es dann auch was anderes als die nasconfig_fs.img.tgz ausgegeben werden. (I hope) :thumb:


    Zitat

    Außerdem würde mich echt interessieren, worin solche Maßnahmen begründet sind und woher solche eigenartigen Verhaltensweisen kommen .


    Das kann man erst sagen wenn man mal auf das System drauf schaut, und sich die Modifizierungen anschaut. Da kommen 1000sende Gründe in verdacht. ;) Deshalb ist es doch immer etwas kniffelig. ;)



    Grüsse, David

  • Hi David,


    Code
    [~] # ls -l / | grep optdrwxr-sr-x    2 admin    administ     1024 Oct 14 00:43 opt/


    so siehts die Ausgabe bei diesem Befehl aus.


    Die anderen beiden Befehle sollen ja wohl den Link löschen und dann neu erstellen. Leider gibt es bei mir kein /share/MD0_DATA/optware/opt. Wahrscheinlich liegt das daran, daß es sich bei meinem NAS ja um ein TS-110 handelt. Wenn ich mit dieser Pfadangabe den Link versuche neu zu erstellen, wird das wohl nicht funktionieren - denke ich . . . oder mache ich da einen Gedankenfehler?


    Der Ursprungspfad meines </opt> sollte der von mir angegebene Pfad </share/HDA_DATA/.qpkg/Optware> sein. Der Inhalt dort sieht so aus:


    Code
    [~] # ls -l /share/HDA_DATA/.qpkg/Optware-rwxr-xr-x    1 admin    administ     1948 Aug 31  2008 Optware-ipkg.sh*drwxr-xr-x    2 admin    administ     4096 Nov 27 00:40 bin/drwxr-xr-x    6 admin    administ     4096 Nov 27 00:40 etc/drwxr-xr-x    4 admin    administ     4096 Nov 27 00:40 include/drwxr-xr-x    7 admin    administ     4096 Nov 27 00:40 lib/drwxr-xr-x    3 admin    administ     4096 Nov 27 00:35 libexec/drwxr-xr-x    3 admin    administ     4096 Nov 27 00:40 man/drwxr-xr-x    2 admin    administ     4096 Nov 27 12:23 sbin/drwxr-xr-x   12 admin    administ     4096 Aug 22  2008 share/drwxr-xr-x    2 admin    administ     4096 Nov 27 00:16 tmp/drwxr-xr-x    3 admin    administ     4096 Nov 27 00:40 var/[~] #


    Also soll ich:

    Code
    rm -rf /opt


    und danach:

    Code
    ln -sf /share/HDA_DATA/.qpkg/Optware


    ausführen?


    (Also das ist wirklich kein Versuch Dich irgendwie vorzuführen, sondern ich bin ernsthaft verunsichert)


    piet

  • Zitat

    (Also das ist wirklich kein Versuch Dich irgendwie vorzuführen, sondern ich bin ernsthaft verunsichert)


    Nene, so hatte ich das auch die ganze Zeit nicht aufgefasst, sonst hätte ich das schon geschrieben :D


    Das /opt ist schon einmal kein Symlink...
    Sieht dann so aus:

    Code
    lrwxr-xr-x  1 admin  admin       37 Oct  8 02:40 zf -> /share/MD0_DATA/optware/opt


    Was bei mir
    MD0_DATA ist, ist bei Dir HDA_DATA. ;) Das HDA hast Du bei den 1xx Modellen mit einer Festplatte... :oops:


    Da sich bei Dir im /opt ja nix "wertvolles" ausser der nasconfig_fs.img.tgz befindet, kannst Du das /opt eigentlich getrost löschen.
    Kopiere Dir die Datei aber mal vorher am besten in einen anderen Pfad...


    Hier mal alle Schritte hintereinander:

    Code
    mkdir -p /share/Public/backup_opt


    Code
    cp -R /opt /share/Public/backup_opt


    Code
    rm -rf /opt


    Code
    ln -sf /share/HDA_DATA/optware/opt


    Danach müsste die Datei kopiert und Du müsstest einen Symlink von /opt haben.
    Seltsam ist dieses Problem aber schon, Du musst halt mal schauen, ob das /opt danach ach nach dem Neustarten des NAS richtig gelinkt wird.
    Machen wir aber mal eines nach dem anderen. ;)

  • Hi David,


    die Befehle sind alle soweit durchgelaufen - bis auf den letzten, denn - wie ich bereits geschrieben habe - auch den Pfad (/share/HDA_DATA/optware/opt) gibts bei mir nicht.


    Ich habe Dein Einverständnis vorausgesetzt - um das ganze abzukürzen - den Befehl hierhin abgeändert:

    Code
    [/] # ln -sf /share/HDA_DATA/.qpkg/Optware /opt


    Damit gibts dann auch einen Link auf /opt mit Inhalt:

    Code
    [/] # ls -l /optlrwxrwxrwx    1 admin    administ       29 Dec  8 08:49 /opt -> /share/HDA_DATA/.qpkg/Optware/


    Ich hoffe das war in Deinem Sinne . . .


    piet


    EDIT:


    . . . nach dem Reboot siehts dann allerdings wieder aus wie vorher . . .


    Code
    [~] # ls /opt
    nasconfig_fs.img.tgz


    . . .

    Einmal editiert, zuletzt von christian () aus folgendem Grund: Doppelte Beiträge sind zu vermeiden, siehe Forenregeln!

  • Für die Leser:


    Es haben sich noch andere Probleme bemerkbar gemacht darum geht es für uns Beide erst mal via Remote weiter. ;)