Ich bin bisweilen immer davon ausgegangen, dass RFC1918 konforme Adressen im Netz nicht geroutet werden bzw. nicht geroutet werden können. Das ist zumindest das, was ich in meiner Ausbildung gelernt habe. Kann mir vllt. einer von Euch sagen wie das funktionieren soll? :-)
Ich wollte eben den Standort einer IP ausfindig machen, welche versucht hat in meinen Root Server einzubrechen, und habe dann mal ein Traceroute auf die IP gemacht. Das hat dann folgendes Ergebnis zu Tage gebracht. Besonderes Augenmerk gilt dabei dem Hop Nr. 8.
>tracert 210.51.162.35
Routenverfolgung zu 210.51.162.35 über maximal 30 Abschnitte
1 26 ms 6 ms 6 ms 192.168.0.1
2 * * * Zeitüberschreitung der Anforderung.
3 17 ms 12 ms 19 ms ge-01-04-510.dor002isp005.versatel.de [62.214.109.85]
4 21 ms 19 ms 19 ms hhb2isp5.versatel.de [62.214.110.109]
5 22 ms 19 ms 19 ms hhb2isp6.versatel.de [62.214.111.78]
6 20 ms 21 ms 19 ms hhb2ip6.versatel.de [62.214.111.86]
7 23 ms 24 ms 24 ms hhb2dtag.versatel.de [62.214.1.66]
8 379 ms 373 ms 374 ms 192.168.2.2
9 391 ms 376 ms 386 ms 217.6.49.182
10 349 ms 348 ms 348 ms 210.53.126.1
11 363 ms 343 ms 345 ms 210.52.132.229
12 374 ms 351 ms 351 ms 210.52.133.125
13 354 ms 367 ms 358 ms 210.53.128.54
14 356 ms 356 ms 371 ms 210.51.176.10
15 357 ms 357 ms 368 ms 210.51.176.97
16 357 ms 355 ms 367 ms 210.51.162.35
Ablaufverfolgung beendet.
AFAIK werden Routing-Entscheidungen in der Regel lediglich aufgrund der Ziel-IP getroffen. Was dann als Quell-IP angegeben ist, spielt keine Rolle, auch "privates" wird weitergeleitet. Grund: Die zur Vermeidung dessen notwendigen Filterregeln würden nochmals Rechenzeit kosten und die Latenz auf den Routern weiter erhöhen.
Warum diese IP aber in deinem Trace irgendwo mitten drin auftaucht, verstehe ich nicht so wirklich.. Ich habs spaßeshalber mal nachvollzogen, und diese IP nicht gefunden in der Ausgabe.
//Edit: Ich finde sie nicht, wenn ichs von der Firma aus ausprobiere - Von zuhause aus schon. Hilfe, ich bin verwirrt ;)
Jo,... die Ergebnisse unterscheiden sich bei mir auch. Wenn ich von meinem Server aus die IP trace, dann bekomme ich auch ein anderes Ergebnis, was wohl darauf schliessen lässt, dass es an meinem Provider liegen könnte.
n24srv02:~ # traceroute 210.51.162.35
traceroute to 210.51.162.35 (210.51.162.35), 30 hops max, 40 byte packets
1 85.214.1.14 0.308 ms 0.216 ms 0.354 ms
2 85.214.0.129 2.136 ms 2.260 ms 1.235 ms
3 ae3-0.lpz2-j2.mcbone.net (62.104.199.93) 4.632 ms 4.574 ms 4.611 ms
4 ge-2-0-0-0.ffm4-j2.mcbone.net (62.104.191.199) 19.226 ms 17.395 ms 17.361 ms
5 unknown.level3.net (62.67.33.245) 13.090 ms 34.374 ms 32.523 ms
6 dtag-level3-te.Frankfurt1.Level3.net (4.68.110.254) 13.877 ms 13.860 ms 13.943 ms
7 * * *
8 217.6.49.182 347.565 ms 347.456 ms 347.586 ms
9 210.53.127.209 326.866 ms 326.650 ms 326.795 ms
10 210.52.132.229 339.595 ms 339.611 ms 339.334 ms
11 210.52.133.125 355.571 ms 355.688 ms 355.612 ms
12 210.53.128.54 368.486 ms 368.433 ms 368.279 ms
13 210.51.176.222 377.236 ms 368.749 ms 368.575 ms
14 210.51.176.97 368.719 ms 368.869 ms 369.068 ms
15 210.51.162.35 368.601 ms 368.797 ms 368.708 ms
@elch_mg: Bist Du zufällig auch Versatel Kunde? Wenn nicht dann wäre in dieser Ausgabe wahrscheinlich der Hop Nr.7 das, was in der vorherigen Ausgabe der Hop Nr. 8 ist. Warum er dann aber nicht hier mit seiner RFC1918 IP angezeigt wird, kann ich dann allerdings auch nicht versteh'n... *grübel*
Ich hab diese lokalen IP-Adressen auch schon entdeckt, bei mir zwischen dem Netzwerk der DOKOM (dort bin ich Kunde) und KNIPP. Gehen unseren Providern die IP-Adressen aus?
Ich hab aber das Gefühl, dass da im T-Netz irgendwas schiefläuft. Der Hop direkt danach ist ein T-Hop, und "ungefähr" da scheint sich soetwas wie eine Grenze zu verstecken, jedenfalls wenns nach den (T-)Latenzen geht. ;)
Der 217.6.49.182 is'n T-Router in deren Transitnetz. Demarkationsgrenze zum nächsten Backbone vielleicht? Das erklärt aber trotzdem diese RFC1918 IP nicht. Denn Source Routing machen die Dinger nich' afaik,... *immernochgrübel*
Naja, nur weil die IPs im RFC1918 definiert sind, warum sollte man sie nicht routen können?
Es ist doch kein Problem dem HOP7 62.214.1.66 zu sagen, das er Pakete für 210.51.162.35 an 192.168.2.2 leiten soll. Und der 192.168.2.2 weiss das er das Paket für 210.51.162.35 an 217.6.49.182 weitergibt. Ein technisches Problem ist es nicht, solange da kein Filter zwischen 62.214.1.66 und 192.168.2.2 ist der die Pakete aufgrund der RFC ablehnt.
1 <1 ms <1 ms <1 ms internet.local [172.16.7.7]
2 <1 ms <1 ms <1 ms arcor.local [172.16.7.168]
3 8 ms 8 ms 8 ms dslb-084-062-128-001.pools.arcor-ip.net [84.62.128.1]
4 8 ms 8 ms 27 ms esn-145-254-12-25.arcor-ip.net [145.254.12.25]
5 8 ms 18 ms 8 ms dus-145-254-19-198.arcor-ip.net [145.254.19.198]
6 8 ms 9 ms 8 ms dus-145-254-18-202.arcor-ip.net [145.254.18.202]
7 9 ms 8 ms 9 ms 145.253.33.130 --> Arcor
8 325 ms 324 ms 345 ms 217.239.41.10 --> DTAG
9 325 ms 324 ms 372 ms 217.6.49.182 --> DTAG
10 324 ms 377 ms 324 ms 210.53.126.1 --> China Netcom Corp.
11 366 ms 349 ms 350 ms 210.52.132.229 --> China Netcom Corp.
12 359 ms 359 ms 359 ms 210.52.133.125 --> China Netcom Corp.
13 360 ms 360 ms 360 ms 210.53.128.30 --> China Netcom Corp.
14 355 ms 352 ms 354 ms 210.51.176.10 --> China Netcom Corp.
15 359 ms 359 ms 364 ms 210.51.176.97 --> China Netcom Corp.
16 353 ms 358 ms 360 ms 210.51.162.35 --> China Netcom Corp.
Hier nochmal der Auszug vom Traceroute von einem Rootserver
...
5 FRA-3-pos000.de.lambdanet.net (217.71.96.73) 3.985 ms 4.017 ms 5.104 ms
6 FRA-1-pos000.de.lambdanet.net (217.71.96.69) 4.533 ms 4.128 ms 4.101 ms
7 FRA-2-pos500.de.lambdanet.net (217.71.96.94) 4.172 ms 4.396 ms 4.292 ms
8 62.156.139.241 (62.156.139.241) 4.704 ms 4.358 ms 4.746 ms --> DTAG
9 192.168.2.2 (192.168.2.2) 444.547 ms 331.877 ms 332.988 ms
10 217.6.49.182 (217.6.49.182) 357.864 ms 358.874 ms 359.108 ms --> DTAG
11 210.53.127.205 (210.53.127.205) 331.931 ms 331.666 ms 332.162 ms --> China Netcom Corp.
...
Erstmal können natürlich RFC1918-Adressen geroutet werden. Das es im Internet nicht klappen sollte liegt einfach daran, das sie zum einen in der Internet-Routing-Tabelle nicht vorkommen *sollten* und zweitens an jedem Border-Router gefiltert werden sollten.
Zu 1) Nur weil es nicht sein sollte heißt es nicht, dass nicht ein Provider eine 1918-Adresse ankündigt (das ist vor einiger Zeit zu Analyse-Zwecken mit dem 10er-Netz gemacht worden). Weiterhin kann ein Provider ohne weiteres in seinem internen Netz diese Adressen verwenden. Warum auch nicht, per Definition hat niemand externes mit den Provider-Geräten zu kommunizieren.
Wenn im Traceroute allerdings diese Adressen sichtbar sind ist das für mich ein Hinweis, das an mehreren Stellen nicht sauber gefiltert wird.
Die im Traceroute sichtbaren RFC-1918-Adressen sind sogenannte Transfernetze.
Da die Transfernetze ausschließlich zwischen einzelnen Routern verwendet werden und nicht nach außen bekanntgegegeben werden (Stichwort: EGP) ist das kein Problem, sondern durchaus sinnvoll um wertvolle öffentliche Adressen einzusparen.
Das dürfte wohl die logischste (und wahrscheinlichste) Erklärung sein. Nur das "nicht nach außen bekanntgegeben werden" scheint hier, in diesem Falle, wohl nicht grundsätzlich zu stimmen - Obs eine Fehlkonfiguration ist, vermag ich nicht zu beurteilen ;)
Wenn andere Provider sich aber an solche Standards wie das RFC1918 halten, dann dürften die T-Com Transitrouter und die dazugehörigen Netze aber teilweise doch Probleme haben, dass Pakete nicht dort ankommen wo sie ankommen sollen oder gar in den Untiefen des Internets verschwinden, oder nicht?! Gerade in Bezug auf dynmaische Routingprotokolle müsste das doch eigentlich für Probleme sorgen.
Der einzige Weg, wie solche Konfigurationen dann funktionieren würden, wäre dann strikt mit Source Routing zu arbeiten. Aber ich kann mir nicht wirklich vorstellen, dass sich irgendein Provider oder Backbonebetreiber eine solche Arbeit macht, was ohne jeden Zweifel bei der Größe einiger Provider eine "menge" Arbeit bedeuten würde.
Ich werde mich da aber nochmal ein bisschen schlauer machen. ;-)
Niemand im Internet erlaubt anderen Source-Routing (sofern man sich dessen bewusst ist). Es ist aber deshalb kein Problem weil niemand mit den Geräten in den Transitnetzen kommunizieren will und diese Geräte auch nicht mit anderen Geräten kommunizieren. Die leiten nur die Pakete weiter; und das geschieht aufgrund der "richtigen" Adressen.
