Danke,
die Forensuche bringt aber auch so viel, dass ich den Überblick wieder verloren habe.
Dann werd ich das mal in Ruhe probieren, wenn ich mal Zeit habe.
Vielen Dank für eure Hilfe!
Gruß wolder
Printable View
Danke,
die Forensuche bringt aber auch so viel, dass ich den Überblick wieder verloren habe.
Dann werd ich das mal in Ruhe probieren, wenn ich mal Zeit habe.
Vielen Dank für eure Hilfe!
Gruß wolder
Hi,
@wolder: Bin da eben noch über nen Thread gestoßen. Ist sogar einer von den Sticky-ones. Hier erklärt FastJack wie es mit dem lighthttpd funktioniert.
Ich habe mal wieder ein Update auf Transmission 1.75 gewagt und es scheint soweit alles zu funktionieren. Die Syntax von settings.json hat sich ein wenig verändert, z.B.:
stattCode:"speed-limit-down": 500,
"speed-limit-down-enabled": false,
"speed-limit-up": 20,
"speed-limit-up-enabled": true,
Code:"download-limit": 500,
"download-limit-enabled": 0,
"upload-limit": 20,
"upload-limit-enabled": 1,
und noch ein paar Sachen. Die neue Syntax kann hier nachgelesen werden: http://trac.transmissionbt.com/wiki/EditConfigFiles
Gruß
Robert
Danke für den Hinweis.
Hat jemand von Euch eine aktuelle, funktionierende conf, die ich in das HowTo einfügen kann?
Ich nutze Transmission so gut wie gar nicht mehr...
wengi
Ich werde Dir mal so ein Config-File geben.
Es gibt sonst ein paar merkwürdige Effekte, die ich damals schon mit der Version 1.60 festgestellt habe. Remote GUI 1.2 kann zum Beispiel den verwendeten Port testen, ob er frei ist. Bei mir reportet es, der Port sei zu. Wenn ich eine entsprechende Regel in iptables einbaue, dann reportet es der Port ist offen. Ich kann aber Up- und Downloaden auch wenn der Port laut Transmission/Remote GUI zu ist. Das kommt mir sehr verdächtig vor. Die Firewall scheint also gegen Transmission Client wirkungslos zu sein? Wie kommen die Daten zu und von Transmission an der Firewall/Iptables vorbei? Es sind ja keine expliziten Freigaben für Transmission gemacht worden und trotzdem funktioniert's. :confused:
Gruß
Robert
Weil die Firewall nur nach Aussen dicht macht und Du es aus dem LAN probiert hast?
Zugegeben banal aber denkbar :)
Hi,
versuch doch mal den Transmission über nen DynDns-Host anzusprechen. Dann sollte sich das Verhalten ändern und die iptables werden wirksam. So ist es jedenfalls bei mir. Für "interne" Verbindungen wirken die iptables ja nur dann, wenn du explizit die Schnittstelle angibst.
@Wengi
Nanana, nix LAN, habe ich etwa einen BT-Tracker bei mir im LAN? ;)
@Wengi, carterb
Es geht hier nicht um den Zugriff auf das Webinterface von Transmission. Das Webinterface ist von WAN aus nicht erreichbar (hoffe ich zumindest :rolleyes:) und durch zwei Mechanismen geschützt: 1. Iptables/Firewall des Routers und 2. RPC Whitelist von Transmission.
Es geht um die Kommunikation mit den Peers. Irgendein Peer bekomt vom Tracker die Information, dass er sich mit meinem BT-Client unter einer bestimmten IP/Port verbinden kann und ein paar Pakete abholen kann. Dann versucht er das, wie kommt er da an meiner Firewall vorbei? Das ist hier die Frage. Aber anscheinend funktioniert das irgendwie. Oder laufen alle Verbindungen über den Tracker nach dem Prinzip, dass Transmission zuerst nach draussen kommuniziert und dann eine Antwort bekommt, die die Firewall passieren kann (Defaultregel)? Das würde aber eine ziemliche Last am BT-Traker erzeugen, es heisst ja nicht umsonst Peer-to-Peer. Andererseits muss ich auch gestehen, ich habe vom BT-Protokoll insgesamt zu wenig Ahnung.
Gruß
Robert
Es ist schon so wie Du zunächst vermutet hast.
Die anderen Clients nehmen über IP/Port mit Deinem BT kontakt auf.
(Bei emule z.B. gibts eine LowID wenn Du nicht erreichbar bist...).
Also ist Dein Transmission erreichbar.
Nutzt Du UPNP? Das wäre eine Erklärung.
wengi
Nein, UPNP ist aus. Diese Frage lässt mir keine Ruhe. In den anderen Anleitungen für Transmission gibt es einen Schritt für Portfreigaben in Iptables. Wozu, wenn's auch ohne funktioniert? Vielleicht taugt meine ganze Firewall nichts und ich habe immerhin Samba-Freigaben ohne Benutzerkontrolle im LAN. EDIT: ok, das stimmt nicht ganz, immerhin ist "hosts allow" und "interfaces" gesetzt. Ich sollte echt mal einen Portscan von aussen machen...
Hier, wie versprochen, ein Beispiel für settings.json:
GrußCode:{
"blocklist-enabled": true,
"dht-enabled": true,
"download-dir": "/tmp/harddisk/transmission/download",
"encryption": 2,
"lazy-bitfield-enabled": true,
"open-file-limit": 64,
"peer-limit-global": 250,
"peer-limit-per-torrent": 60,
"peer-port": 51413,
"peer-port-random-enabled": false,
"peer-port-random-high": 65535,
"peer-port-random-low": 1024,
"peer-socket-tos": 8,
"pex-enabled": true,
"port-forwarding-enabled": false,
"preallocation": 1,
"proxy": "",
"proxy-auth-enabled": false,
"proxy-auth-password": "",
"proxy-auth-username": "",
"proxy-enabled": false,
"proxy-port": 80,
"proxy-type": 0,
"rpc-authentication-required": false,
"rpc-enabled": true,
"rpc-password": "",
"rpc-port": 9091,
"rpc-username": "",
"rpc-whitelist": "127.0.0.1,192.168.1.*",
"rpc-whitelist-enabled": true,
"speed-limit-down": 500,
"speed-limit-down-enabled": false,
"speed-limit-up": 20,
"speed-limit-up-enabled": true
}
Robert
Hast Du mal getestet, ob der Port wirklich erreichbar ist?
Also mit telnet IP Port?
Es kann ohne weiteres sein, dass alles so funktioniert wie es soll und Dein transmission nur keine Uploads macht, wenn der Port zu ist.
wengi
Hi Wengi,
ich werde heute Abend mal einen kompletten Portscan an meiner WAN-IP machen. Wenn die Firewall so funktioniert, wie ich erwarte, dann wird nur TCP 21 (FTP) zu sehen sein. Wenn die Firewall komplett durchlässig ist, dann werde ich alle Services im LAN (Dropbear - TCP 22, Samba -???, NFS - TCP 111, Transmission-GUI - TCP 9091) sehen können. Ich tippe selber darauf, dass die Firewall dicht ist und dass ich die Regel, nach der der BT-Traffic passieren kann, einfach nicht verstehe, bzw., dass es doch irgendwie unter die "Defaultregel" (die Antwort auf eine Anfrage darf passieren) fällt.
Gruß
Robert
Um zu sehen, was alles so auf deinem Asus lauscht:
und mit einem externen nmap von hier: http://nmap-online.com/Code:netstat -nape --inet
bekommt man sofort einen Ueberblick, ob Gefahr im Verzug ist.....
newbiefan
Hi Wengi,
tolle Anleitung, vielen Dank dafür!
Ich wollte nur noch ein Paar kleine Anmerkungen machen:
zu 15:
Beim einfügen des öffentlichen Schlüssels muss man aufpassen, dass der Schlüssel in in der Datei authorized_keys in eine Zeile ohne Umbrüche passt (so wie hier). Wenn man den Schlüssel dagegen so wie hier oder hier einfügt, funktioniert das Anmelden nicht. Ich habe es leider nicht gewusst (noch nie dropbear benutzt) und musste mich darüber zwei Tage lang ärgern :D
zu 5 (Zeitzone)
Braucht man das noch für die neue Firmware (1.9.2.7-d)?
In Changelog wird folgendes erwähnt:
Ich weiß allerdings nicht, ob damit das Problem mit der Sommerzeit gelöst wird.Quote:
timezones improved, ability to manual define TZ
Grüße
Thinkpad_fan
@Thinkpad_fan
dass man in den Key keine Zeilenumbrüche einbaut, halte ich für selbstverständlich. Du kopierst ja den Key mit Crtl+C in die Zwischenablage und er enthält keine Zeilenumbrüche. Wie kommt man überhaupt auf die Idee die Zeilenumbrüche einzubauen? Oder hast du den Key abgetippt?
Der Zeitzone-Bug ist behoben! Die Zeitzone GMT+1 DST (Deutschland, Sommerzeit) wird als CET-1CEST,M3.5.0,M10.5.0/3 aufgelöst.
@newbiefan
aus welchem Package hast du netsat nachinstalliert? Frage nur, weil sich die Syntax mit Busybox-Netstat beisst. net-tools?
Wenn Transmission inaktiv ist, dann ist es sehr übersichtlich, ausser der SSH-Session im LAN sehe ich nix verdächtiges.
Und Nmap-Online scheint leider nichts zu taugen, sogar der "Full-Scan" behauptet, alle Ports sind dicht (filtered) und ist nicht einmal in der Lage meinen FTP-Server zu entdecken. "Full-Scan" scannt angeblich 5000 Ports, aber anscheinend nicht die richtigen, es gibt ja 65536 TCP Ports und genau so viele UDP.
Habe http://www.port-scan.de recherchiert viellecht taugt die Seite mehr, die Scanndauer gibt schon mal Hoffnung :)
Gruß
Robert