Filetransfers schlagen fehl

Hallo, falls du dich fragst, ob wir Teamspeak 5 Beta Keys haben, nein diese haben wir nicht und erhalten auch keine von Teamspeak. LG dein TScon Team
  • Hallo,


    vielleicht kann mir ja jemand von euch weiterhelfen.


    Ich habe hinter einem Router einen Server stehen und leite den TCP Port 30033 an den Ziel-Rechner/Server, worauf der TeamSpeak 3 Server läuft weiter. Wenn ich dann versuche, eine Datei hoch zu laden, erhalte ich folgende Fehlermeldung:

    Quote

    <16:35:56> Transfer "001_Pizza_Flyer.jpg" berichtet: (could not open file transfer connection)


    Laut meiner Firewall ist der Port jedoch weitergeleitet:


    Und wenn ich das Remote auch überprüfe, ob der Port offen ist oder nicht, erhalte ich ebenfalls ein OK als Meldung:


    In der Log-Datei des virtuellen Servers steht folgendes drin:

    Quote

    2014-06-19 14:35:11.650254|INFO |VirtualServer | 2| file upload to (id:30), '/001_Pizza_Flyer.jpg' by client 'Sebbo'(id:8)
    2014-06-19 14:35:55.940286|INFO |VirtualServer | 2| file deleted from (id:30), 'files/virtualserver_2/channel_30//001_Pizza_Flyer.jpg' by client 'Sebbo'(id:8)
    2014-06-19 14:36:11.957084|WARNING |FileTransfer | 2| Failed to remove files/virtualserver_2/channel_30/001_Pizza_Flyer.jpg


    Die Datei wird also angelegt, ist aber leer - Dateigröße 0 Bytes. So... Warum funktioniert der Transfer jetzt nicht? Die Rechte für den Upload sind gesetzt, also liegt es daran nicht.


    Ich nutze für den TeamSpeak Server übrigens eine INI-Datei:


    Ich dachte erst, es kann daran liegen, dass die IPs in der INI-Datei nicht die öffentlichen, sondern die privaten sind. Einerseits dachte ich mir jedoch auch, dass man dort die IP-Adresse angeben muss, worauf der TS Server lauscht und der lauscht ja auf der lokalen Netzwerkschnittstelle, also auf der privaten IP.


    Ich hoffe, mir kann jemand weiterhelfen.

  • Mich auch, aber ein Versuch ist es Wert.


    Hast nur du das Problem?
    Ist der Pfad richtig(also Serverseitig)?
    Ist es nur mit Bildern oder auch mit allen anderen Dateien(zip, usw)?

  • Der Port wird nur dort verwendet, aber selbst mit einem anderen Port schlägt es fehl...


    Und ja, der Port ist freigeschaltet - er wird auch als "offen" angezeigt: Filetransfers schlagen fehl


    https://www.teamspeak-connecti…ehl/?postID=2082#post2082

    Schau mal ob der Raum als Ordner überhaupt angelegt worden ist.


    Ah, okay. Ja, das existiert und wenn ich über den Client ein Verzeichnis erstelle, wird das auch angelegt. Lediglich der Dateitransfer funktioniert nicht.

    Code
    1. $ find files/ -name test
    2. files/virtualserver_2/channel_30/test
  • Nein, der Upload steht auf -1, also auf unbegrenzt.


    Ah, okay... Wir kommen dem Ziel näher. Es liegt an einer falschen Konfiguration der Firewall/des Routers bzw. der INI-Datei des TeamSpeak 3 Servers, denn mein Client meldet mir eine sehr hilfreiche Meldung:

    Code
    1. 19.06.2014 21:34 FileTransfer Error Failed to open filetransfer tcp connection to 192.168.178.240:30033
    2. 19.06.2014 21:35 ClientUI Error Error getting transfer sender state


    Mein Client wartet also auf eine Antwort von der privaten IP-Adresse. Er sollte jedoch auf eine Antwort von der öffentlichen warten, darum timet er irgendwann aus und der Filetransfer schlägt somit fehl. Jetzt ist die Frage: Wie sag ich dem TeamSpeak Server per INI-File, dass er dem Client die öffentliche mitteilen soll? Wenn ich die öffentliche IP eintrage, bringt der Server die Fehlermeldung, dass er die IP nicht binden kann - ist auch logisch, da sie nicht auf seiner Netzwerkkarte liegt. Wenn ich einfach garkeine IP angebe, startet der Server erst garnicht, weil er dann sagt "converting bind() IP failed".

  • Weder noch.


    Der Server steht im Rechenzentrum, wobei der folgende Aufbau gilt:


    WAN -> Router & Firewall -> Server mit TeamSpeak Server


    Die Firewall maskiert alle privaten IP Adressen nach außen - nach innen verändert sie jedoch nichts. Der Router selbst leitet per NAT den TCP Port 30033 an den Server weiter.


    Die Firewall-Regel für den Filetransfer sieht wie folgt aus:

    Code
    1. iptables -t nat -A PREROUTING -d 194.10.20.30 -p tcp --dport 30033 -j DNAT --to-destination 192.168.178.240 -m comment --comment "TeamSpeak Filetransfers"
  • Ja, die Regeln meinte ich ja mit maskieren:

    Code
    1. iptables -t nat -A POSTROUTING -o ${RTR_FW_EXT_IFACE} -j MASQUERADE


    Nein, die Maschine aka der Server, worauf der TS Server läuft, hat eine eigene Netzwerk-Schnittstelle, welche direkt mit dem Router verbunden ist.

  • Nein, der Upload steht auf -1, also auf unbegrenzt.


    Ah, okay... Wir kommen dem Ziel näher. Es liegt an einer falschen Konfiguration der Firewall/des Routers bzw. der INI-Datei des TeamSpeak 3 Servers, denn mein Client meldet mir eine sehr hilfreiche Meldung:

    Code
    1. 19.06.2014 21:34 FileTransfer Error Failed to open filetransfer tcp connection to 192.168.178.240:30033
    2. 19.06.2014 21:35 ClientUI Error Error getting transfer sender state


    Mein Client wartet also auf eine Antwort von der privaten IP-Adresse. Er sollte jedoch auf eine Antwort von der öffentlichen warten, darum timet er irgendwann aus und der Filetransfer schlägt somit fehl. Jetzt ist die Frage: Wie sag ich dem TeamSpeak Server per INI-File, dass er dem Client die öffentliche mitteilen soll? Wenn ich die öffentliche IP eintrage, bringt der Server die Fehlermeldung, dass er die IP nicht binden kann - ist auch logisch, da sie nicht auf seiner Netzwerkkarte liegt. Wenn ich einfach garkeine IP angebe, startet der Server erst garnicht, weil er dann sagt "converting bind() IP failed".


    evtl. hilft dir Netcat weiter...?

    netcat › Wiki › ubuntuusers.de

  • Der Port ist offen, wie ich bereits im ersten Post erwähnt hatte. Sonst hilft mit netcat auch nicht weiter.


    Es liegt aber glaub ich an der Firewall. Weis jemand, wie der TeamSpeak Client die FTP Verbindung aufbaut? Also aktiv oder passiv?


    Bei mir funktioniert nämlich aktuell nur eines von beiden.

  • Kein Plan, ich weiß das ich mal Probleme hatte mit folgendem Szenario:


    Auf IP 1 lief immer nen TS auf Port 9400. Die sind dann auf ne andere Instanz gezogen und ich wollte den Port 9400 weiterleiten auf IP 2, das wollte einfach nicht funktionieren :(