pingが成功してもサービスは駄目なことがある
一言でいうと
pingが証明するのは、IP層までの到達性だけです。その上のポートも、その上のアプリケーションも、さらには大きなパケットが通れるかどうかも証明しません。
なぜ必要なのか
「pingは通るのに接続できない」は矛盾ではなく、正常な状態です。pingはICMP echoをやり取りするだけです。TCP 8080が開いているかはまったく別の問いで、そのポートが開いていても、アプリケーションが5xxを返すことがあります。
逆の方向も重要です。pingが失敗しても、サービスは問題なく動いていることがあります。多くの組織がICMP echoを遮断しているからです。したがって、「pingが通らないからサーバーが死んでいる」という判断は危険です。
どう動くのか
3つのツールは役割が違います。
| ツール | 何を見るか | この環境での注意 |
|---|---|---|
ping |
宛先までIPの往復ができるか | 動作します(ping_group_rangeが許可されています) |
traceroute |
どのホップまで届くか | UDPモードだけ動作します(ICMPモードはraw socketが必要) |
mtr |
ホップごとの損失率とレイテンシを継続して観察 | --udpが必要 |
tracerouteの原理は、TTLを1から上げながら送ることです。TTLが0になった地点のルーターがICMP time exceededを返し、その送信元アドレスがそのホップの正体です。そのため、tracerouteは「経路を照会する」ツールではなく、「わざと失敗させて応答を集める」ツールです。
* * *は障害ではありません。そのホップのルーターが、ICMP応答を制限しているか、作らないだけです。判定ルールは次のとおりです。
- 中間のホップだけで損失が見え、最終宛先で損失がなければ、ICMPのレート制限である可能性が高いです
- 特定のホップからレイテンシが急増するなら、その区間がボトルネックです
- 最後の数ホップで損失が増えるなら、実際の問題である可能性が高いです
pingが見逃すもの: パスMTU
最もたちが悪い事例が、MTUブラックホールです。pingは既定のペイロードが56バイトなので、常に通ります。ところが、応答が少し大きくなるAPIは、そのまま止まります。エラーでもなく、ただ止まります。サイズがしきい値を超えたパケットだけが消えるため、症状がサイズによって分かれます。
確認は、フラグメント禁止ビットを立てたpingで行います。
ping -M do -s 1472 -c 1 10.20.0.5
# From 10.0.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
-sの値に28(ICMP 8 + IP 20)を足したものが、実際のMTUです。二分探索で通過できる最大値を探すと、パスMTUが求まります。
トンネルを使うと、オーバーヘッドの分だけ実効MTUが減ります。
| カプセル化 | 追加ヘッダー | 実効MTU | 推奨MSSクランプ |
|---|---|---|---|
| PPPoE | 8 | 1492 | 1452 |
| GRE | 24 | 1476 | 1436 |
| VXLAN (IPv4) | 50 | 1450 | 1410 |
| WireGuard (IPv4) | 60 | 1440 | 1400 |
| IPsec ESP + NAT-T | 約81 | 1419 | 1379 |
現場での姿
「VPNをオンにすると、特定のサイトだけ開きません」。 トンネルのオーバーヘッドで実効MTUが減ったのに、MSSクランピングがない典型的な状況です。小さなページは開き、大きなページは止まります。pingは100%成功します。
クラウドでICMPをすべて塞いだまま、tracerouteを実行するケースです。すべてが* * *になり、「経路が切れている」と結論づけやすくなります。そのときは、TCPモードのtraceroute(-T -p 443)やnc -zvで宛先ポートを直接叩くほうが正確です。
どこで測るかが答えを変える
同じツールで同じ対象を測っても、どこで測ったかによって結論が変わります。これを意識しないと、別々の場所で測った値をめぐって議論することになります。
自分のノートパソコンで測った値は、私たちのサービスの値ではありません。オフィス回線、VPN、自宅のルーターがすべて経路に挟まっています。ユーザーが体験するものとも違い、サーバー同士の通信とも違います。そのため、問題が起きた場所と同じ位置で測ることが第一の原則で、それができないときは、測った位置を結果に併記します。
片側だけで測るのは半分です。前のコースで見たとおり、行きの道はあるのに帰りの道がないことがよくあり、そのとき片側から見たtracerouteは正常に見えます。両側から互いに向けて測ってみれば、非対称性がすぐに現れます。
経路は毎回同じではありません。複数の経路がある区間では、フローごとに別の道を通るため、tracerouteを2回実行するとホップが違って出ます。損失が特定のフローでだけ現れる問題は、1回の測定では捕まえられません。
測定そのものが負荷を生みます。すでに飽和したリンクにmtrを当てると、それが損失を上乗せします。そして前のコースで述べたとおり、すでに弱っているシステムで診断コマンドが障害を大きくすることは、実際に起きます。
最後に、いつ測ったかを書きます。ネットワークの問題は時間によって現れたり消えたりするので、時刻のない測定値は数日後には何の根拠にもなりません。正常なときの値をあらかじめ測っておくことも、同じ理由で価値が大きいです。比較するものがなければ、今の値が悪いのかどうか判定できません。
次のラボですること
インターフェースとルーティングを確認し、pingの統計から損失率とRTTを読み、UDPモードのtracerouteとmtrを実行します。最後に、ICMPは通るがTCPはどうかを自分で比較して表にします。