Wenn der Traceroute Kreise tanzt
Manchmal überrascht einen eine Trivialität. Ich wollte das Routing einer Server-IP prüfen, aber der Trace wurde zu mir zurück reflektiert. Wie geht das?
Wunder
traceroute to 178.19.224.48 (178.19.224.48), 30 hops max, 40 byte packets 1 switch1-9-4-1-vl52.net.iks-jena.de (217.17.197.11) 1.470 ms 1.372 ms 1.304 ms 2 turm1-g001.net.iks-jena.de (217.17.197.49) 0.382 ms 0.438 ms 0.363 ms 3 rudo8-t001-116.net.encoline.de (5.102.160.98) 0.613 ms 0.574 ms 0.566 ms 4 switch3-v93.net.encoline.de (5.102.160.161) 1.465 ms 1.141 ms 1.170 ms 5 server16-vlan58.net.encoline.de (5.102.160.132) 0.567 ms 0.538 ms 0.541 ms 6 switch4-v94.net.encoline.de (5.102.160.178) 2.181 ms 1.469 ms 1.686 ms 7 server16-vlan94.net.encoline.de (5.102.160.185) 0.641 ms 0.635 ms 0.575 ms 8 switch2-v58.net.encoline.de (5.102.160.129) 9.887 ms 3.478 ms 1.380 ms 9 rudo7-t000-123.net.encoline.de (5.102.160.90) 0.879 ms 0.740 ms 0.721 ms 10 turm1-g001-116.net.iks-jena.de (5.102.160.99) 0.991 ms 0.942 ms 1.012 ms 11 * * * 12 nat-178-19-224-48.net.encoline.de (178.19.224.48) 1.123 ms 1.052 ms 1.025 ms
Der Trace geht raus, kehrt um, kommt zurück und am Ende meint er das Ziel erreicht zu haben.
Dabei trifft er sogar bestimmte Router mehrfach. Das ist deswegen verwunderlich, weil doch die Router ihre Entscheidung allein anhand der Zieladresse fällen. Wie kann also das Paket in verschiedene Richtungen geroutet werden?
Zunächst erst einmal handelt es sich nicht um ein lokales Phänomen, sondern es funktioniert auch von anderen Quellen aus.
traceroute to 178.19.224.48 (178.19.224.48), 30 hops max, 60 byte packets ... 4 inexio2.gw.network.manitu.net (89.238.127.62) 4.593 ms 4.594 ms 4.592 ms 5 209-096-244-077.ip-addr.inexio.net (77.244.96.209) 7.633 ms 7.634 ms 7.642 ms 6 DE-CIX1.de.lambdanet.net (80.81.193.74) 7.605 ms 7.358 ms 6.739 ms 7 ae2.irt2.fra25.de.as13237.net (217.71.96.45) 7.881 ms 7.878 ms 7.584 ms 8 ae5.irt1.han87.de.as13237.net (217.71.96.30) 13.407 ms 13.380 ms 13.390 ms 9 ae7.irt1.ber02.de.as13237.net (217.71.96.133) 16.610 ms 16.613 ms 16.607 ms 10 bb-erf-02-loc.netz.netkom-line.net (109.73.31.198) 213.352 ms 213.364 ms 213.361 ms 11 tnk-ilm-001-loc.netz.netkom-line.net (109.73.31.195) 22.149 ms 20.946 ms 20.579 ms 12 109.73.31.141 (109.73.31.141) 147.983 ms 147.987 ms 147.974 ms 13 tnk-jen-001-loc.netz.netkom-line.net (109.73.31.193) 19.504 ms 19.453 ms 19.471 ms 14 tnk-jen-001-ipt.netz.netkom-line.net (109.73.31.194) 19.468 ms 19.468 ms 19.467 ms 15 rudo7-t010.net.encoline.de (5.102.160.105) 33.994 ms 34.003 ms 34.002 ms 16 switch2-v123.net.encoline.de (5.102.160.91) 34.350 ms 34.407 ms 34.573 ms 17 server16-vlan58.net.encoline.de (5.102.160.132) 33.875 ms 33.879 ms 33.866 ms 18 switch4-v94.net.encoline.de (5.102.160.178) 34.753 ms 35.605 ms 35.596 ms 19 server16-vlan94.net.encoline.de (5.102.160.185) 34.362 ms 34.259 ms 34.179 ms 20 switch2-v58.net.encoline.de (5.102.160.129) 34.800 ms 35.279 ms 34.905 ms 21 rudo7-t000-123.net.encoline.de (5.102.160.90) 34.440 ms 34.203 ms 34.452 ms 22 rudo5-t001-123.net.encoline.de (5.102.160.89) 34.228 ms 34.449 ms 34.435 ms 23 ar2.ber.de.colt.net (213.61.70.177) 55.706 ms 55.705 ms 55.674 ms 24 212.36.135.22 (212.36.135.22) 55.909 ms 56.438 ms 56.417 ms 25 212.36.135.22 (212.36.135.22) 55.398 ms 55.416 ms 55.389 ms 26 * * * 27 * * * 28 * * * 29 nat-178-19-224-48.net.encoline.de (178.19.224.48) 68.590 ms 68.544 ms 68.691 ms
Wow. Hin- und Rückrouting in einem Trace! Man sieht sehr schön den asymmetrischen Rouingweg.
Aber was passiert da?
Schnüffeln
Die Ursache sollte ausschließlich am angesprochenen Server zu suchen sein. Alles andere wäre eine grobe Überraschung, denn dann müßten die Geräte im Transportweg irgendeine Manipulation vorgenommen haben.
Also ein Mitschnitt auf den Außeninterfaces des betroffenen Servers aktiviert:
13:39:51.074580 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 13, length 20 13:39:51.074601 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.077408 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 14, length 20 13:39:51.077414 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.077939 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 15, length 20 13:39:51.077944 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.078590 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 16, length 20 13:39:51.079237 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.082388 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 17, length 20 13:39:51.084253 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.084855 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 18, length 20 13:39:51.088146 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.088802 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 19, length 20 13:39:51.088848 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.092134 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 20, length 20 13:39:51.092176 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.092892 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 21, length 20 13:39:51.092934 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.093756 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 22, length 20 13:39:51.093774 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 22, length 20 13:39:51.097201 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.100803 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 23, length 20 13:39:51.100823 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 23, length 20 13:39:51.101499 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.102261 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 24, length 20 13:39:51.102280 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 24, length 20 13:39:51.102924 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.103742 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 25, length 20 13:39:51.103763 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 25, length 20 13:39:51.103870 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.106558 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 26, length 20 13:39:51.106577 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 26, length 20 13:39:51.106687 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.107389 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 27, length 20 13:39:51.107408 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 27, length 20 13:39:51.107510 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.108284 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 28, length 20 13:39:51.108302 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 28, length 20 13:39:51.108652 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.111847 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 29, length 20 13:39:51.111866 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 29, length 20 13:39:51.112220 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.113013 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 30, length 20 13:39:51.113032 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 30, length 20 13:39:51.113386 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36 13:39:51.114062 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 31, length 20 13:39:51.114080 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 31, length 20 13:39:51.115606 IP 217.17.197.43 > 217.17.192.34: ICMP time exceeded in-transit, length 36
Man sieht sehr schön, wie anfangs die Echo-Pakete mit einem Timeout beantwortet werden.
Kurz darauf (ab Sequenznummer 22) tauchen plötzlich Echo-Pakete auf, bei denen Quell- und Ziel-Adresse vertauscht sind. Diese entstehen offenbar direkt nach dem Eingang des ersten Paketes.
Nun dient die Kiste ein (Carrier Grade)-NAT. Ihr Zweck ist es also Pakete umzuschreiben und zwar so, daß möglichst wenig Pakete verloren gehen. Schließlich dient NAT ja dazu, Verbindungen zu ermöglichen! Eine Firewall oder Paketfilter würde Pakete verwerfen. NAT dagegen muß so gut wie möglich raten, wo das Paket eigentlich hin soll.
In diesem Fall geht das NAT systematisch vor:
- Es nattet die fremde Quell-Adresse auf die eigene öffentliche IP.
- Und es nattet die eigene öffentliche Ziel-IP zu – tja wohin, achja, da ist ja ein ganz frischer Eintrag in der NAT Tabelle …
Fertig ist der Spiegel.
Gefährlich?
Kann man das mit allen Protokollen machen? Wenn ja, könnte man trivial unter falscher Flagge segeln, oder?
Tracing the path to 178.19.224.48 on TCP port 80, 30 hops max 1 switch1-9-4-1-vl4.net.iks-jena.de (217.17.192.125) 6.742 ms 2.125 ms 1.139 ms 2 turm2-g001-5.net.iks-jena.de (217.17.197.50) 0.228 ms turm1-g001.net.iks-jena.de (217.17.197.49) 0.350 ms turm2-g000-3.net.iks-jena.de (217.17.197.34) 0.265 ms 3 rudo8-t001-116.net.encoline.de (5.102.160.98) 0.449 ms 0.468 ms 0.423 ms 4 switch3-v93.net.encoline.de (5.102.160.161) 1.414 ms 1.570 ms 2.359 ms 5 server16-vlan58.net.encoline.de (5.102.160.132) 0.489 ms 0.431 ms 0.418 ms 6 switch4-v94.net.encoline.de (5.102.160.178) 1.443 ms 1.166 ms 1.921 ms 7 server16-vlan94.net.encoline.de (5.102.160.185) 0.429 ms 0.473 ms 0.444 ms 8 switch4-v94.net.encoline.de (5.102.160.178) 14.355 ms 2.695 ms 1.462 ms 9 server16-vlan94.net.encoline.de (5.102.160.185) 0.473 ms 0.495 ms 0.465 ms ...
Nein, man kann nicht. Und das ist gut so™.