Pritunl サーバーの名前を変えるとエンドポイントも変わると思っていませんか？

Pritunl サーバーの名前を変えると、コンソール上のラベルが変わります。クライアントプロファイルが接続するアドレスは変わらず、DNS レコードが作られるわけでもありません。重要なのはホストのパブリックアドレスであり、これはアドレスと同様に名前も受け付けます。

クライアントが接続する名前はひとつのホストフィールドに宿る

Pritunl はホストの パブリックアドレス 設定でエンドポイントを公開し、ここにはパブリック IP アドレスか DNS 名を指定できます。そこに vpn.example.net を置くと、生成されるプロファイルと認証済み同期がその名前をクライアントに渡します。レコードはあらかじめ存在し、VPN トランスポートを受け付けるリスナーへ解決している必要があり、このフィールドは宛先を告知するもので、公開するものではありません。サーバーオブジェクトの表示名は管理用メタデータであり、クライアントの接続試行には決して届きません。

つまり最初の一手は、何かの名前を変えることではありません。ホスト設定を開き、パブリックアドレスを変更し、サポートされているインターフェースから保存します。

似ているようで似ていない三つのフィールド

ローカルアドレス は Pritunl ホスト間のレプリケーションとルーティングに使います。リンクアドレス はリンクされたサーバー同士がどう到達するかを表します。どちらもクライアントが接続するアドレスではなく、パブリック名をこれらにコピーすると、それぞれが表すトポロジーが壊れます。パブリック IPv6 アドレス は独自のレコードと経路を持つ別フィールドであり、IPv4 の A レコードは IPv6 の到達性を確立しません。

DNS 名もポートマッピングやリスナーを運びません。サービスが 1194 UDP で待ち受けるなら、名前は依然として 1194 UDP を受け付けるホストへ解決されます。Web コンソールを提供するポート 443 の HTTP リバースプロキシは、両者が同じ名前を共有していても VPN トランスポートのエンドポイントではありません。

トンネル内のドメインベースルーティングはまた別の層です。外側のエンドポイントに名前を付けても、クライアントが到達できるプライベートな宛先については何も語りません。

新しい名前を既存のクライアントに配信する

フィールドを変えても、すでにサーバーを離れたプロファイルは書き換わりません。Pritunl の認証済み構成同期は、ホストのアドレスとポートの変更を互換クライアントに配信でき、文書化された CLI クライアントは接続または再接続の前に同期します。NetworkManager や単体の OpenVPN クライアントにインポートされたプロファイルにはそのような経路がなく、承認済みの差し替えが必要です。既存のセッションは、古い値に対して確立されたものなので何も証明しません。

Web コンソールがロードバランサーの背後にある場合、Pritunl は同期経路用に別の 同期アドレス 設定を文書化しています。どちらも Pritunl だからといって、VPN リスナーにコンソールのホスト名を再利用しないでください。

変更は、ホスト設定の保存、現在のプロファイルのエクスポートまたは同期、クライアントのコピーの差し替え、それからの再接続という順序で届けます。どのクライアントが同期で管理され、どれがインポート済みファイルを持つかを記録してください、後者は自動では追随しないためです。ここではクライアントの所有一覧のほうが、もうひとつの DNS レコードより役立ちます。

実際の接続で変更を検収する

名前解決は最も弱い検証です。dig +short vpn.example.net がアドレスを返すことは、レコードが存在することしか証明しません。

検収テストは、新しいプロファイルを持つクライアントからの新規の認証済み接続と、それに続くトンネル経由で到達できるべきプライベートリソースへの要求です。クライアントログで、実際に使われたエンドポイントを確認してください、意図したものではなく。名前の変更が正しいことに依存しない管理経路を確保し、誤りでコンソールから締め出されないようにしてください。

後でパブリックアドレスが移ったら、レコードを更新し、クライアントのキャッシュと再接続の挙動を見込んで計画します。ホスト名はクライアントを数値アドレスから切り離しますが、稼働中のソケットを移すわけでも、到達不能なリスナーを応答させるわけでもありません。