Comment tracer les interfaces sortantes?

La commande Unix traceroutetrace les adresses IP des nœuds d'un nœud source à un nœud de destination. Chaque nœud intermédiaire a une interface entrante et sortante.

traceroute

L'exécution de traceroute -n dston srcaffichera les adresses IP de src, dst et toutes les interfaces entrantes des sauts intermédiaires.

Mais comment tracer les adresses IP sortantes?

Mise à jour

J'ai essayé la ping -Rsuggestion mais cela ne semble pas fonctionner. Voici la traceroute vers un serveur Web public:

$ ping -n -c 1 -R 212.227.222.9
PING 212.227.222.9 (212.227.222.9) 56 (124) octets de données.
64 octets de 212.227.222.9: icmp_req = 1 ttl = 57 temps = 47,4 ms
RR: 192.168.2.111
        169.254.1.1
        87.186.224.94
        62.154.76.34
        62.154.12.175
        212.227.117.13
        212.227.117.8
        10.71.3.253
        212.227.222.9


--- 212.227.222.9 statistiques ping ---
1 paquets transmis, 1 reçu, 0% de perte de paquets, temps 0 ms
rtt min / moy / max / mdev = 47,441 / 47,441 / 47,441 / 0,000 ms

Et ceci est l'adresse IP de ma connexion d'accès à distance.

$ curl -s https://toolbox.googleapps.com/apps/browserinfo/info/ | jq -r .remoteAddr
93.192.75.247

Mais il n'a pas été enregistré par la commande ping. Quelle peut être la raison?

ping traceroute

— ceving
source

Astuce: le moyen le plus rapide d'obtenir votre adresse IP publique est curl ifconfig.me. La chose la plus simple sur Internet. Les doigts dans le nez.

— Ryan Foley

ICMP ne vous donnera jamais les informations que vous cherchez à obtenir avec précision. Le comportement par défaut consiste à utiliser l'interface de sortie du message ICMP, mais elle peut généralement être configurée pour provenir d'autres interfaces. Disons que j'ai un routeur Internet qui utilise l'adressage RFC1918 entre les interfaces de routeur au sein de mon propre réseau, mais je ne veux pas fournir ces adresses au public, je peux attribuer une IP publique à une interface de bouclage et générer tout le trafic ICMP à partir de cette interface. Vous n'obtenez ni les interfaces "entrantes" ni "sortantes" et ne le recevrez jamais de cet appareil.

— Apprendre

@RyanFoley ifconfig.me n'est pas fiable (1 erreur sur 5 tests) et il est lent: une requête prend 2,8s. La boîte à outils de Google a besoin de 0,7 s.

— ceving

Une réponse vous a-t-elle aidé? si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.

— Ron Maupin

Réponses:

Je ne suis pas exactement la réponse à votre question, mais c'est une façon simple (mais limitée) de faire (dans certains cas) ce que vous voulez. J'adopte-poste l'option -R de la page de manuel ping:

-R Enregistrer l'itinéraire. Inclut l'option RECORD_ROUTE dans le paquet ECHO_REQUEST et affiche le tampon de route sur les paquets retournés. Notez que l'en-tête IP n'est suffisant que pour neuf de ces routes. De nombreux hôtes ignorent ou ignorent cette option.

Ainsi, vous pouvez également voir le chemin de retour de ECHO_REQUEST, ce n'est pas l'interface de sortie (que vous demandez) sauf si le chemin sortant est le même que le chemin de retour. Dans ce cas uniquement, le chemin de retour est l'adresse IP de l'interface sortante que vous demandez.

C'est un vrai exemple sur mon réseau de fournisseur Internet, peut-être pas si clair, mais je n'ai pas pour l'instant de routeur pour se relier :) dest 10.2.105.178

traceroute 10.2.105.178
traceroute to 10.2.105.178 (10.2.105.178), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  3.418 ms  3.575 ms  4.021 ms
 2  10.189.48.1 (10.189.48.1)  11.237 ms * *
 3  10.2.105.178 (10.2.105.178)  15.235 ms * *

ping -R 10.2.105.178 PING 10.2.105.178 (10.2.105.178) 56 (124) octets de données.

64 octets à partir du 10.2.105.178: icmp_req = 5 ttl = 253 temps = 74,1 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.178

10.189.48.1

192.168.1.254

192.168.1.133

----omis----

64 octets à partir du 10.2.105.178: icmp_req = 6 ttl = 253 temps = 13,0 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.218 ## changer à chaque fois, je ne sais pas pourquoi ##

10.189.48.1

192.168.1.254

192.168.1.133

— feligiotti
source

Je ne sais pas si j'ai bien compris ce que fait RECORD_ROUTE, mais il ne semble pas être ce dont j'ai besoin. Je l'ai essayé avec une connexion commutée. Je connais l'adresse publique de mon routeur d'accès à distance et j'ai un itinéraire de neuf tronçons vers un serveur Web public. Pour chacun des sauts, j'ai essayé l' -Roption. Le quatrième saut était le premier, qui a répondu à la demande. Mais la réponse ne contient pas mon adresse publique. Et bien que ce ne soit que le quatrième saut, la réponse contient 9 adresses.

— ceving

juste un instant, je prépare un exemple

— feligiotti

Le ping -Rdoit être utile uniquement pour un saut très limité. Je dis avant que c'est une voie restreinte

— feligiotti

Le même exemple ne fonctionne pas pour mon réseau commuté. Je ne sais pas pourquoi. Peut-être NAT?

— ceving

Salut @Ceving, fais un traceroute 212.227.222.9puis fais un ping -R au troisième saut que tu as trouvé dans la traceroute. De cette façon, vous avez le même schéma que j'ai fait pour lire la réponse. Le total de neuf routes signifie aller et revenir, donc si vous le faites, vous ne ping -R 212.227.222.9pouvez pas voir le chemin complet, mais seulement la dernière partie

— feligiotti

Selon RFC1812, l'adresse source du message ICMP généré par le routeur devrait être celle de l'interface de sortie sur laquelle le paquet retournerait normalement à l'expéditeur.

En réalité, il est très probable que vous fassiez face à un comportement non standard où le routeur fournira la réponse ICMP avec la source de l'interface d'entrée. Cela facilite généralement la lecture du traceroute.

Pour faire suite à la question de YLearn, je publie un schéma de réseau et quelques sorties. Exemple de topologie pour illustrer le fonctionnement de traceroute

Supposons que nous gâchons le traceroute du bouclage de R5 5.5.5.5 au bouclage de R1 1.1.1.1. Comme vous pouvez le voir, le chemin aller se fait via R4-R2, tandis que le chemin inverse est R3-R4.

R4#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "bgp 4", distance 20, metric 0
Tag 2, type external
Last update from 10.1.24.2 00:02:42 ago
Routing Descriptor Blocks:
* 10.1.24.2, from 10.1.24.2, 00:02:42 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2

R1#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "bgp 1", distance 20, metric 0
Tag 3, type external
Last update from 10.1.13.3 00:14:18 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.13.3, 00:14:18 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2
  Route tag 3
  MPLS label: none

La sortie traceroute de R5 se présente comme suit:

R5#traceroute
Protocol [ip]:
Target IP address: 1.1.1.1
Source address: 5.5.5.5
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 208 msec 140 msec 100 msec
2 10.1.24.2 96 msec 44 msec 104 msec
3 10.1.12.1 224 msec 220 msec 112 msec

Ainsi, alors que le trafic ICMP réel généré par R1 revient à R5 via R3, l'en-tête IP du message ICMP inaccessible aura la source de l'interface d'entrée 10.1.12.1.

D'après mon expérience sur le comportement des routeurs Cisco et Juniper, je ne suis pas sûr des autres fournisseurs.

— mkurek
source

Probablement juste moi, mais la deuxième phrase me rend un peu confus. Êtes-vous en train de dire qu'il est courant qu'un appareil sur Internet réponde en utilisant l'interface d'entrée du trafic qui a provoqué la génération du message ICMP? Donc, si le trafic est reçu sur Int1 et que le message ICMP sort Int2, il provient d'Int1? Ou faites-vous référence à une interface d'entrée différente (et si oui, laquelle)? D'après mon expérience, la plupart des routeurs fonctionnent comme les états RFC, en utilisant l'interface de sortie du message par défaut, et que dans la plupart des cas, c'est la même interface que le trafic a été reçu.

— Apprendre