Azure OpenVPN のトンネルがおよそ六十秒ごとに切れる理由

トンネルはハンドシェイクを終え、約一分間トラフィックを運んでから再接続します。この順序は、ポートを遮断するファイアウォールならセッションではなくハンドシェイクの時点で止めるはずなので、よくある容疑者を除外します。起きているのは生きているかどうかの見解の相違で、片側が相手を沈黙したと判断し、動作中のトンネルを切ったのです。ログの行がどちらの側かを示し、その行が対処法を決めます。

タイマーに触れる前に、その行を読んでください。

俗説：経路上の何かがトンネルを遮断している

ポートが遮断されていれば、接続は最初に失敗し、失敗したままになります。繰り返す周期は、制御メッセージが流れ、セッションが確立し、会話の後半で何かが期限切れになり続けていることを意味します。遮断は沈黙を生み、これはリズムを生みます。

リズムこそ有用な手がかりです。タイマーがそれを生み、パケット損失はほとんど生みません。

タイマーより先に切断理由を読む

OpenVPN は理由に名前を付け、それぞれの名前は別のサブシステムを指します。Session invalidated: KEEPALIVE_TIMEOUT はタイマーの満了なので、両端の ping と ping-restart の値を比較してください。AUTH_FAILED は資格情報か証明書の状態で、タイマーを変えても役に立ちません。TLS エラーは、両者が keepalive の段階にすら達していないことを意味します。

接続時刻、切断時刻、間隔が秒単位で安定しているかを記録してください。その一つの測定が、設定されたスケジュールと偶然を分けます。

安定した間隔はタイマーです。ずれていく間隔は、経路の問題か移動したセッションである可能性が高いです。

決して一致しなかった二つの keepalive タイマー

ポータルからエクスポートしたプロファイルには、コミュニティサーバーのテンプレートからコピーした keepalive や ping-restart の行が残っていることがあります。ゲートウェイは独自の死んだピアの検出を実行し、独自の期待を押し付けますが、二つのスケジュールが一致する必要はありません。食い違うと、クライアントはゲートウェイが同意していないスケジュールで再起動します。

二つの値は同じ制御ではありません。ping はクライアントがエコーを送る頻度で、ping-restart はトンネルを切る前に何も聞こえないまま待つ時間です。短い ping-restart を設定したプロファイルと応答の遅いゲートウェイは、静かな期間ごとに再起動し、それはまさに一分周期の形です。

クライアント側の最小の変更は、プロファイルの最上位で、インラインブロックの外にあるタイマーを無効にすることです：

keepalive 0 0

保存し、プロファイルを再読み込みし、再接続します。すでにメモリにあるセッションは古い値を保つので、編集が何もしていないように見えることがあります。

証明書の名前は足元で動くことがある

Azure の証明書認証は、クライアントが今日ゲートウェイが提示する名前を信頼しているかどうかに依存します。古いダウンロードの verify-x509-name 行は、ゲートウェイの再構築や証明書の更新によってその後変わった名前を固定してしまい、不一致は明確なエラーではなく再接続のループとして現れます。行を削除すると接続は戻りますが、検証も失うため、優れた診断でありながら恒久的な修正としては不適切です。トンネルが保持されたら、ゲートウェイが実際に提示する名前で行を戻してください。

ゲートウェイを編集する前に、同じマシンで第二世代のクライアントを試してください。一方がループし、もう一方が保持するなら、プロファイルが問題ではありません。

何を、どの順序で変えるか

次に、移動したセッションを確認してください。一つの証明書を共有する二台の端末は互いを押し出せ、両側が再接続を続けるため結果は周期的に見えます。同じ識別情報が何度も現れるポイント対サイトのセッション記録を比較してください。

次に、数分間継続的なトラフィックを流してアイドル経路を試してください。トラフィックが流れている間に切断が止まるなら、重要なタイマーは経路上の NAT 機器かロードバランサーのもので、OpenVPN のものではありません。

ゲートウェイの設定は、これら四つのテストの後にだけ変えるべきです。