公開VPNリストはオンラインと言うが、クライアントは違う

ディレクトリを開き、速度で並べ替え、オンラインと表示されたノードを選ぶと、クライアントは接続を終える前に諦めてしまう。リストは厳密には嘘をついていない。別のネットワークから、より早い時点で、第三者が行った検査の結果を、ボランティアがいつでも止められるサービスに対して伝えていただけだ。このずれを理解すれば、いらだたしい探索は、どの候補にも実行できる短い検査の列に変わる。

リストが実際に測ったもの

公開ディレクトリは、最後に検査した時刻、観測された往復時間の値、セッション数、時にはプロトコルの一覧といった項目を保持する。どれもプロジェクト自身の視点から見た最後の成功観測を表しており、あなたのパケットが届いた時点のノードの状態ではない。

数字よりも鮮度が重要だ。四分会前に検査されたノードと四時間前に検査されたノードが同じ緑の印を示すことはあり、記録された状態にまだ似ているのは片方だけだ。色ではなくタイムスタンプを見よう。

ボランティアによる運用は、どんな監視でも直せない第二の変化要因を加える。運営者がノートパソコンを再起動しているかもしれず、帯域が尽きているかもしれず、回線を変えたかもしれず、あるいは単にふたを閉じただけかもしれない。リストの項目は候補であり、それをサービス水準合意として扱うのはカテゴリー錯誤だ。

スピナーではなくクライアントの段階を見る

どのVPNクライアントも同じ大きな流れを通る——名前を解決し、トランスポート接続を開き、セキュリティを交渉し、認証し、それからトンネルを設定してデータを流す。各段階の失敗はそれぞれ異なる証拠を残すが、スピナーはそのどれも示さない。

まず名前解決から始める。ホスト名が解決できなければ、 ノードの可用性については何も検査されていない——接続があなたのマシンから出発していないからだ。次にトランスポート：TCPやUDPの交換が拒否されたり時間切れになったりすれば、そのポートで端点が応答していないという、ノードについての実際の所見になる。続いて交渉と認証では、証明書の誤り、期限切れのプロファイル、不一致の暗号方式が失敗する一方で、ノード自体は完全に健全であることがある。トンネルを設定した後になって初めて、ルーティングやDNSの不具合が最後の段階を説明できる。

画面にまだ収まる最も詳細な設定でクライアントのログを読み、最後に成功した行を書き留める。その行が診断の出発点であり、通常はディレクトリが表示する何よりも情報量が多い。

試行ごとに一つの変数

同じクライアント、同じアクセス網、同じプロファイル形式で候補を比較し、変えるのは端点だけにする。そうしなければ、失敗は自分の側にあるのにノードのせいにしてしまう。

二回の試行で傾向はつかめ、三回目で確認できる。ノードAがトランスポート段階で失敗し、ノードBが認証で失敗するなら、古いリスト一つではなく無関係な二つの問題を抱えている。

どのノードも同じように失敗するとき

最初の段階で普遍的に失敗するなら、原因は自分の側にある——応答できないリゾルバ、プロトコルを遮断するローカルファイアウォール、ウェブの通信だけを許す網のいずれかだ。ディレクトリはそれを報告できない、検査があなたの席から走るわけではないからだ。

整形された網の場合は意識して試そう。アクセス網によってはウェブへのHTTPSだけを許し、他のプロトコルを落とすため、リストが正確でもどの候補も死んで見える。ブラウザでのページ読み込みと生の接続試行を比べれば、その二つの状況を一分足らずで切り分けられる。

失敗した段階でその失敗を読む

段階が見えるように、端末から試行を再現する。以下の三つのコマンドは、名前を解決し、ポートが応答するかを試し、OpenVPNプロファイルの交渉行を出力する：

dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"

ポートが応答し、交渉行が証明書の問題を報告するなら、ノードは稼働していてプロファイルが古い。ポートがまったく応答しないなら、その項目は失敗した候補であり、クライアントをデバッグするよりも次へ移るのが正しい対応だ。段階を短い一行に記し、次の試行は希望ではなく知識から始まる。