Traceroute gibt nur * aus + MTU-Frage.
Hallo, ich hoffe, folgende Frage wird nicht als Beleidigung verstanden, aber ich bin irgendwie nicht in der Lage, das Problem alleine zu lösen (die manpage von traceroute bringt mich auch nicht grade weiter..). Auch wenn es so klingt, als wäre ich nicht in der Lage, die Manpage ein mal durchzulesen: Traceroute zeigt bei mir nichts an außer *. linux:/home/soeren # traceroute -m 255 www.google.de traceroute to www.google.de (66.102.9.104), 255 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * Ich habe die maximale Time-To-Live -Rate mal etwas hochgesetzt, in der Hoffnung, dass später noch etwas sinnvolles kommt, doch es bleibt so in dem Stil. Es ändert auch nichts, wenn ich das an anderen Hosts probiere. Pingen kann ich www.google.de. Anscheinend kommen die ICMP-Pakete nicht an, wenn die Sternchen angezeigt werden, sehe ich das richtig? Das heißt also, dass nur das "Reinkommen" der Pakete nicht klappt. (aus dem Grund habe ich die "Versende-Seite" noch nicht unter die Lupe genommen..) An meinem Router habe ich aber ICMP-Pakete ausdrücklich erlaubt. (Das ist ein Hardware Router, über den ich ins Netz gehe.) Kann mir dort bitte jemand einen Tipp geben, woran das liegen kann? Ich habe mal die MTU von 1500 auf 1412 hinuntergesetzt, in der Hoffnung, dass das irgendwas damit zu tun haben könnte. (ich las irgendwo, dass das für t-online die richtige sein sollte...) Weiß jemand dazu genaueres? Wie kann ich herausfinden, welche MTU für mich optimal ist? Ich habe es so ausprobiert: (192.168.0.1 ist die ip des routers...) linux:/home/soeren # ping -f -l 1500 192.168.0.1 WARNING: probably, rcvbuf is not enough to hold preload. PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. --- 192.168.0.1 ping statistics --- 8339 packets transmitted, 6237 received, 25% packet loss, time 4845ms rtt min/avg/max/mdev = 2.008/919.056/1121.356/247.682 ms, pipe 1500, ipg/ewma 0.581/1007.476 ms linux:/home/soeren # ping -f -l 1488 192.168.0.1 WARNING: probably, rcvbuf is not enough to hold preload. PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. --- 192.168.0.1 ping statistics --- 8097 packets transmitted, 6111 received, 24% packet loss, time 4755ms rtt min/avg/max/mdev = 2.121/921.014/1113.439/252.023 ms, pipe 1488, ipg/ewma 0.587/1034.832 ms linux:/home/soeren # ping -f -l 1412 192.168.0.1 WARNING: probably, rcvbuf is not enough to hold preload. PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. --- 192.168.0.1 ping statistics --- 5596 packets transmitted, 3899 received, 30% packet loss, time 3057ms rtt min/avg/max/mdev = 1.906/817.796/1047.387/278.648 ms, pipe 1412, ipg/ewma 0.546/977.203 ms linux:/home/soeren # ping -f -l 1450 192.168.0.1 WARNING: probably, rcvbuf is not enough to hold preload. PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. --- 192.168.0.1 ping statistics --- 3769 packets transmitted, 2225 received, 40% packet loss, time 1779ms rtt min/avg/max/mdev = 2.015/709.134/1085.262/330.004 ms, pipe 1450, ipg/ewma 0.472/1038.840 ms linux:/home/soeren # Allerdings ist das ja intern, von daher weiß ich nicht, ob man dem irgendeinen Glauben schenken kann. Das war nur das einzige, was mir zu MTU so einfiel... Auch hier wäre ich dankbar, wenn mich jemand darüber aufklären könnte. für jede Anregung bzw. Hilfe bin ich dankbar! Gruß Sören
Am Sonntag, 3. Oktober 2004 17:03 schrieb Sören Wengerowsky:
An meinem Router habe ich aber ICMP-Pakete ausdrücklich erlaubt. (Das ist ein Hardware Router, über den ich ins Netz gehe.)
Das heißt, ich habe die Option "Respond to ICMP (ping) on WAN interface" aktiviert. Das ist das einzige, was ich diesbezüglich gefunden habe. Gruß Sören
* Sonntag, 03. Oktober 2004 um 17:03 (+0200) schrieb Sören Wengerowsky:
Traceroute zeigt bei mir nichts an außer *.
linux:/home/soeren # traceroute -m 255 www.google.de traceroute to www.google.de (66.102.9.104), 255 hops max, 40 byte packets 1 * * * 2 * * * [ ... ]
Ich habe die maximale Time-To-Live -Rate mal etwas hochgesetzt, in der Hoffnung, dass später noch etwas sinnvolles kommt, doch es bleibt so in dem Stil. Es ändert auch nichts, wenn ich das an anderen Hosts probiere.
Pingen kann ich www.google.de.
Anscheinend kommen die ICMP-Pakete nicht an, wenn die Sternchen angezeigt werden, sehe ich das richtig?
Die Sterne zeigen an, dass keine Antwort auf das/die Paket(e) eintrifft. Das kann aber auch durchaus daran liegen, dass keine Pakete rausgegangen sind.
Das heißt also, dass nur das "Reinkommen" der Pakete nicht klappt. (aus dem Grund habe ich die "Versende-Seite" noch nicht unter die Lupe genommen..)
Das solltest du aber... Hast du eine Firewall/Paketfilter auf dem Rechner laufen? Das 'traceroute' aus dem "net-tools"-Paket sendet UDP-Pakete, keine ICMP-Pakete.
Ich habe mal die MTU von 1500 auf 1412 hinuntergesetzt, in der Hoffnung, dass das irgendwas damit zu tun haben könnte. (ich las irgendwo, dass das für t-online die richtige sein sollte...) Weiß jemand dazu genaueres?
Bei einem 'traceroute' mit 40 Byte-Paketen kann kein PMTUD-Problem auftreten, stelle die MTU besser wieder zurück... (Melde dich ggfs. wieder, wenn du Probleme mit WWW-Sites wie z.B. "www.gmx.de" hast.)
Wie kann ich herausfinden, welche MTU für mich optimal ist? Ich habe es so ausprobiert:
(192.168.0.1 ist die ip des routers...) linux:/home/soeren # ping -f -l 1500 192.168.0.1
Entweder hast du eine anderes 'ping' als ich (aus dem "iputils-*"-Paket) oder
du hast die Man-Page zu ping nicht gelesen. Mein 'ping' macht mit
obenstehender Zeile einen Flood-Ping mit einer Preload von 1500 Paketen, und
ich weiss nicht, was man mit so einem 'ping' diagnostizieren kann.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Sonntag, 3. Oktober 2004 20:33 schrieb Andreas Koenecke:
* Sonntag, 03. Oktober 2004 um 17:03 (+0200) schrieb Sören Wengerowsky: Die Sterne zeigen an, dass keine Antwort auf das/die Paket(e) eintrifft. Das kann aber auch durchaus daran liegen, dass keine Pakete rausgegangen sind.
Würde dann nicht vorher schon eine Meldung kommen?
Das heißt also, dass nur das "Reinkommen" der Pakete nicht klappt. (aus dem Grund habe ich die "Versende-Seite" noch nicht unter die Lupe genommen..)
Das solltest du aber... Hast du eine Firewall/Paketfilter auf dem Rechner laufen? Also der Hardware-Router hat eine Firewall... an meinem PC ist keine FW aktiv. Paketfilter demnach auch nicht. Das 'traceroute' aus dem "net-tools"-Paket sendet UDP-Pakete, keine ICMP-Pakete. Über welchen UDP-Port geht soetwas?
Ich benutze auch das traceroute aus nettools: linux:/home/soeren # rpm -qf `which traceroute` net-tools-1.60-543 linux:/home/soeren # Welchen Port muss ich dann öffnen? Sendet Ping nicht auch UDP Pakete? Wie gesagt, Ping geht bei mir.
Ich habe mal die MTU von 1500 auf 1412 hinuntergesetzt, in der Hoffnung, dass das irgendwas damit zu tun haben könnte. (ich las irgendwo, dass das für t-online die richtige sein sollte...) Weiß jemand dazu genaueres?
Bei einem 'traceroute' mit 40 Byte-Paketen kann kein PMTUD-Problem auftreten, stelle die MTU besser wieder zurück...
OK
(Melde dich ggfs. wieder, wenn du Probleme mit WWW-Sites wie z.B. "www.gmx.de" hast.)
Wie kann ich herausfinden, welche MTU für mich optimal ist? Ich habe es so ausprobiert:
(192.168.0.1 ist die ip des routers...) linux:/home/soeren # ping -f -l 1500 192.168.0.1
Entweder hast du eine anderes 'ping' als ich (aus dem "iputils-*"-Paket) oder du hast die Man-Page zu ping nicht gelesen. Mein 'ping' macht mit obenstehender Zeile einen Flood-Ping mit einer Preload von 1500 Paketen, und ich weiss nicht, was man mit so einem 'ping' diagnostizieren kann.
Ich dachte, da das die Größe der Paketanzahl ist, kann man sehen, welche MTU besser passt. Aber so wie du das sagst, macht es für mich auch nicht mehr so viel Sinn... Vielen Dank Gruß Sören
* Sonntag, 03. Oktober 2004 um 23:44 (+0200) schrieb Sören Wengerowsky:
Am Sonntag, 3. Oktober 2004 20:33 schrieb Andreas Koenecke:
Die Sterne zeigen an, dass keine Antwort auf das/die Paket(e) eintrifft. Das kann aber auch durchaus daran liegen, dass keine Pakete rausgegangen sind.
Würde dann nicht vorher schon eine Meldung kommen?
Nur wenn sie direkt auf dem Host blockiert werden. Mit "raus" meinte ich raus aus dem lokalen Netz.
Hast du eine Firewall/Paketfilter auf dem Rechner laufen? Also der Hardware-Router hat eine Firewall... an meinem PC ist keine FW aktiv. Paketfilter demnach auch nicht. Das 'traceroute' aus dem "net-tools"-Paket sendet UDP-Pakete, keine ICMP-Pakete. Über welchen UDP-Port geht soetwas?
Ports 33434 + max_hops.
Sendet Ping nicht auch UDP Pakete? Wie gesagt, Ping geht bei mir.
Nein, ping sendet ICMP-Pakete.
Versuche es doch mal mit dem Paket "mtr-*", das ist nicht nur schöner als
'traceroute', sondern arbeitet auch mit ICMP...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
* Montag, 04. Oktober 2004 um 00:46 (+0200) schrieb Andreas Koenecke:
* Sonntag, 03. Oktober 2004 um 23:44 (+0200) schrieb Sören Wengerowsky:
Über welchen UDP-Port geht soetwas?
Ports 33434 + max_hops.
Das ist missverständlich. Ich meinte: Ports 33434 bis 33434 + max_hops.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Montag, 4. Oktober 2004 00:46 schrieb Andreas Koenecke:
* Sonntag, 03. Oktober 2004 um 23:44 (+0200) schrieb Sören Wengerowsky:
Am Sonntag, 3. Oktober 2004 20:33 schrieb Andreas Koenecke:
Die Sterne zeigen an, dass keine Antwort auf das/die Paket(e) eintrifft. Das kann aber auch durchaus daran liegen, dass keine Pakete rausgegangen sind.
Würde dann nicht vorher schon eine Meldung kommen?
Nur wenn sie direkt auf dem Host blockiert werden. Mit "raus" meinte ich raus aus dem lokalen Netz. Achso..
Hast du eine Firewall/Paketfilter auf dem Rechner laufen?
Also der Hardware-Router hat eine Firewall... an meinem PC ist keine FW aktiv. Paketfilter demnach auch nicht.
Das 'traceroute' aus dem "net-tools"-Paket sendet UDP-Pakete, keine ICMP-Pakete.
Über welchen UDP-Port geht soetwas?
Ports 33434 + max_hops.
Ich habe in dem Konfigurations-Menü die Möglichkeit gefunden, einen "Service" hinzuzufügen.. Also sollte er jetzt die Pakete an dem UDP-Port 33434 durchlassen können. Von max_hops habe ich nichts gefunden. Ich konnte lediglich die Portnummer eingeben.(Start Port und Finish Port). Ist es möglich, dass diese max_hops Funktion nicht vorhanden ist? Jedenfalls hat das öffnen dieses Portes nach innen hin nichts gebracht...
Sendet Ping nicht auch UDP Pakete? Wie gesagt, Ping geht bei mir.
Nein, ping sendet ICMP-Pakete. Versuche es doch mal mit dem Paket "mtr-*", das ist nicht nur schöner als 'traceroute', sondern arbeitet auch mit ICMP... Also mtr zeigt mir die Traceroute an. So wie es eigentlich sein muss. Das heißt, es liegt bei mir hier nicht an icmp?
* Montag, 04. Oktober 2004 um 14:27 (+0200) schrieb Sören Wengerowsky:
Am Montag, 4. Oktober 2004 00:46 schrieb Andreas Koenecke:
Ports 33434 + max_hops.
Ich habe in dem Konfigurations-Menü die Möglichkeit gefunden, einen "Service" hinzuzufügen..
Nein, das ist es vermutlich nicht. AFAIK bedeutet bei Hardware-Routern "Service" Destination-NAT (aka "Port-Forwarding").
Also sollte er jetzt die Pakete an dem UDP-Port 33434 durchlassen können.
Es sind nur die ausgehenden Pakete UDP-Pakete, eingehend sind es ICMP-Pakete. Der Router muss lediglich die ausgehenden UDP-Pakete source-"natten". (Ich glaube aber nicht, dass es ein (reines) NAT-Problem ist, da in dem Fall wenigstens der Router als Hop 1 in der Route auftauchen sollte.)
Von max_hops habe ich nichts gefunden. Ich konnte lediglich die Portnummer eingeben.(Start Port und Finish Port).
Ist es möglich, dass diese max_hops Funktion nicht vorhanden ist?
Mit "max_hops" ist die max. Anzahl der Hops gemeint, mit denen du und dein 'traceroute' "arbeiten"; Default ist max_hops = 30, ansonsten die Zahl hinter der Option "-m".
Also mtr zeigt mir die Traceroute an. So wie es eigentlich sein muss. Das heißt, es liegt bei mir hier nicht an icmp?
Ja, so würde ich es auch interpretieren.
Aus irgendeinem Grund gehen IMHO die UDP-Pakete nicht raus, anscheinend kommen
sie nicht einmal bis zum Router...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Montag, 4. Oktober 2004 15:45 schrieb Andreas Koenecke:
* Montag, 04. Oktober 2004 um 14:27 (+0200) schrieb Sören Wengerowsky:
Am Montag, 4. Oktober 2004 00:46 schrieb Andreas Koenecke:
Ports 33434 + max_hops.
Nein, das ist es vermutlich nicht. AFAIK bedeutet bei Hardware-Routern "Service" Destination-NAT (aka "Port-Forwarding").
Ok. In diese Richtung habe ich noch gar nicht gedacht. Für ident und vnc und so habe ich bis jetzt immer nur andersherum damit gearbeitet. Ich werde es aber wohl probieren.
Also sollte er jetzt die Pakete an dem UDP-Port 33434 durchlassen können.
Es sind nur die ausgehenden Pakete UDP-Pakete, eingehend sind es ICMP-Pakete. Der Router muss lediglich die ausgehenden UDP-Pakete source-"natten". (Ich glaube aber nicht, dass es ein (reines) NAT-Problem ist, da in dem Fall wenigstens der Router als Hop 1 in der Route auftauchen sollte.) Heißt das, ich sollte erstmal woanders suchen?
Von max_hops habe ich nichts gefunden. Ich konnte lediglich die Portnummer eingeben.(Start Port und Finish Port).
Ist es möglich, dass diese max_hops Funktion nicht vorhanden ist?
Mit "max_hops" ist die max. Anzahl der Hops gemeint, mit denen du und dein 'traceroute' "arbeiten"; Default ist max_hops = 30, ansonsten die Zahl hinter der Option "-m". Ja. Ich weiß.. aber warum ändert das was bei den ports? Das ist doch ne art "Zähler", weil die TTL -Zeit je um 1 hochgesetzt wird, oder?
Also mtr zeigt mir die Traceroute an. So wie es eigentlich sein muss. Das heißt, es liegt bei mir hier nicht an icmp?
Ja, so würde ich es auch interpretieren.
Aus irgendeinem Grund gehen IMHO die UDP-Pakete nicht raus, anscheinend kommen sie nicht einmal bis zum Router... Wie kann ich das näher überprüfen? Die SuSE-Firewall ist aus.
Jetzt habe ich sie mal angeschaltet und den Port 33434 als Dienst freigegeben. (Ob udp oder TCP weiß ich nicht.. wie kann man das differenzieren?) Aber es klappt trotzdem nicht. (Auch mit DMZ vom router her...) Gruß Sören
* Montag, 04. Oktober 2004 um 18:48 (+0200) schrieb Sören Wengerowsky:
Am Montag, 4. Oktober 2004 15:45 schrieb Andreas Koenecke:
Nein, das ist es vermutlich nicht. AFAIK bedeutet bei Hardware-Routern "Service" Destination-NAT (aka "Port-Forwarding").
Ok. In diese Richtung habe ich noch gar nicht gedacht. Für ident und vnc und so habe ich bis jetzt immer nur andersherum damit gearbeitet. Ich werde es aber wohl probieren.
Was probieren?
Es sind nur die ausgehenden Pakete UDP-Pakete, eingehend sind es ICMP-Pakete. Der Router muss lediglich die ausgehenden UDP-Pakete source-"natten". (Ich glaube aber nicht, dass es ein (reines) NAT-Problem ist, da in dem Fall wenigstens der Router als Hop 1 in der Route auftauchen sollte.) Heißt das, ich sollte erstmal woanders suchen?
Hm, ich bin mir nicht sicher... (s.u.)
Mit "max_hops" ist die max. Anzahl der Hops gemeint, mit denen du und dein 'traceroute' "arbeiten"; Default ist max_hops = 30, ansonsten die Zahl hinter der Option "-m". Ja. Ich weiß.. aber warum ändert das was bei den ports? Das ist doch ne art "Zähler", weil die TTL -Zeit je um 1 hochgesetzt wird, oder?
Ja. 'traceroute' zählt aber auch synchron zur TTL den Zielport hoch.
Aus irgendeinem Grund gehen IMHO die UDP-Pakete nicht raus, anscheinend kommen sie nicht einmal bis zum Router... Wie kann ich das näher überprüfen? Die SuSE-Firewall ist aus.
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). Vielleicht hat ja der Router auch ein Log, in dem aufschlussreiche Informationen zu finden sind?
Jetzt habe ich sie mal angeschaltet und den Port 33434 als Dienst freigegeben. (Ob udp oder TCP weiß ich nicht.. wie kann man das differenzieren?)
Mit der SuSEFirewall kenne ich mich nicht aus, aber "Dienst" ist gleich
"Service" und das bezieht sich auf _eingehende_ Pakete.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
* Montag, 04. Oktober 2004 um 18:48 (+0200) schrieb Sören Wengerowsky:
Am Montag, 4. Oktober 2004 15:45 schrieb Andreas Koenecke:
Nein, das ist es vermutlich nicht. AFAIK bedeutet bei Hardware-Routern "Service" Destination-NAT (aka "Port-Forwarding").
Ok. In diese Richtung habe ich noch gar nicht gedacht. Für ident und vnc und so habe ich bis jetzt immer nur andersherum damit gearbeitet. Ich werde es aber wohl probieren.
Was probieren? Einen "virtual server" oder Portforwarding einzurichten für Port
Am Montag, 4. Oktober 2004 21:52 schrieb Andreas Koenecke: 33434. Das hat aber auch nichts gebracht. Allerdings konnte ich nur einen aufmal forwarden.. mit denen, die mit der TTL (30 oder so sollten es ja schon sein...) hochgezählt wurden, kann man hier nicht rechnen.. Ich habe bei "Spezial-Applikations" mal ein paar Ports mehr freigegeben (33434 - 334500).. jedoch ohne Erfolg. Die Pakete tauchen noch nichtmal im Log auf. Bei den Services hab ich auch mal 33434-334500 geöffnet. Ohne Erfolg.
Mit "max_hops" ist die max. Anzahl der Hops gemeint, mit denen du und dein 'traceroute' "arbeiten"; Default ist max_hops = 30, ansonsten die Zahl hinter der Option "-m".
Ja. Ich weiß.. aber warum ändert das was bei den ports? Das ist doch ne art "Zähler", weil die TTL -Zeit je um 1 hochgesetzt wird, oder?
Ja. 'traceroute' zählt aber auch synchron zur TTL den Zielport hoch. Achso. Jetzt verstehe ich das, was du mit "Max-TTL" meinst.
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?
Aus irgendeinem Grund gehen IMHO die UDP-Pakete nicht raus, anscheinend kommen sie nicht einmal bis zum Router...
Wie kann ich das näher überprüfen? Die SuSE-Firewall ist aus.
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. Die Ausgabe von tcpdump habe ich mal angehängt. Kannst du dort etwas auffälliges erkennen?
Vielleicht hat ja der Router auch ein Log, in dem aufschlussreiche Informationen zu finden sind?
Ja.. "Outgoing connections" "Access Control" "DoS" Ich habe mal bei "outgoing connections" nachgesehen. Dort war nichts zu finden, außer den Seiten, auf die ich vorher gesurft bin...
Jetzt habe ich sie mal angeschaltet und den Port 33434 als Dienst freigegeben. (Ob udp oder TCP weiß ich nicht.. wie kann man das differenzieren?)
Mit der SuSEFirewall kenne ich mich nicht aus, aber "Dienst" ist gleich "Service" und das bezieht sich auf _eingehende_ Pakete.
So dachte ich mir das auch... 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... Eine Idee noch: ist es möglich, dass der Port 33434 bei t-online gar nicht verfügbar ist? Gruß Sören
Am Mittwoch, 6. Oktober 2004 16:06 schrieb Sören Wengerowsky:
Ich habe mal bei "outgoing connections" nachgesehen. Dort war nichts zu finden, außer den Seiten, auf die ich vorher gesurft bin...
Ich habe festgestellt, dass diese Log sich wohl nur auf Port 80 bezieht.. Ich werde nochmal etwas warten, bis er mir die Logs per mail zusendet. Dort werden sie (das weiß ich noch, seit ich das mal getestet habe) etwas ausführlicher sein. Gruß Sören
* 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).
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...
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.
Die Ausgabe von tcpdump habe ich mal angehängt. Kannst du dort etwas auffälliges erkennen?
s.u.
Vielleicht hat ja der Router auch ein Log, in dem aufschlussreiche Informationen zu finden sind?
Ja.. "Outgoing connections" "Access Control" "DoS"
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.
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".)
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"?
Falls nicht, dann wäre es jetzt interessant, mit einem Hub und einem weiteren
Rechner den Traffic _hinter_ dem Router belauschen...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
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
* Mittwoch, 06. Oktober 2004 um 21:40 (+0200) schrieb Sören Wengerowsky:
Am Mittwoch, 6. Oktober 2004 20:40 schrieb Andreas Koenecke:
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..
Nö, sagt mir nichts...
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.
Ich denke schon, dass es dann geht.
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?
Ich kenne keine Möglichkeit, wenn der Switch sich nicht entsprechend
konfigurieren lässt.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
participants (2)
-
Andreas Koenecke
-
Sören Wengerowsky