リクエストのタイムアウトと宛先ホストに到達できません
1. 序章
システム管理者が日常業務で直面するさまざまなエラーメッセージの意味を理解することは、問題やボトルネックをすばやく特定してトラブルシューティングするためのキーです。 そのため、最近の分散システムで頻繁に発生するエラーの中には、「リクエストがタイムアウトしました」および「宛先ホストに到達できません」というメッセージがあります。
このようなエラーは、誰かの日を台無しにする可能性があります。 実際、それらはさまざまな問題の兆候であり、確実に注意と早急な対応が必要になります。
このチュートリアルでは、これらのエラーについて少し掘り下げ、トラブルシューティングに役立ついくつかのツールについて説明します。
2. インターネット制御メッセージプロトコル
インターネット制御メッセージプロトコル(ICMP)は、由緒あるIPプロトコル( RFC791 )とともに最初に設計され、1981年にさかのぼるRFC792で定義されています。 。 IPネットワークに診断および制御メッセージを提供することを目的としています。
TCPやUDPなど、他の主要なインターネットプロトコルと同様に、IP上で実行されます。 元の機能の一部が現在廃止されているにもかかわらず、それはまだかなり使用されています。 その制御メッセージの多くは、ネットワークまたはそのゲートウェイの接続の問題を通知するために発生します。 これらの問題に関連するより一般的なICMP制御メッセージは次のとおりです(完全なリストについては、 this を確認してください)。
2.1. 宛先ホストに到達できません
サブクラス「DestinationHostUnreachable」を含む「DestinationUnreachable」制御メッセージは、ユーザーホストまたはそのゲートウェイが宛先に到達するためのパスを見つけられない場合に発生します。
したがって、それが発生した場合、それは通常、ユーザーから目的地までの利用可能な適切なルートが不足していることが原因です。 珍しいことですが、この種のメッセージを生成する可能性のあるネットワークとファイアウォールの構成または管理アクションがあることに注意する必要があります。
2.2. リクエストタイムアウト
一方、「要求タイムアウト」は、クライアントソフトウェアが特定の時間内に(たとえば、エコー要求制御メッセージに対する)応答を受信できないことに関連しています。 これは実際のICMP制御メッセージではありません。
これは、ネットワークの輻輳、ホストのダウンまたは応答不能、パケット損失などの多くの要因により、しばらくして応答がまったく受信されなかった場合に生成されます。
2.3. 時間超過
対照的に、「Time Exceeded」ICMP制御メッセージは、時間ではなく距離に関連しています。 ネットワークスタックが新しいIPパケットを作成するたびに、TTLとも呼ばれる「存続時間フィールド」が挿入されます。 IPv6仕様では、このフィールドの名前を「ホップ制限」に変更し、その機能を維持しています。
ネットワークを通過している間、パケットがネクストホップに進むたびに、そのTTL値は1つ減少します。 0(ゼロ)に達するとすぐに、「TimeExceeded」制御メッセージがパケットの発信元ホストに送信され、パケットが元のパケットのTTLよりも長く移動することを通知します。
この動作はこのイメージに示されています。クライアントは、開始TTLが10のIPパケットを宛先サーバーに送信します。 パス内の各ホップは、宛先に到達するまでTTLを減少させます。
可能な最大TTL(またはIPv6のホップ制限)は255です。これは、これが単一のポイントツーポイントインターネット会話で許可される最大のホップ距離であることを意味します。 中流階級の攻撃に典型的な動作であるにもかかわらず、パケットを分解し、新しいパケットを組み立てることができるルート内のプロキシを使用して、この距離を伸ばすことができます。
2.4. Traceroute
表に、Traceroute制御メッセージが非推奨になっていることがわかります。 これは、ネットワーク接続の問題を診断するためにtracerouteまたはtracertコマンドを毎日使用する管理者にとっては奇妙に聞こえるかもしれません。
事実、現在、その機能は実際には冗長でした。 ちなみに、これは、連続したICMPエコー要求、 TCP SYN 、またはUDPプローブパケットを送信することによって実装されています。 送信パケットのTTLを、1からターゲットに到達するために必要なホップ数まで段階的に増やします。
パケットが宛先に到達できない場合、またはTTLがゼロになると、ICMP制御メッセージが返送されます。 このようにして、クライアントソフトウェアは、対応するICMP制御メッセージを送信したホストのIPを登録します。
3. ネットワーク接続の問題を診断するためのユーティリティ。
「リクエストがタイムアウトしました」や「宛先ホストに到達できません」などのエラーが発生した場合、最初に行う必要があるのは、その根本的な原因を特定することです。
IPスタックを実装するオペレーティングシステムには、システム管理者が自由に使用できる一連のトラブルシューティングユーティリティが必要です。 より一般的なものを見ていきます。
3.1. Ping
頭に浮かぶ最初のネットワーク診断コマンドはpingです。このユーティリティは、IPプロトコル自体とほぼ同じくらい古いものです。 これは、ICMPエコー要求を送信することによって機能します。 次に、対応するエコー応答制御メッセージを受信するために必要な時間を測定します。
それが特定の時間に発生しない場合、結果として「リクエストがタイムアウトしました」というメッセージが発行されます。
たとえば、2つのホスト間に接続があるかどうかを確認し、それらの通信遅延( ping の出力の1つはラウンドトリップ時間– RTT)とパケット損失を確認します。 そうすれば、次を使用できます。
# ping -c 10 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=31.8 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=31.7 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=31.2 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=30.2 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=53 time=31.1 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=53 time=79.1 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=53 time=30.6 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=53 time=319 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=53 time=31.5 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=53 time=29.9 ms
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9015ms
rtt min/avg/max/mdev = 29.904/64.621/319.028/86.009 ms
パラメータ-cは、送信されるプローブパケットの数を指定するために使用されます。 ご覧のとおり。 IP 1.1.1.1を10パケットでプローブしている間、パケット損失は0%で、平均ラウンドトリップ時間は64ミリ秒で、平均標準偏差は86ミリ秒でした。
ping コマンドの現在のバージョンには多数のオプションがあり、コマンドping-h。を使用してそれらすべてを確認できます。
3.2. pingの一般的なアプリケーション
遅延とデータ損失を見積もるために、次のように、多数のパケットとより大きなペイロードが必要になる場合があります。
# sudo ping -f -c 579 -s 1460 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 1460(1488) bytes of data.
............
--- 10.1.1.1 ping statistics ---
579 packets transmitted, 567 received, 2.07254% packet loss, time 9249ms
rtt min/avg/max/mdev = 148.030/154.707/408.936/25.042 ms, pipe 14, ipg/ewma 16.000/149.251 ms
-f (可能な限り最速のパケットレート)および -s (パケットペイロードサイズ)オプションが設定されたコマンドは、より高い負荷を生成し、-fオプションはスーパーユーザーのみに制限されます。 実際のところ、-fオプションを使用して他のパーティのシステムをプローブすることは絶対にしないでください。これは、偽のトラフィックと見なされ、悪意のあるものと見なされる可能性があるためです。
ちなみに、オプション-fと-sには、DoS(サービス拒否攻撃)によって悪用された歴史があります。 有名なPingof Death 攻撃のように、パケットの断片化のバグを標的にして、数百万ドルのマシンを次のような簡単なコマンドで停止させることができます。
# ping -s 65535 <host IP>
現在、これらの攻撃には脆弱なターゲットがほとんどありませんが、ICMP制御メッセージは、ネットワークと潜在的なターゲットをマッピングするために、攻撃者候補によって広く使用されています。
そのため、ファイアウォールを使用して、ICMP制御メッセージが内部ネットワーク要素と宛先に渡すことができるものを制御するのが一般的です。
ベストプラクティスは、基本的なトラブルシューティングに必要な少数の内部ホストへの着信ICMPトラフィックのみを許可し、アウトバウンドをICMPエコー要求および応答制御メッセージのみに制限することです。
3.3. traceroute
「宛先ホストに到達できません」などのメッセージが表示された場合は、そのホストへのルーティング検出に問題があることがわかります。 したがって、発生場所を特定するには、tracerouteコマンドを使用できます。
このコマンドは、2つのホスト間のホップをトレースします。
プローブに使用するプロトコル( ICMP 、 UDP、またはTCP の中から)、プローブの数とタイミングを選択し、ルーター、ゲートウェイ、または使用するインターフェイスを使用して、ルートに沿って MTU (最大伝送ユニット、つまり断片化のない最大のペイロード)をプローブするか、ターゲットから独自のホストへの逆ルートを推測します。
たとえば、ホストからgoogleDNSへのルートをマッピングしましょう。
# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.0.2.1 4.162 ms 3.856 ms 3.705 ms
2 201.88.63.1 9.591 ms 9.481 ms 9.371 ms
3 100.120.69.45 9.265 ms 100.120.69.47 9.155 ms 9.991 ms
4 177.2.210.10 10.101 ms 100.120.22.7 10.107 ms 100.120.22.247 9.663 ms
5 100.120.24.241 33.581 ms 100.120.22.212 27.239 ms 27.133 ms
6 100.120.20.240 30.848 ms 100.120.20.246 28.394 ms 100.120.25.80 23.335 ms
7 * 72.14.198.152 30.368 ms *
8 * * *
9 8.8.8.8 28.958 ms 32.079 ms 31.915 ms
オプション-nは、ホスト名を解決しないように要求します。 コマンドの出力は、ローカルマシンからGoogle DNSサーバーへの9ホップを示しており、注意すべき非常に興味深いことがいくつかあります。
- アスタリスクマークは、タイムアウトしたプローブを示しています。ネット上で、8番目のホップなどのある種のプローブに応答しないゲートウェイを見つけることは珍しくありません。
- 一部のホップ、3番目、4番目、5番目、および6番目では、さまざまなホストからの回答がありました。つまり、複数のルートが使用可能であり、プローブはさまざまなゲートウェイを通過しました。
- 各ホップ間の時差により、往復時間にさらに時間を追加しているホップを確認できます。 したがって、100ミリ秒を超えるホップ間時間差が一貫して見られる場合は、おそらく国際ルートが見られます。 500ミリ秒を超えると、パケットが衛星パケットを通過する可能性があります。
多数のパラメーターの完全なリストについては、 traceroute –helpコマンドを発行できます。
4. 結論
このチュートリアルでは、「DestinationHostUnreachable」や「RequestTimeout」などの一般的なエラーについて簡単に説明しました。 さらに、それらが互いにどのように関連しているか、およびそれらを分析するために使用するいくつかのツールについて、よりよく理解することができました。
ただし、ネットワークの問題についての理解を深めることができるネットワーク分析ツールは次のとおりです。
時々、私たちはもっと深く行く必要があります。 ネットワークパケットの構造、ヘッダー、およびペイロードを表示できるツールを使用して、トラフィックを分析し、その内容を確認します。 さらに言えば、 Tcpdump 、またはWiresharkのようなグラフィカルパケットアナライザーを使用できます。
また、ネットワーク自体とそのホストに関する詳細情報を収集する必要がある場合もあります。 そのため、 Nmap を使用できます。これは、ネットワーク内のホストの非常に詳細な分析を実行し、ホストが実行しているサービスを検出できるツールです。
最後になりましたが、 tc コマンドを使用してネットワークの問題をシミュレートし、ネットワークの誤動作の特定のシナリオでシステムがどのように動作するかを評価できます。