発信インターフェースをトレースする方法は？

Unixコマンドtracerouteは、ソースノードから宛先ノードまでのノードのIPアドレスをトレースします。間にあるすべてのノードには、着信および発信インターフェイスがあります。

traceroute -n dston srcを実行すると、src、dst、およびその間のホップのすべての着信インターフェイスのIPアドレスが表示されます。

しかし、発信IPアドレスをトレースする方法は？

更新

ping -R提案を試しましたが、うまくいかないようです。これは、パブリックWebサーバーへのtracerouteです。

$ ping -n -c 1 -R 212.227.222.9
PING 212.227.222.9（212.227.222.9）56（124）バイトのデータ。
212.227.222.9から64バイト：icmp_req = 1 ttl = 57 time = 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 ping統計---
1パケット送信、1受信、0％パケット損失、時間0ミリ秒
rtt min / avg / max / mdev = 47.441 / 47.441 / 47.441 / 0.000 ms

そして、これが私のダイヤルアップ接続のIPアドレスです。

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

ただし、pingコマンドでは記録されていません。その理由は何ですか？

私はあなたの質問に対する答えではありませんが、それはあなたが望むことを（場合によっては）行うための単純な（しかし限定された）方法です。私はpingのmanページのオプション-Rを対処しています。

-Rルートを記録します。ECHO_REQUESTパケットにRECORD_ROUTEオプションを含め、返されたパケットのルートバッファーを表示します。IPヘッダーは、9つのルートに十分な大きさであることに注意してください。多くのホストはこのオプションを無視または破棄します。

したがって、ECHO_REQUESTの戻りパスも確認できます。これは、出力インターフェイスが復帰パスと同じでない限り、（求めている）出口インターフェイスではありません。この場合のみ、戻りパスは、要求している発信インターフェイスのIPアドレスです。

これは私のインターネットプロバイダーネットでの実際の例です。あまり明確ではないかもしれませんが、相互にリンクするためのルーターがありません:)

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）バイトのデータ。

10.2.105.178から64バイト：icmp_req = 5 ttl = 253 time = 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

----省略----

10.2.105.178から64バイト：icmp_req = 6 ttl = 253 time = 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 ##毎回変更、理由がわからない##

10.189.48.1

192.168.1.254

192.168.1.133

RFC1812によれば、ルーターによって生成されたICMPメッセージの送信元アドレスは、パケットが通常送信者に返される出力インターフェイスの送信元アドレスである必要があります。

実際には、ルータが入力インターフェイスのソースを使用してICMP応答をソースするという非標準の動作に直面する可能性が非常に高いです。通常、これによりtracerouteがはるかに読みやすくなります。

YLearnの質問の補足として、ネットワーク図といくつかの出力を投稿します。

R5のループバック5.5.5.5からR1のループバック1.1.1.1にtracerouteを実行していると仮定します。ご覧のとおり、順方向パスはR4-R2を経由し、逆方向パスは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

R5からのtraceroute出力は次のようになります。

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

したがって、R1によって生成された実際のICMPトラフィックがR3経由でR5に戻る間、ICMP到達不能メッセージのIPヘッダーには入力インターフェイス10.1.12.1のソースが含まれます。

私の経験では、CiscoとJuniperのルーターがどのように動作するか、他のベンダーについてはわかりません。