六十秒のTLSタイムアウト：実際に止まったのはどちら側か

クライアントは六十秒後に鍵交渉に関するメッセージを出して諦め、ノートPCはその理由について何も語りません。この文が表しているのはクライアントの忍耐であって、サーバーの挙動ではありません。これにはまったく異なる三つの状況があります。パケットが正しいサービスに届かなかった場合、サービスが何も記録する前に破棄した場合、サービスが拒否してクライアントから見えない場所でそれを告げた場合です。両端で一つの試行を突き合わせることだけが、それらを切り分けます。

一つの試行に検索できる識別子を与える

開始時刻とタイムゾーン、プロファイル名、クライアントが実際に解決した宛先、ポート、接続がUDPかTCPかを書き留めます。プロファイルに複数のリモート項目がある場合は、その試行がどれを選んだかを記録してください。再試行が、読んでいるファイルを変えないまま次の項目へ移っている可能性があるからです。

エンドポイントは、覚えているダウンロードからではなく、稼働中のログから取ります。プライベートアドレスを指すプロファイルは完全に有効であり、そこへルーティングできないネットワークからは完全に使えません。その状況は、停止したサーバーとまったく同じに見えます。

次に、意図したインスタンスで同じ時間帯のログを運用者に求めます。時計のずれはよくあることで、数分の差があると一致するイベントが存在しないように見えます。ですから「イベントはなかった」と結論するのではなく、ずれを記録してください。

四つの観察、四つの異なる次の一手

サーバーが何を記録するかで分岐が決まります。試行がまったくない場合は、アドレス指定、トランスポート、またはサービスへの経路を示します。通常の交換の前に消える受信パケットは、実際のサービスの制御チャネルの要件を示します。名前付きの拒否は、それが名指すオブジェクトを示します。サーバーを離れてもクライアントに届かない応答は、戻り経路を示します。

空のアプリケーションログは、見た目より弱い証拠です。ログ記録は交換の一定の地点から始まり、その地点より前に破棄されたパケットは、読んでいるファイルに痕跡を残しません。許可されている場所では、運用者がサービスとネットワークの観察を使って、何かが届いたかどうかを見られます。

メモでは四つの結果を別々に保ってください。誘惑はそれらを「サーバーが応答しない」にまとめることですが、本当の問題がファイアウォール規則のときに人を暗号方式の変更へ向かわせるのはこの言葉です。タイムアウトという語だけを記録したメモは、たった今代価を払って得た区別を捨てています。

証拠が名指す段階を直す

TCP接続が完了したことは、何かがソケットを受け入れたことしか証明しません。待ち受けているのが設定したOpenVPNサービスであることは証明せず、同じホスト名のウェブサーバーはブラウザーには完璧に応答しながら、トンネルには無関係です。

サーバーが失効リストの期限切れを報告するなら、それはクライアントの最終的なタイムアウトよりはるかに具体的な事実であり、修正はネットワークではなく認証局に属します。両端が制御チャネルの保護や共有材料について一致しない場合、パスワードを再設定しても何も変わりません。破棄はどの資格情報も検査される前に起きるからです。

証拠が実際に裏づける一つのことを変え、同じプロファイルを同じエンドポイントに対して繰り返します。接続が先へ進んだなら最初の新しいイベントを保存してください。そのイベントは新しい問題ではなく、調査の次の段階だからです。

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

ウィンドウを延ばすと実際に何が変わるか

六十秒はクライアントのハンドシェイクのウィンドウであり、コミュニティのクライアントリファレンスがそれを調整するオプションを文書化しています。延ばせばクライアントは諦めるまで長く待ちます。存在しないサービスが現れるわけでも、拒否されたパケットが受け入れ可能になるわけでもありません。

遅い回線や負荷の高いサーバーでは、長いウィンドウに正当な用途があり、交換が起きていないのではなく遅く進んでいるという証拠が得られてから試す価値があります。最初に試すと、同じ診断をさらに一分遅らせ、タイムラインを読みにくくするだけです。タイムラインが進んでから止まる交換を示すなら、ウィンドウは到達性ではなく負荷の症状です。