自宅 VPN に nas.home.arpa 用の独自 DNS レコードを与える

dnsmasq から一つの名前を公開し、リゾルバーを WireGuard 経由でルーティングし、クライアント全体への DNS プッシュと home.arpa だけの split-DNS のどちらかを選びます。

トンネルが上がったら、最後の手順は通常、ブックマークに貼るアドレスの代わりに機能する名前です。dnsmasq のホストレコードとクライアントが到達できるリゾルバーのアドレスがあれば、二つのファイルとマルチキャストなしでそれが実現します。本当に考える必要がある判断はもっと狭いものです：クライアントがすべての DNS を自宅のリゾルバー経由で送るのか、home.arpa 配下の名前だけを送るのか。以下はすべて、Linux クライアントと、自宅の管理者がすでに運用しているラボ用リゾルバーを備えた承認済みの WireGuard 構成を前提としています。

クライアントにリゾルバーを渡す三つの方法

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

たまにトンネルに参加するノート PC には、通常のインターネット名をマシンがすでに信頼しているリゾルバーに残せるので、split-DNS がより良い既定です。自宅のサービスに到達するために存在するマシンには、リゾルバーをプッシュする方が簡単で、範囲のコストは問題になりません。

ゾーンを所有するリゾルバーでレコードを公開する

設定を書く前に役割を分けてください：VPN クライアントのアドレス、リゾルバー、サービスは三つの異なる仕事を持つ三つの異なるホストです。このラボでは、クライアントが 10.77.0.2、dnsmasq が 192.168.50.53、NAS が 192.168.50.20 で、トンネルが自宅 LAN をルーティングします。

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

host-record 行がアドレスを提供し、local= 行が未知の home.arpa の問い合わせを上流へ転送せずにこのリゾルバー内に留めます。まず既存の設定を読み、サーバー、インターフェース、同じローカルドメインをすでに定義しているものをすべて突き合わせてください（矛盾する設定の上に断片を重ねると、正常に読み込まれて誤って応答するリゾルバーになります）。dnsmasq のマニュアルに両方のディレクティブと待ち受けの制御が定義されています。

次に、ファイルではなく実行中のサービスを検証します。設定テストと再起動が最低限で、実際の答えは問い合わせが返すものです。

リゾルバーをルーティングする（ウェブページだけではない）

WireGuard の AllowedIPs が、どの宛先をトンネルに入れるかを決めます。リゾルバーのアドレスがその外にあると、問い合わせは通常の経路に出て dnsmasq に決して届きません（NAS 自体に到達できても同じです）。リゾルバーのアドレス、またはそれを含む LAN プレフィックスを含め、向こう側のゲートウェイの転送ポリシーを確認してください。

許可されたトンネル範囲からポート 53 の UDP と TCP を許可し、クライアントのトンネルアドレスへの戻り経路を用意します。テストを楽にするために WAN からポート 53 を転送しないでください：家庭回線のオープンな再帰リゾルバーは数時間で発見されます。インターフェースにバインドすること自体はアクセスポリシーではありません。

アプリケーションより先に答えを確認する

まずリゾルバーに直接問い合わせ、次にシステムに、次にアプリケーションに問い合わせます。各手順が連鎖の一つの環を切り分け、その差が診断になります。

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

TCP の問い合わせを実行する価値があるのは、切り詰められた UDP の応答が再試行を強制し、TCP 53 を落とすポリシーが断続的に見える障害を生むからです。getent の手順は、マシンのリゾルバー設定が実際に何をするかを示し、それはプッシュした内容と同じとは限りません。

トンネルが落ちているときに何が起きるかを決める

クライアントの一般 DNS が 192.168.50.53 を指していると、トンネルが上がっていないときにすべての名前解決が止まります。トンネルと一緒にしか役に立たないマシンでは許容できますが、カフェの Wi-Fi も使うノート PC では許容できません。split-DNS は、home.arpa の検索だけが自宅のリゾルバーに依存するため、この問題を完全に避けます。

その名前が何かを忘れないでください：home.arpa は住宅用ネットワーク向けに予約されており、世界的に一意ではないため、別のネットワークが同じ名前を正当に使えます。これはローカルの便利さであり、信頼できる識別子ではありません。サービスが移転したらレコードを最新に保ち、ラボを廃止したらリゾルバーポリシーを削除してください（もう存在しないトンネル経由でしか到達できないアドレスを指したままノート PC を残さないでください）。

関連記事