FTP per SSL/TLS (explizit) - keine Verbindung nach IP-Trennu

    Hallo,


    Ich habe ein blödes Problem mit dem FTP Zugang über SSL/TLS (explizit).
    An sich funktioniert das verschlüsselte senden und empfangen, aber nach der bei DSL üblichen 24h Trennung, wird vom QNAP versucht mit der alten IP zu antworten. Deshalb kommt dann keine Verbindung zustande (sieht zumindest im FTP-Client so aus - FileZilla).



    Einstellungen in der TS-219 sind wie folgt:
    3.3.1 Build 0720T


    X FTP-Dienst aktivieren
    Protokolltyp: FTP (Standard)
    X FTP mit SSL/TLS (explizit)
    Portnummer: 21
    Unicode-Unterstützung: Ja
    Anonymer Zugriff aktivieren: Nein



    Verbindung
    Maximalzahl sämtlicher FTP-Verbindungen: 10
    Maximale Verbindungsanzahl pro Benutzer: 5
    X FTP-Geschwindigkeit beschränken
    Max. Upload-Geschwindigkeit (KB/s): 0 KB/s
    Max. Download-Geschwindigkeit (KB/s): 36 KB/s
    Erweitert
    Passiver FTP-Portbereich: Standard-Portbereich verwenden (55536 - 56559)
    Portbereich definieren: -


    X Mit externer IP-Adresse auf passive FTP-Verbindungsanfrage reagieren
    Externe IP-Adresse:



    So, nun bin ich mir bei der letzten Einstellung mit der externen IP-Adresse nicht so ganz sicher und ich vermute, dass daher auch der Fehler kommen könnte. Allerdings kann ich gar keine Verbindung aufbauen, wenn das Häkchen fehlt - und im Forum hatte ich irgendwo gelesen, dass es mit diesen Einstellungen klappen sollte (mit Häkchen und ohne eine IP ins Feld einzutragen).



    Noch zur Info:


    Der DynDNS-client läuft auf der FritzBox - also nicht im QNAP
    offene Ports in der Fritzbox (direkt zum NAS) 55536 - 56559, 21, 80, 443, 8080



    Falls jemand eine Lösung hat, wäre ich sehr dankbar.

    Hi,


    nach dem Reconnect (24 h zwangstrennung) hast Du eine neue IP. Das allerdings managed deine FBF.
    Das heisst, deine "externe (Internet) IP" ändert sich, jedoch nicht die Interne. Das NAS hat damit eigentlich nix am Hut.


    Verpasse deinem NAS mal eine Statische (feste) IP ausserhalb der DHCP Range.
    Die Ports: 80, 443, 8080 kannst Du alle schliessen.
    Ein aktiver FTP benötigt nur den Port: 21
    Ein passiver FTP benötigt die Ports: 55536 - 56559


    Den 8080er solltest Du auf keinen Fall auf machen, Port 80, 443 wäre ok, wenn Du den QNAP eigenen WebServer verwenden möchtest (oder auch WebDAV - dazu komme ich aber gleich). Allerdings müsstest Du dich schon entscheiden ob mit oder ohne SSL (Port 80 ohne, 443 mit).
    Das hat auch nix mit den FTP zu tun. ;)


    Ich allerdings würde Dir zu WebDAV anraten. Das ganze ist nicht komplizierter als ein FTP und halt das "neuere" Protokoll, das wesentliche Vorteile Bietet. Mittels Webdav würdest Du über SSL nur den 443er Port benötigen und jedes Betriebssystem könnte das als normales Netzlaufwerk mounten.
    Schaue Dir ruhig mal die Beschreibung an und probiere es mal aus. (Das kannst Du auch mal parallel zum FTP antesten)
    http://www.qnap.com/de/pro_application.asp?ap_id=237


    Grüsse, David

    Hi zusammen,


    Zitat von "Terz"


    Ich allerdings würde Dir zu WebDAV anraten. Das ganze ist nicht komplizierter als ein FTP und halt das "neuere" Protokoll, das wesentliche Vorteile Bietet. Mittels Webdav würdest Du über SSL nur den 443er Port benötigen und jedes Betriebssystem könnte das als normales Netzlaufwerk mounten.
    Schaue Dir ruhig mal die Beschreibung an und probiere es mal aus. (Das kannst Du auch mal parallel zum FTP antesten)
    http://www.qnap.com/de/pro_application.asp?ap_id=237


    Terz: kannst Du vllt. kurz erläutern warum man 443er Port und nicht das auf der ACP vorgeschlagene 8081 mit Häckchen in "Enable Secure Connection" nutzen soll. Ich finde das irgendwie verwirrend und abgesehen davon funktionierts bei mir so oder so nicht http://forum.qnapclub.de/viewtopic.php?f=45&t=9158... Wäre schöne wenn mir da mal jemand weiterhelfen könnte, vielen Dank!


    Anton

    Hi,


    eigentlich sollte der Port 443 der "standart" Port für SSL sein. (https).
    WebServer ohne SSL laufen default auf Port 80 mit SSL auf 443.
    Es gibt keinen Grund den port umzustellen (sicherer wird es dadurch nicht).
    Wenn man den Port nicht auf den "default" laufen lässt, dann müsstest Du den Port halt noch in der URL angeben.


    Beispiel - SSL über den Default Port 443:
    https://meinedomain.de
    und über einen Manuell eingegebenen Port (hier einfach mal 5000):
    https://meinedomain: 5000


    Der Port 8081 ist default? Das kann ich kaum glauben. :-/ Sieht für mich aber so aus, als ob Du den ACP Port meinst - das sollte man generell eigentlich nie freigeben. (Das AdminCP). Egal mit oder ohne SSL. und intern macht SSL kaum einen Sinn.


    Es ging davor um den QNAP eigenen WebServer über SSL nicht das AdminCP.
    Sind praktisch 2 WebServer auf dem NAS am laufen. Einer für das AdminCP und der andere als "normaler" WebServer.


    Grüsse, David

    Hi Terz,


    danke für die Antwort.


    Mir gehts es eigentlich um den WebDav. Da der WebFileManager bereits über 443er Port läuft, kann ich den nicht mehr für den WebDav verwenden. Wenn ich unter Netzwerkdienst/Webserver den Webserver aktiviere und ein Häckchen bei "sicheren Anschluss (SSL) aktivieren" setze steh der Port 8081 als default drin.


    Mein Problem ist dass wenn ich unter Win7(64Bit) versuche den freigegebenen Webdav-Ordner als SSL-Ordner hinzuzufügen also "https://meinserverdyddns/freigabe" und/oder "https://meinserverdyddns/freigabe:8081", dann fragt der mich zweimal nach meinem Passwort und danach kommt die Meldung "Ordner nicht vorhanden. wählen Sie einen anderen" oder so ähnlich. Ohne SSL funktionierts mittlerweile, kann ich aber nicht gebrauchen!


    Hast Du eine Idee, "amverzweifelnbin"


    Anton

    Also das mit dem WebDav habe ich jetzt auch endlich ausprobiert, es funktionierte erst nach einer kompletten Neuinstallation vom NAS - vorher ist der Webserver immer abgestürzt und meldete sich nach ein paar Sekunden mit einem Reboot wieder... naja, allerdings habe ich per SSL-Verbindung mit WebDav die gleichen Probleme mit der Anmeldung - also zweimal Passwortabfrage und dann eine "nicht verfügbar" Meldung (Win7 64x).


    Aber um nochmals auf das FTP per SSL Problem zurückzukommen, es wird bei mir immer eine "alte" globale IP mit gesendet. Also nach einem Neustart der Box bekommt sie eine aktuelle globale IP - dann funktioniert alles korrekt - wenn sich die IP ändert, wird die "alte" IP mitgeschickt und folglich funktioniert es natürlich nicht mehr.
    Der FTP-Server funktioniert nur, wenn "Mit externer IP-Adresse auf passive FTP-Verbindungsanfrage reagieren" eingestellt ist. Wenn es nun eine Möglichkeit gäbe, im Feld "Externe IP-Adresse:" eine DynDNS einzutragen müsste es meiner Meinung nach funktionieren - Ist dies irgendwie möglich? ich bekomme ja nur Zahlen in die Maske eingegeben...


    Danke schon mal für die vorgegangenen Antworten.

    Hallo zusammen,


    ich habe exakt dasselbe Problem: Obwohl der Haken bei "Respond with external IP address for passive FTP connection request" gesetzt ist und kein Eintrag im Feld "External IP address:" angegeben ist, antwortet meine TS219 immer mit der "alten" externen IP-Adresse auf das PASV-Kommando des FTP-Clients.


    Den Fehler kann man beliebig reproduzieren.


    Ich habe testweise das DDNS direkt vom TS219 aus machen lassen - das bringt kein Unterschied. Interessanterweise ist in den DDNS-Einstellungen auch immer korrekt die externe IP zu sehen und Änderungen bekommt das System innerhalb von Minuten mit - einzig der FTP-Server scheint davon unbeeindruckt und antwortet weiterhin mit der alten Adresse.


    Wie kann man den FTP dazu zwingen, die korrekte IP-Adresse zu verwenden? Ein Workaround wäre auch, den Domainnamen anstelle der IP-Adresse als externe Adresse anzugeben.


    Danke für eure Hilfe und viele Grüße

    Hat niemand eine Idee? Leider ist durch diesen bug das nas im Prinzip nicht zu gebrauchen da ja remote Zugriff praktisch unmöglich ist.


    danke für eure Hilfe und viele Grüße

    Also ich habe mein qnap jetzt erstmal so eingestellt, dass es einmal pro Tag (kurz nach der Zwangstrennung vom dsl) neustartet -> dann klappts mit der neuen IP


    Das ist zwar eine absolut blöde und unsichere Methode (z.B. wenn zwischenzeitlich mal getrennt wird o.ä.) aber an sich klappt es damit erstmal... Bis es eine Lösung für das Problem gibt werde ich das so erstmal beibehalten.

    Hallo und danke,


    OK, damit ist klar, dass das QNAP NAS aufgrund der leider undurchdachten Konfiguration fast ein Fehlkauf war :(. FTP ist per DDNS nicht zu gebrauchen, der ProFTPD aktualisiert den Hostname bei der Qnap Config tatsächlich nur beim Start:

    Zitat

    dann ist jedoch zu beachten, dass diese nur einmal beim start von ProFTPD aufgeschluesselt wird. Bei dynamischen IPs kann man den Server per INETD betreiben, so dass beim jedem Start einer Verbindung die IP aufgeloest wird.

    http://www.proftpd.de/MasqueradeAddress.152.0.html
    Umkonfigurieren auf Inetd oder Installieren eines anderen FTP Dienst oder Umbau des SSH-Servers damit sich auch normale User einloggen können sind mir zu stressig, da hätte ich auch gleich einen echten Linux-Server selbst konfigurieren können.


    Fazit: Problem ist also inhärent und nicht ohne komplexere Eingriffe lösbar. Remote-Zugriff lege ich erstmal ad acta. Danke und Grüße,

    *bump*


    Hat einer vielleicht schon eine Lösung für dieses Problem gefunden?


    Das ist schon echt doof, da auf diese Art leider keine zuverlässige Verbindung aufgebaut werden kann. Und ohne SSL/TLS wollte ich den FTP nicht ans Netz anbinden.

    Hallo,


    ich habe ein ähnliches Problem weiß aber woran es liegt.
    Leider habe ich bisher keine Lösung, aber vielleicht hilft weiter.


    Der QnapServer hat seit einem der letzten Updates 2 Schlüssel für TLS/SSL.
    Einer ist im Januar 2010 abgelaufen. Der zweite geht bis 2020.
    Das Problem ist, dass ich nicht weiß wie ich den ersten los werde, da man in den meisten Programmen den Schlüssel nicht auswählen kann und dieser automatisch übermittelt wird.


    Der Qnap Support hat (trotz wiederholter Anfragen) nicht reagiert und dann erklärt, dass sie "nur ftp und sftp (via ssh) unterstützen", nicht aber FTP mit TLS/SSL.
    Vorher hat es aber anstandslos funktioniert.
    Ich denke wenn jemand weiß wie man das richtige Certificat benutzt dann geht es auch.

    Moin,


    vielleicht habe ich gerade die Lösung für das bestehende Problem mit der IP-Adresse. Im QNAP habe ich spasseshalber einfach mal die 127.0.0.1 unter den FTP-Settings - External-IP-Address eingegeben.
    Die Antwort vom FTP-Client (FileZilla) sieht dann so aus:


    Befehl: PASV
    Antwort: 227 Entering Passive Mode (127,0,0,1,220,103).
    Status: Vom Server gesendete Adresse für den Passiv-Modus ist nicht routingfähig. Benutze stattdessen die Serveradresse.


    Und die Verbindung steht dann. Wenn das nochmal jemand testen könnte wäre das super, bei mir klappts so auf jeden fall.

    @don-quijote


    Das ist sicher ein guter Workaround, setzt aber voraus, dass der jeweilige FTP Client das so unterstützt.


    EDIT:
    Und wie ich gerade festgestellt habe, funktioniert das beim FileZilla nicht, wenn man (z.B. aus einem Firmennetzwerk heraus) über einen SOCKS Proxy gehen muss.
    Das FireFTP Plugin für Firefox funktioniert aber mit der Methode, auch hinter einem SOCKS Proxy.


    Eine andere Methode um das Problem auf der NAS Seite zu lösen, ist das automatische Neustarten des ProFTP, wenn die Zwangstrennung erfolgt ist.


    Dazu habe ich mir folgendes Script geschrieben:


    Bash
    #!/bin/sh## check_ext_ip.sh - check if external ISP ip address has changed and if so, restart proFTP# this script is supposed to be run by cronGET_EXT_IP="/etc/init.d/get_external_ip.sh"LAST_EXT_IP="/tmp/ext_last_ip"LOG_MSG="ISP external IP address has changed - restarting FTP Server."RUN_CMD="/etc/init.d/ftp.sh restart"EXT_IP=$(${GET_EXT_IP})if [ $? -eq 0 ]; then	if [ ! -e ${LAST_EXT_IP} ]; then		echo ${EXT_IP} >${LAST_EXT_IP}	fi		if [ "${EXT_IP}" != "$(< ${LAST_EXT_IP})" ]; then		echo ${EXT_IP} >${LAST_EXT_IP}		/sbin/log_tool -t 0 -a "${LOG_MSG}"		${RUN_CMD}	fifiexit 0


    Dieses Script wird dann via cron alle fünf Minuten (oder welches Intervall man nehmen möchte) aufgerufen. Ändert sich die externe IP Adresse, wird der FTP-Server neu gestartet und im System-Log wird ein entsprechender Eintrag gemacht.


    Den zusätzlichen crontab Eintrag mache ich in der autorun.sh


    z.B.:

    Code
    0,5,10,15,20,25,30,35,40,45,50,55 * * * * /tmp/check_ext_ip.sh


    Cheers,
    Zap

    moin moin
    zaphod42 ich kenne mich noch nicht so mit dem nas aus, wie kann ich dein script auf meinem 212er einrichten? ich hab genau das problem dass ich per filezilla auf das nas zugreifen (lassen) will und immer nach einer zwangstrennung ohne verbindung dastehe

    Moin shaggy,


    sorry, ich habe Deine Frage erst heute gelesen. Mittlerweile ist viel Zeit vergangen und vermutlich hast Du es schon hin bekommen.


    Der Vollständigkeit halber schreibe ich hier noch mal, wie es geht:


    Zunächst musst Du das o.s. Script in einen Editor kopieren (am besten Notepad++ im Unix Modus) und dann in einem Verzeichnis auf dem NAS speichern, oder lokal auf dem PC und dann z.B. mit WinSPC auf das NAS kopieren. Ich habe für solche Dinge unter /share/HDA_DATA ein Verzeichnis ".config" angelegt. Darauf hat nur der admin zugriff. Wenn Du WinSCP verwendest kannst Du damit auch gleich die Execute Rechte für das Script setzen. Ansonsten musst Du mit putty/telnet auf das NAS und die Rechte mit chmod setzen.


    Putty/telnet brauchst Du aber auf jeden Fall um den Cronjob einzutragen. Wenn Du per putty auf dem NAS als admin angemeldet bist und angenommen, Du hast das Script unter /share/HDA_DATA/.config/check_ext_ip.sh abgelegt, gib folgendes ein:


    Code
    chmod u+x /share/HDA_DATA/.config/check_ext_ip.sh
echo "0,5,10,15,20,25,30,35,40,45,50,55 * * * * /share/HDA_DATA/.config/check_ext_ip.sh" >>/etc/config/crontab
crontab /etc/config/crontab
crontab -l


    Mit crontab -l kontrollierst Du die crontab. Der neue Eintrag muss dann in der Ausgabe von crontab -l erscheinen.


    Anders als in meinem o.s. Post geschrieben, muss man die Änderung der crontab nicht über eine autorun.sh machen, da die crontab einen reboot/Neustart des Systems überlebt.


    Das war es dann auch schon. Ich hoffe, es war halbwegs verständlich.


    Cheers,
    Zap