Am Mittwoch, 6. Oktober 2004 20:40 schrieb Andreas Koenecke:
* Mittwoch, 06. Oktober 2004 um 16:06 (+0200) schrieb Sören Wengerowsky:
Am Montag, 4. Oktober 2004 21:52 schrieb Andreas Koenecke:
Was probieren?
Einen "virtual server" oder Portforwarding einzurichten für Port 33434. Das hat aber auch nichts gebracht.
Das kann auch nichts bringen, da ja die UDP-Pakete nur rausgehen (sollen). Ja.. wie gesagt, ich bin mir nicht so ganz im klaren darüber, was man unter diesem schwammigen Begriffen wie "special applications" oder "virtual servers" verstehen soll..
Wie gesagt, ich habe es mit DMZ probiert, und das geht trotzdem nicht..
Ich könnte behaupten, dass es dann nicht am router liegt... oder gilt DMZ für diese UDP-Ports nicht?
Eine DMZ (was immer der Router-Hersteller darunter versteht), sollte nichts damit zu tun haben, es sei denn, der Router leitet aufgrund irgendeiner Einstellung _alle_ Pakete an die 'traceroute'-Ports (unabhängig von der Ziel-IP) irgendwohin um. Ich habe trotzdem den Router in Verdacht, aber nur, weil ich dem Linux-Rechner eher vertraue als dem Router...
Tja... falls es dir was sagt, es ist ein Compu-Shack SR-103 xDSL Router.. Ohne integriertes DSL-Modem.
Erst einmal sollte IMHO sichergestellt werden, ob die UDP-Pakete deinen Rechner verlassen: Setze mal ein '(t)ethereal' oder 'tcpdump' auf das Netzwerk-Interface an und fahre einen 'traceroute'(-Versuch).
Ich denke schon, dass die Pakete rauskommen.
Ja, das sehe ich ebenso.
OK
Ich habe mal bei "outgoing connections" nachgesehen. Dort war nichts zu finden, außer den Seiten, auf die ich vorher gesurft bin...
Sieh' dir doch auch die beiden anderen Logs an, vielleicht ergibt sich etwas.
Ah.. ok.
Im Grunde ist es ja auch nicht so besonders wichtig, da du mir mit mtr ja eine gute Alternative genannt hast, die auch funktioniert.. interessieren würde es mich allerdings schon, was ich hier falsch mache...
Ja, das würde mich auch interessieren...
Eine Idee noch: ist es möglich, dass der Port 33434 bei t-online gar nicht verfügbar ist?
Das spielt keine Rolle, t-online und alle anderen Router auf dem Weg zum Zielhost sollen die Pakete lediglich routen und ggfs. ICMP-Fehlermeldungen an den Quellhost zurücksenden. Der Zielport ist dabei unwichtig und muss auch auf dem Zielhost nicht aktiv sein ("Der Weg ist das Ziel").
In der Tat werden mittlerweile viele öffentliche Server von "vorgeschalteten" Firewalls/Paketfiltern geschützt, die UDP-Pakete blocken, so auch bei "www.google.de". Das bedeutet aber lediglich, dass beim 'traceroute' am _Ende_ Sterne dargestellt werden. (Insofern ist das UDP-'traceroute' heutzutage relativ "wenig wert".)
Tja.. Ich glaube, ich werde demnächst mal den Router abklemmen und dann sehen, ob es geht. Wenn ja, kann ich den Router ja als Übeltäter eindeutig identifizieren.
15:40:24.448363 IP 192.168.0.3.64000 > 66.102.9.99.traceroute: UDP, length: 40 15:40:24.450197 IP 192.168.0.3.64001 > 66.102.9.99.33435: UDP, length: 40 15:40:24.451221 arp who-has pD95ECF01.dip.t-dialin.net tell 192.168.0.1 15:40:24.452187 IP 192.168.0.3.64002 > 66.102.9.99.33436: UDP, length: 40 15:40:24.454182 IP 192.168.0.3.64003 > 66.102.9.99.33437: UDP, length: 40 [ ... ]
Das sieht gut aus, die UDP-Pakete gehen raus... Etwas seltsam ist IMHO die ARP-Anfrage des Routers nach der IP seiner eigenen PPP-Schnittstelle, ich weiss aber im Moment nicht, ob das etwas zu bedeuten hat...
Ist das ein Router mit integriertem DSL-"Modem"?
Nein. s.o.
Falls nicht, dann wäre es jetzt interessant, mit einem Hub und einem weiteren Rechner den Traffic _hinter_ dem Router belauschen... Wie soll ich das umsetzen? Ich hätte noch einen weiteren PC zur Verfügung, auf dem ich Knoppix booten könnte. Dieser ist auch an den gleichen Router angeschlossen.
Ein Hub habe ich nicht mehr zur Verfügung, aber in dem Router ist ja wie gesagt ein Switch drin.... das ist zwar nicht so leicht zu sniffen, müsste aber auch gehen, oder? Gruß Sören