VPNは接続済みなのに一つのサービスだけ失敗する:段階を切り分ける
完了したハンドシェイクは、名前・経路・パケットサイズ・待ち受けについて何も語らない。四つの段階を順にたどり、最初に失敗した段階に障害を名指しさせよう。
VPNチケットにおいて「接続済み」は最も情報量の少ない事実だ。二つのピアがハンドシェイクを終えたことだけを記録し、問い合わせた名前、パケットが出て行ったインターフェース、そのサイズ、遠端が受け取ったかどうかについては何も語らない。だから同じノートPC上の他のアプリがすべて動いていても、一つのサービスだけが失敗しうる。段階を順にたどれば、最初に失敗した段階が障害を名指しする。
名前から始める、トンネルからではない
経路を決める前に名前を解決する。悪い答えは以降のテストをすべて無意味にするからだ。システムのリゾルバで名前を問い合わせ、その答えをアプリが実際に使ったアドレスと比べる。プライベートな名前がパブリックアドレスとして返るなら、その問い合わせは答える筋合いのないリゾルバへ行っている。解決に失敗する名前も同じ分類で、ただ声が大きいだけだ。
resolvectl query host.internal
getent hosts host.internal
独自のセキュアDNS設定を持つブラウザはここで失敗し、システムの他の部分は動く。だからブラウザだけの不具合は、誰かが経路に触る前に、まずこの段階に属する。片方ではなく両方のコマンドを比べよう。getent は NSS の経路をたどり、リゾルバへの問い合わせはたどらない。
カーネルにどの経路を選んだか尋ねる
ルーティングテーブルは優先順位であり、カーネルが選ぶ経路は図に描かれたものとは限らない。問題の宛先について直接尋ねよう。返答はインターフェース、次のホップ、使用される送信元アドレスを示す。パケットは遠端が拒否する送信元アドレスを載せてトンネルを出ることもあり、物理テーブルのより具体的なエントリが Wi-Fi インターフェースから送り出すこともある。
ip route get 10.20.30.40
ip -brief address show
dev、via、src のフィールドをこの順に読む。それぞれが別の疑いを消すからだ。この段階は、異常終了の後もファイアウォール規則や経路が残りうるためクライアントが導入した状態も担い、だから「トンネルなしではインターネットなし」と「クライアントが動かなければインターネットなし」は二つではなく一つの障害ファミリーだ。
パケットサイズを試す
大きな転送が止まる一方で小さな応答が返るなら、まず経路の MTU を疑う。トンネルの内側から送る、do-not-fragment ビットを立てた一回のプローブが、この段階を他から切り分ける。プローブが失敗するまでペイロードを上げれば、意味のある数値が手に入る。
ping -M do -s 1400 10.20.30.40
ディレクトリ一覧やアップロードが固まる一方で小さなプローブが通るのが、この段階の署名だ。申告は認証情報やファイアウォール規則のように聞こえるが、どちらでもない。
その数値はクライアントではなく経路の性質なので、オフィス回線で通る値がモバイル回線では失敗しうる。プローブのコマンドはチケットと一緒に残そう。次の担当者も同じ測定を必要とする。より小さなペイロードが通るなら、対処は clamp かより低いトンネル MTU であり、新しい暗号ではない。
遠端を試す
宛先をそのアドレスで試し、次にそこで何が待ち受けているかを見る。接続拒否と、決して応答しない接続は別の所見だ。前者は何かが動いていてそのポートを提供していないと言い、後者は何も返ってこなかったと言う。どちらも既定ではクライアントの問題ではない。
curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'
トンネル経由で届くものが 127.0.0.1 だけで待ち受けるサービスのはずはない。待ち受け側はパケットを決して見ないからだ。遠端ホストのファイアウォールがオフィスのサブネットを許可しトンネルのプールを拒否すると、結果はクライアントの不具合に見えるがそうではなく、ウェブ通信は生きているのにリモートデスクトップやファイル共有が壊れるのは、たいていここに落ち、ユーザーがどう言い表しても同じだ。
申告を一つの段階に対応づける
ほとんどの報告は五つの形のどれかに収まり、それぞれの形が一つの段階を名指しする。トンネル経由でしか動かない一つのサイトは、名前の答えか送信元アドレスに結びついたポリシーだ。トンネルなしで更新が失敗し閲覧は動くなら、そのクライアントの名前か経路の問題だ。
プロバイダのクライアントが起動するとすべて止まるのは、導入済みの状態、つまり経路とファイアウォールの問題だ。他が正常なのに一つのサービスに届かないのは遠端だ。転送が数秒で固まるのはパケットサイズだ。コマンドを走らせる前に形を照合しよう。どの証拠を先に集めるかが決まる。
最初の失敗を生んだ段階を、コマンドの出力とともに記録する。送信元アドレスが誤っていたと述べ、経路の行を添えたチケットは対応する価値があるが、VPN が壊れていると報告するチケットにはない。