自宅のVPNサーバーに動的DNSは必要か

私に相談される自宅VPNの不調の多くはDNSの不調ではない。それでも人はまず動的DNSの契約を買う。何かを設定する前に、ホスト名が本当に壊れている部分なのかを決めよう。更新ツールはISPが渡したアドレスが変わったときにレコードを書き換えるだけで、ポートを開けず、キャリアNATを抜けず、稼働中のWireGuardセッションに端点が変わったことを気づかせることもできない。動的DNSが解決策の全部なのか、その一行だけなのかは三つの条件で決まる。

条件一：アドレスが実際に変わる

住宅向けアドレスはありふれた理由で変わる。停電後にモデムが再同期し、ISPがプールを再配分し、長時間の障害のあとに新しいリースが来る。回線によってはほとんど変わらず、私は同じアドレスが一年続くのを見たことがある。法人向けプランには固定アドレスが付くことも多い。十二か月何も変わっていないなら、手で編集するAレコード一つのほうが、生かしておくデーモンが一つ減る。

推測せず測る。ルーターの状態画面でWANアドレスを読み、外の世界から見える値と比べる。LAN上のマシンで次を実行する。

curl -fsS https://api.ipify.org; echo

二つの値が違うなら、ルーターの手前で何かが変換しており、ホスト名の更新では直らない。100.64.0.0/10の中のアドレスはキャリアグレードNAT用の共有範囲で、正しく更新した名前が外からタイムアウトする通常の理由はこれだ。

条件二：クライアントが名前を引き直す

短いTTLは人が飛ばす部分だ。再帰リゾルバはレコードのTTLを守るが、クライアント側のスタックは別にキャッシュし、すでに立っているトンネルは何も引き直さない。デバッグ中はレコードを60-300秒にしておく。古い応答が配られる時間が縮み、接続中のセッションが移行するわけではない。

OpenVPN は再接続のたびに remote vpn.example.net 1194 の行を引き直し、resolv-retry infinite は名前引きに失敗しても終了せず再試行を続けさせる。サーバー側では float が、送信元アドレスが変わった相手に既存セッションを追従させる。WireGuardはもっと率直で、wg-quick up は設定を適用した時点で Endpoint を解決し、クライアントはトンネルを作り直すときにまた解決する。だから古いアドレスに対して成功し続けるハンドシェイクは、止まるまで成功し続ける。

この違いが計画を決める。クライアントが必要なときだけ接続するなら、アドレス変更のコストは再接続一回だ。何日もセッションを開いたままにするなら、次のハンドシェイクでトンネルは死ぬと見て、上がったまま前提にせず再試行させるべきだ。

条件三：入り口の経路が開いたままである

動的DNSが変えるのは名前の向き先だけで、それ以外ではない。ルーターのポート転送、VPNホストのファイアウォール規則、ISPが受信パケットを許すこと、そのすべてがレコードより先に必要だ。転送が何を指しているかを見る。インターフェースではなくWANアドレスに固定されていると、アドレス変更で転送が黙って壊れ、レコードのせいにされる。

外から試す。Wi-Fiを切ったスマートフォンのモバイル回線が最も安上がりで正直な試験で、同じLANのノートPCでは代わりにならない。名前が公開アドレスに解決し、ルーターにNATループバックが無いと、内側からの試験は失敗する。レコードは完全に正しいのに、多くの人が間違ってもいないレコードを編集しに行くのはこのためだ。

三つすべてが成り立つときに動かすもの

小さなホストにはddclientが最も驚きの少ない更新ツールだ。最小限の設定でプロバイダーから見えるアドレスを公開するので、二重NATの誤りを避けられる。

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

シェルループではなくsystemdタイマーで数分おきに動かし、成功を前提にせずプロバイダーの応答を記録する。資格情報は鍵として扱う。どのクライアントをどこへ送るかがこれで決まるからだ。アカウントのパスワードではなく範囲を絞った更新トークンを使い、ファイルは0600に保ち、更新はHTTPSで送る。

決める前に検証する

一度の問い合わせで外の世界から見える値がわかり、変更後に待つべきTTLも表示される。

dig +noall +answer vpn.example.net @1.1.1.1

そのアドレスをルーターのWANアドレスと比べる。一致していれば名前は役目を果たしており、まだ失敗するのは受信側の到達性、鍵、引き直していないクライアントのいずれかだ。違っていれば、更新ツールが間違ったインターフェースを公開している。ルーター自身ではなく、ルーターの後ろのVPNホストで動いていたためであることが多い。

一分で戻せる巻き戻しを用意する。最後に動いたアドレスと直前のTTLを控えておけば、プロバイダーが不調な午後でも手で両方公開できる。

答えが「いいえ」のとき

条件一か三が崩れるなら、変えるのは設定ではなく判断だ。キャリアNATの背後では、ISPに公開アドレスを頼む、入り口を固定アドレス付きの小さなVPSへ移す、あるいは自前の待ち合わせを持つオーバーレイを使う、が現実的な選択肢になる。アドレスが固定なら更新ツールは不要で、Aレコード一つ、IPv6を動かすならAAAAレコード一つ、ポート転送は同じままでよい。

クライアントが接続したままアドレスが変わるなら、正直な修正はクライアント側にある。再接続のロジックと再試行の間隔であり、より速い更新ツールではない。二つ目のプロバイダーを足しても間隔が隠れるだけだ。

先に進む前に、四つを順に確認する。

• 更新ツールが公開するアドレスがルーターのWANアドレスと一致しているか。
• レコードのTTLが、変更が数分で反映される程度に短いか。
• ポート転送が固定アドレスではなくインターフェースに紐づいているか。
• 最後の変更以降に、実際のクライアント一台が再接続して通信を通したか。

四つとも成り立てば設定はそのままにする。次の不調は名前の問題ではなく、鍵かファイアウォール規則だ。どれかが崩れたら、可動部品を増やす前にその行を直す。RFC 2136 は更新機構そのものを説明している。デーモンが回線に何を流すか見たいなら読むとよい。