Adresse RFC 1918 sur Internet ouvert?

En essayant de diagnostiquer un problème de basculement avec mes pare-feu Cisco ASA 5520, j'ai exécuté un traceroute vers www.btfl.com et, à ma grande surprise, certains sauts sont revenus sous forme d'adresses RFC 1918.

Juste pour être clair, cet hôte n'est pas derrière mon pare-feu et aucun VPN n'est impliqué. Je dois me connecter sur Internet pour y accéder.

Comment / pourquoi est-ce possible?

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  *  *  *

et il fait la même chose depuis ma connexion FiOS à la maison:

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.

Il est permis aux routeurs de se connecter les uns aux autres à l'aide de la RFC1918 ou d'autres adresses privées, et en fait, cela est très fréquent pour des choses comme les liaisons point à point et tout routage qui a lieu à l'intérieur d'un AS.

Seules les passerelles frontalières d'un réseau ont réellement besoin d'adresses IP routables publiquement pour que le routage fonctionne. Si l'interface d'un routeur ne se connecte à aucun autre AS (ou à tout autre fournisseur de services, plus simplement), il n'est pas nécessaire de publier l'itinéraire sur Internet, et seul l'équipement appartenant à la même entité devra se connecter directement au interface.

Le fait que les paquets vous reviennent de cette façon dans traceroute est une légère violation de la RFC1918, mais il n'est pas réellement nécessaire d'utiliser NAT pour ces appareils car ils ne se connectent pas eux-mêmes à des choses arbitraires sur Internet; ils passent juste le long du trafic.

Le fait que le trafic emprunte la route (éventuellement détournée) à travers plusieurs organisations est simplement une conséquence du fonctionnement des protocoles de routage de passerelle extérieure. Il semble tout à fait raisonnable que Microsoft possède une colonne vertébrale et que certaines personnes y aient jeté un œil; vous n'avez pas besoin d'être un FAI de gros pour acheminer le trafic.

Le fait que le trafic ait traversé plusieurs séries de routeurs avec des adresses IP privées, transitant par des routeurs avec des adresses IP intermédiaires, n'est pas particulièrement étrange - cela indique simplement (dans ce cas) que deux réseaux différents le long du chemin ont acheminé le trafic via leurs propres routeurs. qu'ils ont choisi de numéroter de cette façon.

Pas seulement la RFC 1918 ... mais aussi la RFC 6598 , c'est-à-dire l' 100.64.0.0/10espace CGN. Il s'agit de réseaux privés, mais ce dernier est plus récemment standardisé et moins connu.

Ce n'est pas inhabituel d'un point de vue traceroute. Vous ne parlez pas directement à ces hôtes 10espaces et 100espaces, vous envoyez des paquets avec des TTL incrémentalement plus grands à votre routeur de saut suivant. Pour éviter que la réponse ne soit trop longue, ce lien Wikipédia résume le processus.

Ce qui est inhabituel, c'est que ce paquet traverse l'espace IP public, puis est tunnelé à travers l'espace IP privé pour atteindre à nouveau un réseau "public". 157.56.176.94appartient à Microsoft, et le paquet traverse les réseaux appartenant à MS avant de toucher le réseau privé ... c'est donc simplement ce que Microsoft choisit de faire avec son espace réseau aux deux extrémités de l'espace privé. Ils annoncent les itinéraires; les autres routeurs font juste ce qu'on leur dit.

En règle générale, non, les opérateurs de réseau n'exposent généralement pas leurs réseaux privés le long d'un itinéraire à l'espace IP public depuis l'extérieur de leur réseau. C'est pourquoi c'est si inhabituel.

(Il pourrait s'agir d'une route manquante quelque part sur leur frontière, obligeant les paquets à traverser un chemin non optimal qui finit par atteindre sa destination, mais je ne suis pas un type de réseautage et quelqu'un peut probablement mieux essayer)