VPN 接続サーバーの DNS にはどのアドレスを入れる？
ホスト型サーバーは三つのアドレスを持ち、互いに置き換えはきかない。各サービスに必要な値を選び、そのうえで機械の外から確認する。
VPN を入れたホスト型サーバーは最終的に三つのアドレスを持つが、これから設定する場所ごとに当てはまるのはそのうち一つだけだ。プロバイダーのパネルの数字を DNS に、リスナーに、あるいは許可リストにコピーする——それが、動いていたトンネルを誰も届かないサービスに変える手順である。本稿は、各アドレスが明示した用途のために選ばれるよう作業を並べる。実際に何を公開したかを確かめるコマンドも挙げる。
何かを公開する前に三つのアドレスを整理する
機能で名前を付ける。underlay アドレスは、機械がインターネット越しに VPN の終端へ届くために使うもので、多くの場合プロバイダーの NAT の後ろにある私有アドレスだ。トンネルアドレスは VPN の内側にあり、製品によってサーバーかクライアントが配る。公開出口はリモートのサイトが変換のあとに記録するアドレスであり、こちらが問い合わせられるどのインターフェースにも存在する必要はない。
一つの公衆アドレスだけを示すパネルは、残り二つの役割についてほとんど何も語らない。underlay への到達性は要件であって購入物ではない：家庭のルーターの後ろにあるノート PC でも、公衆 IPv4 アドレスを持たずにホスト型 VPN の終端へ届ける。できないのは、誰も転送しないアドレスに解決する名前を書いて、内向きの経路をでっち上げることだ。
ラベルではなくサービスでアドレスを選ぶ
数字を選ぶ前に、サーバーが何をするべきかを書き出す。外向き API 呼び出しは、相手が許可リストを持つ場合に安定した出口を要する。私有アクセスには、クライアントが経路を向けられるトンネルアドレスと、そこに束ねたリスナーが要る。公開ホスティングには、プロバイダーが実際に提供する内向きの対応付けが要り、出口アドレスだけでは足りない。
一台で三つの用途を兼ねながら、三つの異なるアドレスを使うこともできる。崩れるのは、一つの値ですべてを賄えるという前提だ：
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
議論になるのは内向きの行だ。出口アドレスを指すレコードは、リスナーも、ファイアウォールの穴も、ポート対応付けも作らないし、待っても変わらない。プロバイダーが専用アドレスを内向き規則と一緒に売るなら、その束が買った能力であり、アドレス単体は権利ではない。
どのアドレスがどれかを見るコマンド
パネルではなく機械を読む。インターフェース名はシステムごとに違うので、ラベルを信じるのではなくアドレスを機器に対応させる。
一行目はすべての IPv4 アドレスとその機器を並べ、二行目は既知の外部宛先に対してカーネルがどの機器を使うかを尋ねる：
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'公衆向けトラフィックの経路照会がトンネル機器で答えるなら、フルトンネルが効いている。リスナーの確認も同じくらい重要で、127.0.0.1 にしか束ねていないプロセスは、どんな名前を公開してもトンネルアドレスで応答しない。
公開してから、外から検証する
サービスが必要とする値だけを公開する：ホスティングなら A か AAAA レコード、外向き呼び出しなら許可リストの項目、私有アクセスならクライアントプロファイルだ。そのうえで重要な位置から試すが、それは決して、いま編集した機械ではない。
二つの確認で大半を押さえられ、どちらもスクリプトに残せるほど安い：
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthレコードの存在を証明する DNS 応答は、要求が届く証明にはならず、成功した要求一つが示すのは一つの経路が一つのネットワークから通ることだけだ。許可リストが絡むなら、モバイル回線から確認を繰り返す：観測した出口はアドレスファミリーと通った経路に依存しうるからだ。どちらのファミリーを検証したかを記し、動く IPv4 経路は IPv6 について何も語らない。
サービスが内向きなら、出口アドレスでは足りない
内向きのアクセスには四つが揃っている必要がある：クライアントが届く名前かアドレス、パケットを機械まで運ぶ経路、それを受け入れるリスナー、そして落とさない方針だ。VPN が変えるのは二つ目で、ときには一つ目も変えるが、三つ目と四つ目には何もしない。トンネルが配送路なら、クライアントは出口ではなくトンネルアドレスに接続する。
各サービスがどのアドレスに依存するかを記録し、プロバイダーが経路モデルを変えるたびにその記録を見直す。私的に応答して公に失敗するサーバーは、たいてい壊れていない：誤った識別で応答しているのであり、直すのは対応付けの判断であってファイアウォールの変更ではない。