VPN が移転した：OpenVPN クライアントが今も古い IP に接続する理由

プロバイダーが公開アドレスを変更し、動的 DNS レコードを更新しても、クライアントは接続できません。外から見るとレコードが伝播していないように見えます。ほとんどの場合レコードは正常で、クライアントは移転前に解決したアドレスへ接続しています。稼働中のトンネルと保存済みのプロファイルは、それぞれサーバーの居場所について独自の考えを持っているからです。三つの層が一致する必要があり、それぞれ更新のタイミングが異なります。

DNS が言うことではなく、プロファイルが接続する先を見る

実際に使っている接続を開き、remote 行を読んでください。そこにある数値アドレスは、レコードがどれほど正しくなっても、ホスト名の更新に追従しません。

次に、編集したプロファイルがクライアントの読み込んだものと同じかを確認します。インポートされたプロファイルはよくあります。管理者が数か月前にコピーを取り、独自の版を保持していると、ダウンロードフォルダーのファイルとアプリ内の項目が食い違うことがあります。DNS をデバッグする前に、クライアント自身の接続情報にあるエンドポイントを比較してください。

ファイルは二つ、エンドポイントは一つ — ここではそれがよくある発見です。

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

クライアントの次の接続試行を読む

詳細ログを有効にして接続を再起動し、接続先のアドレスが示された行を読みます。重要なのはその値であり、ブラウザーが解決した値ではありません。

リゾルバーのキャッシュには前の応答が残っていることがあり、レコードの TTL が求めるより長く保持するネットワークもあります。他所から試した公開リゾルバーではなく、クライアントが実際に使うリゾルバーに問い合わせてください。

ログに新しいアドレスが表示されても接続が失敗するなら、問題は移っています。パケットはどこかへ向かい、誰も応答していません。これはリスナー、ファイアウォール、ポート転送の問題で、クライアントの解決経路ではなくサーバー側にあり、この二つの失敗は分けておいてください。到達できないリスナーを DNS 問題として扱うと、同じループを二度回ることになります。

どの再起動をしているのかを知る

すべての再起動が同じ状態を保つわけではないため、アドレス変更の挙動はプロセスの再生成方法によって変わります。シグナルによるソフト再起動は前のセッションの文脈を多く保ち、完全な停止と起動は構成からやり直します。クライアントが再解決するかを試すなら、構成から始まる経路を選んでください。

永続化の設定も、認証済みのものを保つためのものであって新しいアドレスを追うためのものではないので、重要です。

最もきれいなテストは、意図したプロファイルからの新規起動と、エンドポイントを示すログ行の確認です。部分的に保持されたセッションから学べることは、そのセッションについての記述にすぎません。

四つのオプションとそれぞれの役割

ホスト名付きの remote は再解決を可能にする設定です。その行にリテラルアドレスがあれば不可能になります。resolv-retry は検索が失敗したときの動作を制御し、2.6 では既定で無限になっています。したがって追加しても何も変わらず、別の応答を定期的に確認することもありません。新しいアドレスをポーリングすると言う人は、回復と鮮度を混同しています。

persist-remote-ip は鮮度ではなく継続性の話です。最後に認証したエンドポイントを、対応するソフト再起動をまたいで再利用します。移転を試している間は、望むものの逆です。ビルドで有効ならテスト中は無効にし、新しいエンドポイントが証明できたら戻してください。有効のままにすると、再接続の成功は DNS について何も教えてくれないかもしれません。

float は、セッション途中でアドレスが変わった認証済みピアを受け入れます。対応する構成に限られます。DNS を更新せず、プロバイダーの変更を自力で追うこともありません。ローミングするピア向けの耐障害機能として扱い、サーバー向けの動的アドレス機構とは考えないでください。

クライアントを責める前に新しいエンドポイントを確認する

ネットワークの外から、新しいアドレスが設定済みポートで待ち受けていること、プロバイダーの転送がそこを指していることを確認します。開放ポートのないマシンに対する正しい A レコードは、人がキャッシュのせいにする症状をそのまま生み出します。

そのうえで再接続し、クライアントが想定のサーバー証明書で認証されたことと、セッションが意図したリソースに到達することを確認します。アドレス変更は身元要件を下げません。誤ったエンドポイントへ成功する接続は、失敗する接続より悪いのです。OpenVPN 2.6 のマニュアル は四つのオプションをそれぞれの範囲とともに列挙しており、プロファイルのそばに置くチェックリストになります。

管理アクセスを運ぶトンネルを再起動する前に、サーバーへの帯域外の経路を確保してください。その一つの用心だけで、このシナリオが生むほとんどの事故を防げます。