VPN接続のタイムアウト：DNS、トランスポート、ネゴシエーション、ログインのどれか
タイムアウトは期限が過ぎたというだけです。名前解決、トランスポート、ネゴシエーション、ログインの4段階を比べ、どれが最後に完了したかを見ます。
「接続がタイムアウトしました」は、VPN クライアントが表示できる最も曖昧なエラーです。一つの操作が期限を逃したという意味で、名前解決からログイン応答まで、どの段階にも期限があります。最後のメッセージだけを出すクライアントでは段階が同じに見えるため、人はタイムアウトを延ばし、ポートを変え、プロファイルを再インストールする、という順番で何も学ばずに試します。段階を比べるほうが速いのです。失敗する場所は段階ごとに違い、失敗が残す証拠の種類も異なります。
四つの段階、四つの異なる失敗
クライアントが隠していても順序は決まっています。名前を解決し、得られたアドレスへのトランスポートを確立し、プロトコルがパラメータと鍵をネゴシエートし、アカウントが認証される必要があります。OpenVPN の 接続に関するトラブルシューティングガイド も自社クライアントで同じ順序をたどり、他のクライアントもほぼ同様です。第二段階のタイムアウトと第四段階のタイムアウトには、画面の言葉以外に共通点はありません。
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
ログでは、エラーの直前の行ではなく、進展を示す最後の行を読みます。多くのクライアントは、解決済みのアドレス、確立したソケット、開始したハンドシェイク、認証要求などを出力し、その行の次の段階がタイムアウトした段階です。
名前解決は何かに接続する前に失敗する
エンドポイントが解決されなければ、クライアントには接続先がなく、トランスポートの処理も起きていません。この失敗は通常、完全なタイムアウトではなく即座に起きるので、他の失敗と区別する最も安価な手がかりになります。名前をシステムのリゾルバと別のリゾルバの両方で試し、サーバーが落ちていると結論する前に二つの答えを比べてください。
フォーラムの投稿からコピーした古いアドレスは、サーバーの問題に見えるタイムアウトのよくある原因です。そのアドレスは今、別のものか何もない場所に属しているからです。以前動いたアドレスに置き換えるのではなく、事業者の現在のプロファイルを使ってください。ping の応答がないことはどちらの証拠にもなりません。多くのエンドポイントは ICMP を捨てながら、問題なくサービスを提供しています。
トランスポートの設定は来ないパケットを待っている
DNS が正常なのにクライアントが期限をすべて使い切るなら、疑わしいのはトランスポート層です。TCP ではポートを直接試せます。Test-NetConnection Windows では nc -vz Linux では、何かが接続を受け付けるかを教えてくれ、ping より役に立ちます。UDP では同じようには試せません。その層には完了すべきハンドシェイクがないからで、この非対称性が多くの誤った結論を生みます。
TCP のテストが証明できることは限られています。443 番ポートを受け付けるサービスが VPN のリスナーとは限らず、UDP のみのエンドポイントには何かを受け付ける TCP ポートがありません。プロファイルを UDP から TCP に書き換えても、相手側にリスナーはできません。変わるのはクライアントが待つ対象だけです。ネットワークがプロトコルを遮断している場合、変更は同じ段階で別のタイムアウトを生むだけです。
キャプティブポータルはこの段階で独自の確認に値します。ポータルが端末を許可するまで、外向きの通信はポータルへ行き、トンネルの試行はただ止まったままになります。まずブラウザでポータルを完了してから再試行し、ポータルが保留のままプロファイルを変えないでください。
ネゴシエーションとログインは、サーバーが応答したという意味
トンネルがサーバーに届くと、クライアントはハンドシェイクを始め、エラーの性格が変わります。ここでの停止は到達性ではなく互換性の問題です。プロトコルのバージョン不一致、相手が受け入れない暗号やデータチャネルの設定、サーバーが提供しない機能を期待するプロファイルなどです。OpenVPN はメジャーバージョン間でネゴシエーションの既定値を何度も動かしてきたため、ある世代向けに書かれたプロファイルがサーバーに届いても起動できないことがあります。
認証は最後の段階で、最も読み違えやすいところです。明示的な拒否は応答です。つまり経路は機能しており、問題は本人確認、証明書、またはアカウントの状態にあります。ブラウザベースのシングルサインオンは第三の場合です。クライアントは、まだ行っていない操作か、起動できないブラウザを待っており、その手順を終えるまで何も届きません。
再試行を変える前に証拠を比べる
端末とプロファイルを固定し、ネットワークから始めて一度に一つだけ変えます。同じプロファイルがスマートフォンのテザリングでつながり、ホテルの Wi-Fi でタイムアウトするなら、変数はサーバーではなく経路です。どこでも失敗するなら、変数はプロファイルかエンドポイントです。特定の時間帯だけ失敗するなら、タイムスタンプを記録し、負荷について何か仮定する前にサーバー側のイベントと比べてください。
自分が管理するサービスの場合、決定的な比較は試行がそもそも届くかどうかです。リスナーに届いてから止まる接続はネゴシエーション段階に属します。リスナーの視界に一度も現れないものはトランスポートか解決の問題で、再試行の調整では動きません。サーバーログは拒否されたログインと静かな切断も分けるので、本人確認の修正とファイアウォールの修正の違いが分かります。
クライアントのバージョン、プロファイル名、タイムゾーン付きの試行時刻、そして最後の切断行ではなく最初の有用なエラーを記録します。抜粋を共有する前に鍵と認証情報を含む資料を除いてください。その後で意味のある修正を一つ行って再試行します。期限を延ばしても、文書化された遅い処理にしか効かず、間違ったアドレスや遮断されたポートには何の役にも立ちません。