RFC 1918-Adresse im offenen Internet?


18

Bei dem Versuch, ein Failover-Problem mit meinen Cisco ASA 5520-Firewalls zu diagnostizieren, führte ich eine Traceroute zu www.btfl.com durch, und zu meiner Überraschung kamen einige der Hops als RFC 1918-Adressen zurück.

Um ganz klar zu sein, dieser Host befindet sich nicht hinter meiner Firewall und es ist kein VPN beteiligt. Ich muss über das offene Internet eine Verbindung herstellen, um dorthin zu gelangen.

Wie / warum ist das möglich?

asa# traceroute www.btfl.com

Tracing the route to 157.56.176.94

 1  <redacted>
 2  <redacted>
 3  <redacted>
 4  <redacted>
 5  nap-edge-04.inet.qwest.net (67.14.29.170) 0 msec 10 msec 10 msec
 6  65.122.166.30 0 msec 0 msec 10 msec
 7  207.46.34.23 10 msec 0 msec 10 msec
 8   *  *  *
 9  207.46.37.235 30 msec 30 msec 50 msec
 10 10.22.112.221 30 msec
    10.22.112.219 30 msec
    10.22.112.223 30 msec
 11 10.175.9.193 30 msec 30 msec
    10.175.9.67 30 msec
 12 100.94.68.79 40 msec
    100.94.70.79 30 msec
    100.94.71.73 30 msec
 13 100.94.80.39 30 msec
    100.94.80.205 40 msec
    100.94.80.137 40 msec
 14 10.215.80.2 30 msec
    10.215.68.16 30 msec
    10.175.244.2 30 msec
 15  *  *  *
 16  *  *  *
 17  *  *  *

und es macht das gleiche von meiner FiOS-Verbindung zu Hause:

C:\>tracert www.btfl.com

Tracing route to www.btfl.com [157.56.176.94]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  myrouter.home [192.168.1.1]
  2     8 ms     7 ms     8 ms  <redacted>
  3    10 ms    13 ms    11 ms  <redacted>
  4    12 ms    10 ms    10 ms  ae2-0.TPA01-BB-RTR2.verizon-gni.net [130.81.199.82]
  5    16 ms    16 ms    15 ms  0.ae4.XL2.MIA19.ALTER.NET [152.63.8.117]
  6    14 ms    16 ms    16 ms  0.xe-11-0-0.GW1.MIA19.ALTER.NET [152.63.85.94]
  7    19 ms    16 ms    16 ms  microsoft-gw.customer.alter.net [63.65.188.170]
  8    27 ms    33 ms     *     ge-5-3-0-0.ash-64cb-1a.ntwk.msn.net [207.46.46.177]
  9     *        *        *     Request timed out.
 10    44 ms    43 ms    43 ms  207.46.37.235
 11    42 ms    41 ms    40 ms  10.22.112.225
 12    42 ms    43 ms    43 ms  10.175.9.1
 13    42 ms    41 ms    42 ms  100.94.68.79
 14    40 ms    40 ms    41 ms  100.94.80.193
 15     *        *        *     Request timed out.

Antworten:


11

Es ist zulässig, dass Router über RFC1918 oder andere private Adressen eine Verbindung herstellen. Dies ist beispielsweise bei Punkt-zu-Punkt-Verbindungen und bei Routing innerhalb eines AS häufig der Fall.

Nur die Border Gateways in einem Netzwerk benötigen öffentlich routbare IP-Adressen, damit das Routing funktioniert. Wenn die Schnittstelle eines Routers keine Verbindung zu einem anderen AS (oder einfach zu einem anderen Dienstanbieter) herstellt, muss die Route nicht im Internet angekündigt werden, und nur Geräte, die derselben Entität gehören, müssen sich direkt mit dem verbinden Schnittstelle.

Dass die Pakete auf diese Weise in traceroute zu Ihnen zurückkehren, stellt eine leichte Verletzung von RFC1918 dar, es ist jedoch nicht erforderlich, NAT für diese Geräte zu verwenden, da sie selbst keine Verbindung zu beliebigen Dingen im Internet herstellen. Sie fahren nur am Verkehr vorbei.

Dass der Datenverkehr über mehrere Organisationen (möglicherweise auf Umwegen) geleitet wird, ist lediglich eine Folge des Betriebs von Routing-Protokollen für externe Gateways. Es scheint völlig vernünftig, dass Microsoft ein gewisses Rückgrat hat und einige Leute damit gleichgesinnt sind. Sie müssen kein Wholesale-ISP sein, um den Datenverkehr weiterzuleiten.

Es ist nicht besonders seltsam, dass der Datenverkehr mehrere Router mit privaten IP-Adressen durchlaufen hat, die jeweils eine öffentliche IP-Adresse zwischen sich haben. Dies zeigt lediglich an, dass (in diesem Fall) zwei verschiedene Netzwerke entlang des Pfades den Datenverkehr über ihre eigenen Router geleitet haben die sie gewählt haben, um auf diese Weise zu nummerieren.


16

Nicht nur RFC 1918, sondern auch RFC 6598 , dh 100.64.0.0/10CGN-Space. Bei beiden handelt es sich um private Netzwerke, letzteres ist jedoch in jüngerer Zeit standardisiert und weniger bekannt.

Dies ist aus Traceroute-Sicht nicht ungewöhnlich. Sie sprechen nicht direkt mit diesen Hosts mit 10 und 100 Speicherplätzen, sondern senden Pakete mit inkrementell größeren TTLs an Ihren nächsten Hop-Router. Damit die Antwort nicht zu lang wird, fasst dieser Wikipedia-Link den Vorgang zusammen.

Was ist ungewöhnlich ist , dass dass dieses Paket öffentlichen IP - Raum durchquert und dann privaten IP - Raum getunnelt durch noch einmal ein „öffentliches“ Netz zu erreichen. 157.56.176.94Microsoft gehört und das Paket durchläuft MS-Netzwerke, bevor es auf das private Netzwerk trifft. Microsoft wählt also einfach, was mit dem Netzwerkbereich an beiden Enden des privaten Bereichs geschehen soll. Sie machen Werbung für die Routen. Die anderen Router tun einfach das, was ihnen gesagt wird.

Nein, Netzbetreiber setzen ihre privaten Netze im Allgemeinen nicht auf einer Route zum öffentlichen IP-Raum von außerhalb ihres Netzwerks aus. Deshalb ist das so ungewöhnlich.

(Es könnte sein, dass irgendwo an der Grenze eine Route fehlt, die dazu führt, dass die Pakete einen nicht optimalen Pfad durchlaufen, der schließlich das Ziel erreicht. Aber ich bin kein Netzwerk-Typ, und jemand kann wahrscheinlich besser darauf eingehen.)


1
Die meisten Traceroute-Implementierungen basieren auf UDP + ICMP.
Dmourati

@dmourati Als Unix-Administrator bin ich gezwungen, rot zu werden. Duh. Vielen Dank.
Andrew B

Nach meiner Erfahrung ist dies überhaupt nicht ungewöhnlich. Viele Netzbetreiber verwenden 10.0.0.0/8 in ihrem Netzwerk und stellen eine störende Menge davon zur Verfügung.
Paul Gear
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.