ネットワーキングの分野で働いたことがある場合、またはその問題をサポートしている場合は、失われた接続のトラブルシューティングに関する良い話があるでしょう。必然的に、いくつかの新しいシステムがインストールおよび構成されますが、システムとの間でトラフィックをやり取りすることはできません。
私が思い出すことができるそのような話の1つは、次のようなものです。
ユースケース
私は、有名なアメリカの大手金融会社によってインストールされたばかりのバックエンドストレージアレイのトラブルシューティングを行っていました。顧客は、ヒューストンの本番（PROD）サイトからサンアントニオのディザスタリカバリ（DR）サイトへのデータレプリケーションを構成しようとしていました。ディザスタリカバリシステムは長い間実装されており、優れた構成として知られているという評判がありました。
生産現場は真新しく、もちろん、私たちのすべての問題の原因でした。本当の問題は、構成した2つのレプリケーションインターフェイス間でトラフィックを移動させることができなかったことです。 DRサイトのゲートウェイの外に到達することはできましたが、PRODサイトの外に到達することはできませんでした。トラフィックがゲートウェイデバイスに到達し、ドロップされていました。
トラブルシューティングから30分以内に、必要なポートのトラフィックをブロックしている可能性のあるファイアウォールがPRODサイトにあるかどうかをクライアントに尋ねました。 「もちろんそうではありません。これらのサイト間にファイアウォールはありません。」全国最大級の金融機関であることを考えると、この反応は衝撃的でした。しかし、すべての顧客対応の立場が進むにつれて、あなたは敬意を持って礼儀正しくなければなりません。
それで、私は自分の側から考えることができるすべてのチェックを実行しました。内部ストレージファイアウォールが無効になっています：確認してください。 DRからPRODへのポートが開いています：確認してください。 PRODからDRへのポートが開いていますか？いいえ。
インターフェースのトラブルシューティングと再構成を4時間行った後、お客様から「ファイアウォール担当者に電話をかけてもらいましょう」と言われたことがわかりました。
あなたの何人ですか？
これらのサイト間にファイアウォールがないことを考えると、これは奇妙な立場です。しかし、それは奇妙なことではありませんでした。もちろん、ファイアウォールがあったからです。問題が解決しました。悪夢が終わったので、問題が発生した場所を特定するために使用したツールは、古き良きTelnet（後の記事で説明します）であり、もちろんtraceroute 。
コマンド
これで、tracerouteの明確なユースケースを確認できます。 、コマンド自体と、コマンドから取得できる情報について説明しましょう。結局のところ、この記事の目的は、tracerouteというユーティリティについてもう少し知識を身に付けることです。 オファー。
構文はかなり単純です。コマンドtraceroute <x> （x ここではIPまたはホスト名）が最も基本的なバージョンであり、指定されたターゲットにパケットを送信し始めます。この結果により、マシンから各システムに送信された、ユーザーと目的の宛先の間のパケットのパスを追跡できます。
たとえば、コンピュータからgoogle.comまでのパスを追跡したい場合 、次のように入力します：
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 119.355 ms 119.315 ms 119.508 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 120.321 ms 119.836 ms 120.009 ms
5 66.sub-69-83-106.myvzw.com (69.83.106.66) 119.042 ms 119.489 ms 119.156 ms
6 2.sub-69-83-107.myvzw.com (69.83.107.2) 120.039 ms 125.954 ms 101.450 ms
7 112.sub-69-83-96.myvzw.com (69.83.96.112) 110.757 ms 108.485 ms 122.108 ms
8 112.sub-69-83-96.myvzw.com (69.83.96.112) 115.028 ms 121.073 ms 125.537 ms
9 116.sub-69-83-96.myvzw.com (69.83.96.116) 121.793 ms 124.769 ms 124.434 ms
10 Bundle-Ether10.GW6.DFW13.ALTER.NET (140.222.237.123) 128.082 ms 128.400 ms 126.509 ms
11 google-gw.customer.alter.net (204.148.43.118) 106.276 ms 107.885 ms 105.718 ms
12 108.170.252.129 (108.170.252.129) 99.725 ms 101.797 ms 108.170.252.161 (108.170.252.161) 101.671 ms
13 108.170.230.109 (108.170.230.109) 101.207 ms 100.515 ms 99.730 ms
14 dfw06s48-in-f100.1e100.net (216.58.194.100) 99.059 ms 94.502 ms 94.015 ms
[root@rhel8dev ~]# 内訳
これらの結果をより小さなバイトに分解してみましょう。このコマンドは多くの情報を生み出すことができ、ことわざにあるように、「象を食べる最良の方法は一度に一口食べることです：」
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms ここでは最初のホップのみを確認しています。ただし、このホップを使用して、表示されている情報を分析できます。まず、実際に何が送信されているか、どこに送信されているかを確認します。
traceroute to www.google.com(IP), 30 hops max, 60 byte packets
この出力から、目的のターゲット（www.google.com）にトラフィックを送信していることがわかります。 ）。 Tracerouteは、デフォルトで、60バイトのパケットの30ホップを測定します。
次に、最初のホップが発生するのを確認します。ここでは、外部ゲートウェイにアクセスしています：
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
ここで、ホップ1が実際に着陸した場所を確認できます。次に、3つの数値があります。これらはラウンドトリップ時間（RTT）と呼ばれ、特定のパケットが宛先に到達してICMPメッセージを送信元にルーティングするのにかかる時間を指します。デフォルトでは、traceroute データの3つのパケットをルーティングして、各ホップをテストします。このプロセスの詳細についてはオンラインで確認できますが、ネットワーク上のデバイスに到達すると、すべてのパケットがICMPエラーメッセージを送信元にルーティングします。このアクションにより、tracerouteが許可されます そのパケットのRTTを決定するためであり、必ずしもエラーを示すわけではありません。
それでは、ホップ2から4を見てみましょう。
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 109.206 ms 109.400 ms 109.423 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 124.793 ms 123.585 ms 124.585 ms ここで何か新しいものを見ることができます。ホップ2は正常に見えます：デバイスは100ミリ秒の範囲のRTT時間でヒットします。すると、面白くなります。星（*）のみが表示されます。
これらの星（アスタリスク）はどういう意味ですか？パケットはドロップされましたか？タイムアウトしましたか？
説明させてください。これらの星に関しては、2つの可能性があります。まず、ICMP/UDPが設定されていない可能性があります。 tracerouteの場合 コマンドが正常に完了し、これらの星が表示されます。ヒットしたデバイスがICMP/UDPトラフィックに応答するように構成されていない可能性があります。この結果は、トラフィックが通過しなかったことを意味するものではありません。 2つ目の可能性は、ネットワーク上の問題が原因でパケットがドロップされたことです。これらの結果は通常、パケットタイムアウトであるか、トラフィックがファイアウォールによってブロックされています。
上記の例でわかるように、ホップ2に星が表示された後でも、パケットは続行され、ホップ4に戻されます。この動作により、tracerouteが成功します。 Googleに到達したことがわかります。
お持ち帰り
Tracerouteは、ネットワークの問題のトラブルシューティングに関して非常に貴重なツールになる可能性があります。問題が実際に発生している場所を視覚化するのに役立ちます。もちろん、tracerouteの舞台裏で行われている他の操作もあります ここでは取り上げませんでした。
このツールをさらに詳しく調べたい場合は、オンラインで調査することを強くお勧めします。 Time-to-Live（TTL）とRTTについては、時間の都合上、この記事には含まれていなかった多くの情報があります。私の目標は、tracerouteをいつどのように使用すべきかをよりよく理解できるようになることです。 ツール、およびそれが提供するデータを解釈する方法。ネットワークのトラブルシューティングと概念の詳細については、こちらの関連記事をご覧ください。