Pingは証拠ではない：二つの拠点間の経路をテストする

ゲートウェイからのpingはサービスについて何も語らない。実際のクライアントから経路をたどり、アプリのプロトコルを使い、失敗するサイズや名前を再現する。

トンネルは上がっており、ゲートウェイ同士は応答しているのに、一方の拠点のユーザーはもう一方のファイル共有を開けない。誰かがゲートウェイからpingを打ち、応答を得てネットワークは健全だと宣言する。その応答は、問題ではなかった二台の機器の間を往復しただけだ。役に立つテストは、サービスを必要とするホストから始め、アプリが使うプロトコルを使い、失敗する条件を再現する。それ以外はすべて、誰も通らない経路に対する青信号だ。

サービスを必要とするクライアントから始める

テストの前に四つ書き留める：クライアントのアドレス、宛先アドレス、ホスト名、アプリのポートだ。次に、サービスのある拠点で、隣のホストからローカルに動くことを確認する。この基準線がなければ、壊れたトンネルと壊れたサービスを区別できず、この種のチケットの半分は後者だ。

文書化されたホスト名を試し、サービスが許すなら同じポートへの直接アドレス確認も行う。名前解決の失敗と、解決されたアドレスへの到達不能は、別々の道筋へ導く。ホスト名の代わりにIPを入れても、動かすためにHTTPSの本人確認を切ってはいけない——証明書の警告は情報であり、障害ではない。

各エッジで経路をたどる

クライアントが選ぶルート、次にゲートウェイがその宛先に選ぶルート、次に各エッジのカウンターか範囲を絞ったキャプチャを読む。探す事実は二つ、要求が遠隔のLANに届いたか、応答が戻ったかだ。インターフェースのカウンターは他のフローも含むので、グラフの形ではなく正確な時刻とアドレスの組で相関させる。間違ったエッジで取ったキャプチャは、証拠に見えるぶん、無いより悪い。

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

要求が遠隔のエッジに現れ、その背後に応答がないなら、問題は向こう側にある。ファイアウォール、戻りルートの欠落、送信元を受け付けないホストのいずれかだ——要求がまったく現れないなら、ローカルルートかトンネルのセレクターが運んでおらず、向こう側を調べる価値はまだない。

アプリが使うプロトコルを使う

ICMPは弱い検査だ。フィルタされたり、レート制限されたり、サービスとは別のポリシーで扱われたりするため、成功も失敗も曖昧になる。実際のポートを、できれば実際のプロトコルのハンドシェイクまで試す。

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

TCPハンドシェイクの完了は、そのポートへの到達性とポリシーを証明する。アプリが動くことは証明しない——認証、アップロード、特定のAPI呼び出しはまだ失敗しうる。ユーザーが実際に行う操作を、本物のトランザクションを繰り返し送るのではなく、無害な同等物で試す。

失敗する条件を再現する

大きな転送でだけ現れる失敗はサイズの問題であり、接続性の問題ではない。don't-fragmentビットを立てた大きなパケットを送り、どこで止まるかを見る。小さな要求が成功して大きな要求が止まるなら、トンネルのMTUとゲートウェイのMSS処理が次の容疑者だ。

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

片方のサブネットだけが失敗するなら、トラフィックセレクター、ルート広告、そのサブネットの戻りゲートウェイを見る。ホスト名だけが失敗するならDNSを追い、クライアントが使ったリゾルバーと、その拠点から遠隔のビューが見えるかを含める。三つの異なる障害、三つの異なる修正、そしてpingテストはどれも区別しない。

修正後、同じテストを繰り返す

同じクライアント、宛先、ポート、ペイロードでもう一度実行する。次に、設計に冗長経路があるなら再接続するかその経路を試す——元のトンネルインスタンスが生きている間しか動かない修正はテストされていないからだ。テストは、ダッシュボードの緑の表示一つではなく、実際の送信元、実際の宛先、実際の操作に結び付けておく。

四つの基準値と結果を記録する。同じ症状の次の報告は、pingではなく証拠から始められる。

関連記事