Keine Lust auf DCC

[[oETTi]]

Hallo,

ich habe mir mittels iptables ein kleines Firewallscript gebastelt.
Soweit funzt das auch alles prima. Das einzige was nicht funktioniert ist
DCC (send) im IRC. :(

Ich habe gelesen, das für DCC die Module ip_nat_irc oder ip_conntrack_irc
verantwortlich sein sollen. Ausserdem sollte man Portforwarding aktivieren.

Leider habe ich keine Ahnung, was ich wohin forwarden soll (falls das überhaupt benötigt wird), und an welche(n) Port(s) DCC (send) gebunden wird.

Das empfangen von Dateien über DCC funktioniert problemlos. Nur das senden nicht :confused:

[[oETTi]]

Jungs und Mädels, ich bau auf euch.
Also lasst mich net hängen :eek:

[PigPen|tuX]

mmh

was sagt den die suchfunktion ?

vielleicht im irc-clienten eine port-range festlegen und diese ports dann auf deiner firewall im Script dementsprechend modifizieren.

mfg.
thom

ein bissel arbeit is dat schon :rolleyes:

[[oETTi]]

Hmm,

1.) hätte ich diesen Thread nicht gestartet, wenn ich mit Hilfe der Suche das Problem gelöst hätte

und

2.) glaube ich nicht, das ich für DCC eine Portrange freigeben muss aus den folgenden Gründen:

- das Modul ip_nat_irc ist für die DCC Verbindungen zu ständig, und stellt die betreffenden Port(s) zur Verfügung
- eine Portrange lässt mehr durch als erwünscht ist!
- DCC arbeitet vom Prinzip her wie FTP

Ich glaube das hat eher was mit PREROUTING zu tun. Leider habe ich bis jetzt auch noch nichts bei google (bevor dieser Tipp auch noch kommt) gefunden!

[Harry]

Hallo oETTi,

ich hab selbst mit IRC noch net allzu viel rumgemacht, daher muß ich auch mal ein bisserl "rumstochern".
Folgendes Code-Snippet könnte jedoch bereits helfen:

...
modprobe ip_conntrack
modprobe ip_conntrack_irc

...
iptables -A OUTPUT -p tcp --dport 194 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
...

Dieses Beispiel sollte passen, falls Du von Deinem Rechner mit installiertem Paketfilter direkt IRC + DCC nutzen willst.
Kommst Du jedoch aus einem LAN über Deinen Paketfilter, dann müssen diese Regeln in der FORWARD-Chain stehen und Du benötigst zusätzlich das Modul ip_nat_irc.
Achtung: ICR + DCC funktioniert so erst ab Kernel 2.4.14. Jedoch gibt es einen Bug im Conntrack-Modul für IRC, der Verbindungen für DCC von beliebigen Rechnern zuläßt (nicht nur von dem einen, zu dem Du DCC machen möchtest). Dieses Problem ist ab Kernel 2.4.18-pre9 behoben.

Ich hoffe, es geht so.

Harry

[[oETTi]]

Hallo Harry,

danke erstmal für den Tipp :)

Leider besteht das Problem immernoch. Die Netzwerkkonfiguration ist folgende:

Win2000 ----> Router/FW ----> www

Beide Varianten, sowohl OUTPUT als auch FORWARD haben nicht funktioniert. Der Router gibt folgende Fehlermeldung an:



Forged DCC Command from 192.168.1.2: 217.85.126.xxx:1102
Forged DCC Command from 192.168.1.2: 217.85.126.xxx:3209
Forged DCC Command from 192.168.1.2: 217.85.126.xxx:4312
...


Da die 217.85.126.xxx ja meine eigene IP ist, kommt DCC nur bis zum Router und dann nicht weiter :(

Am Kernel sollte es eigentlich nicht liegen:



uname -r

2.4.18-3


Mein "Firewallscript"sieht im Moment folgendermassen aus:



iptables -F

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

modprobe ip_conntrack
modprobe ip_conntrack_irc

#iptables -A OUTPUT -p tcp --dport 194 -m state --state NEW -j ACCEPT
#iptables -A OUTPUT -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT

iptables -A FORWARD -p tcp --dport 194 -m state --state NEW -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT



Vielleicht hat noch jemand Ideen voran es liegen könnte :ugly:

[oETTi]

[Harry]

Hallo,

wenn Du eh schon Masquerading auf dem Router machst, dann wirst Du zusätzlich das Modul ip_nat_irc benötigen.

Harry

[slime]

na falsch, natürlich brauch er das ip_nat_irc, weil ohne kann der router der nat ausfürt nicht alle pakete richtig zuordnen. es gibt ja auch ein ip_nat_ftp modul.
diese treiber "zerlegen" die pakete um den port rauszufinden auf dem die nächste verbindung stattfindet um diese richtig an die cleintrechner weiterleiten zu können.

das brauch man NUR bei ftp und irc

[Harry]

Original geschrieben von slime
na falsch, natürlich brauch er das ip_nat_irc, weil ...
Ja - und was hast Du jetzt falsches gelesen? :D

Harry

[psychojoe]

die theorie:
Das Problem besteht darin, dass der irc-client, der etwas per dcc verschicken will, dem empfänger etwa folgendes sagt:
ich will dir etwas schicken. conntecte dich bitte zu meiner ip auf port x um mit der übertragung zu beginnen.
als ip schickt der absender aber natürlich seine lokale ip, da er ja gar nicht weiss, dass er hinter einem NAT-router hängt.
der empfänger kann mit der lokalen ip aber nichts anfangen. deshalb muss man seinem client ( als absender) klar machen, dass er nicht seine lokale ip, sondern die "offizielle" ip des routers an den empfänger schicken soll.
seinem router muss man dann nur noch sagen, dass er alle verbindungsanfragen auf dem port x an den client weiterleiten soll.
da dcc aber mehrere ports benötigt ( fragt mich nicht, warum) nimmt man nicht nur port x, sonder die ports x bis y.

die praxis:
-auf dem router ne port-range an den client forwarden
-diese ports beim irc-client als dcc-ports einstellen
-mittels eines scripts die aktuelle (offizielle ip im internet)ip abfragen
-die dann ebenfalls beim irc-client als dcc-ip eintragen :)

das ist nichth alb so kompliziert, wie ich mich jetzt ausgedrückt hab :D

[slime]

im bezug auf "die praxis"

sollte nicht gerade dieses nat_irc und connectiontracking für irc das ganze übernehmen und automatisch forwarden.

[[oETTi]]

So,

nachdem ich nun alle möglichen iptables-Varianten probiert habe, funzt auch mein DCC-Senden/Empfangen vom Windowsclient aus.

Sicherlich wird viele interessieren, woran das gelegen hat :)

Ich habe Windows2000 komplett neu installiert (hatte ich sowieso vor) und im mIRC eine kleine Änderung vorgenommen (hatte ich vor der Neuinstallation auch schon ohne Erfolg probiert)

Einfach unter File >>> Options >>> Local Info Lookup Method auf Normal stellen, und nicht Server anklicken. That's it :D

Da muss man erst die Windowskiste neuinstallieren um wieder ordentlich chatten zu können *LOL*.

Btw, unter Linux funzte DCC ohne Probleme -> konnte also nur am M$ liegen.

Thx an alle, die mir bei der Lösung weitergeholfen haben. Spitze Forum hier! :)

[Harvest]

sollte nicht gerade dieses nat_irc und connectiontracking für irc das ganze übernehmen und automatisch forwarden.

ja, genau, was machen
ip_conntrack
ip_conntrack_irc
ip_nat_irc
denn eigentlich? ich sitz auch hinter nem debian router mit nem debian rechner, beide mit 2.6.8er kernel.. auf dem router werden die module geladen, auf dem client nicht - richtig ?
passives dcc ist kein problem, aber aktives, also senden geht nur vom router aus, von meinem eigentlichen rechner nicht .. jemand eine idee, was ich machen kann ?

grüsse,
Harvest

[Stage]

ja, genau, was machen
ip_conntrack
ip_conntrack_irc
ip_nat_irc
denn eigentlich? ich sitz auch hinter nem debian router mit nem debian rechner, beide mit 2.6.8er kernel.. auf dem router werden die module geladen, auf dem client nicht - richtig ?
passives dcc ist kein problem, aber aktives, also senden geht nur vom router aus, von meinem eigentlichen rechner nicht .. jemand eine idee, was ich machen kann ?

grüsse,
Harvest
also normalerweise reicht das aus. ABER standardmässig "tracken" diese Module nur Verbindungen mit die auf port 6667 gehen. Wenn du also mit einem IRC-Server verbindest, solltest du drauf achten das dieser Port benutzt wird (und die module natürlich vor dem connect geladen sein müssen).
Ansonsten kannst du auch andere Ports per Parameter definieren z.B

modprobe ip_conntrack_irc ports=6665,6666,6667,6668,6669
modprobe ip_nat_irc ports=6665,6666,6667,6668,6669
wichtig hierbei ist das die beiden ports-angaben übereinstimmen, und ip_conntrack_irc vor ip_nat_irc geladen wird