Pi ホットスポットと Pi-hole・VPN：各サービスに役割を一つずつ

スマートフォンが Pi のホットスポットに接続し、アドレスを取得しても、ページはまだ開きません。Pi ではホットスポット用の支援ツール、Pi-hole、VPN クライアントが動いており、それぞれが経路の一部を自分が持っていると考えています。こうした構成の多くは、部品が壊れているからではなく、二つの部品が同じ仕事をしているから失敗します。どれかを調整する前に、機能ごとに所有者を一つ決めてください。

機能ごとに所有者を 一つ決める

ここでは四つの機能が重要で、それぞれにちょうど一つの所有者が必要です。以下の表は、機能、実現可能な所有者、二つのサービスが奪い合ったときに何が壊れるかを示します。

重なりはたいてい一つずつやってきます。ホットスポット用の支援ツールは独自の dnsmasq を入れ、Pi-hole は 53 番ポートを要求し、VPN クライアントは経路を追加します。どの手順も単独では妥当に見えますが、合わせると、後から起動したサービスが先のサービスの挙動を静かに変えるマシンになります。

ほかの何かを有効にする前に、所有者を書き留めてください。構築メモに短い表を一つ置けば、後からのインストールが既に所有者のいる機能を乗っ取るのを防げます。

範囲を 一つ選び、トンネルから遠ざける

ホットスポットの範囲、その中の Pi のアドレス、DHCP プール、クライアントが受け取るリゾルバを選びます。その範囲は、重なったサブネットが経路の問題をアドレス変換の企画に変えてしまうため、上流の LAN とも VPN トンネルの範囲とも重ねないでください。トンネルと重なる範囲は Pi を二つの同じプレフィックス間の意図しないルーターにしてしまいます。範囲とプールは既定値に任せず、ホットスポットの設定に書いてください。

ホットスポットを NetworkManager の共有モードが持っている場合は、DHCP サーバーを足す前に実際に効いている接続を確認してください。共有モードは独自の支援ツールを起動し転送を有効にするので、そのインターフェースのアドレス計画の所有者はすでに共有モードです。使えるからという理由で二台目のサーバーを足すと、冗長ではなく競合する配布が生まれます。

IPv6 は意識して決めてください。多くの構成では、ルーター広告と DHCPv6 は DHCPv4 とは別の支援ツールから来るため、VPN のポリシーが IPv4 だけを覆っているのに IPv6 を有効のままにすると、クライアントにトンネルを迂回する経路を与えます。IPv6 側を設計するか、ホットスポットのインターフェースで理由を書いた上で無効にしてください。

53 番ポートで実際に応答しているのは誰か

設定を変える前に、53 番ポートを待ち受けているプロセスをすべて挙げてください。ローカルのリゾルバスタブ、Pi-hole、共有用の支援ツールが動く Pi では、待ち受け一覧が、問い合わせに誰が応答しているかを示す唯一の確かな地図です：

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

Pi-hole のインターフェースガイドは、一つのインターフェースに限った受信モードでもワイルドカードソケットを使い、ほかへ届いたものを捨てられることを説明しています。これは選択したインターフェースだけにバインドすることとは別で、別の DNS サービスが同じマシンを共有するときに意図されるのは後者です。

二つのプロセスは通常、同じアドレスとポートにバインドできませんが、SO_REUSEPORT によって共有バインドが成功する場合があり、それでもワイルドカードの待ち受けが、より狭いサービス宛ての到着を取ってしまうことがあります。望む役割について文書化されたモードを選び、意図した順にサービスを再起動してください。

Pi-hole の管理ページはホットスポットのネットワークの外に置いてください。クライアントに必要なのはリゾルバであり、リゾルバの設定を変えられる Web 画面や API ではありません。

DNS の二本の脚、それぞれに一つのポリシー

クライアントの問い合わせはスマートフォンから Pi へ、別の問い合わせは Pi から上流のリゾルバへ流れます。転送されたホットスポットの通信に一致する経路規則は、その通信を Pi がローカルで生成するため、二本目の脚には自動では適用されません。VPN が DNS を運ぶべきなら、ローカルの経路には独自のポリシーが必要です。

ループに注意してください。Pi-hole の上流を Pi 自身が提供するアドレスに向けると、直接でもポート転送でも、タイムアウトするまで回り続ける問い合わせが生まれます。実際の上流を与えるか、答えられないドメインには条件付きフォワーダーを設定してください。

トンネルが落ちたときに何が起きるかを決めてください。ローカルのリゾルバへ戻すと閲覧は続きますが名前が VPN の外へ漏れる可能性があり、遮断すればポリシーは保たれ、障害は目に見えるエラーになります。どちらも筋は通りますが、既定値から引き継ぐのではなく選ぶ必要があります。

経路と切断時の挙動を確かめる

層ごとに、クライアントがアドレスを得る、クライアントが Pi 経由で名前を解決する、Pi が意図した上流経由で解決する、アプリが要求を完了する、という順に試してください。ping が通っても DNS の証明にはならず、名前解決が通っても転送の証明にはなりません。

dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1

次にトンネルを止めて繰り返します。意図した挙動は数秒以内に現れるはずで、Pi-hole やホットスポットのサービスを手で再起動した後ではありません。障害中は、予備の公開リゾルバはポリシーが失敗を期待していても応答を続けるため、クライアントのリゾルバ設定を確認してください。

転送と NAT の所有者は一つにし、Pi 自身ではなくクライアントから検証してください。Pi を正常に出た要求でも戻り道で捨てられることがあり、経路全体が見えるのはクライアントだけです。