OpenVPNクライアントを別ホストのPi-holeリゾルバーに向ける

OpenVPNプロファイルにPi-holeのアドレスを書いても、そこへの経路はできず、問い合わせの許可も得られず、クライアントがそれを使う保証もありません。Pi-holeが別のLANマシンにある場合、四つのことが揃わなければなりません。クライアントからの経路、ゲートウェイでの転送、プールへの戻り経路、そしてPi-hole自体の受け入れポリシーです。失敗はそれぞれログに違う形で現れます。その順に片付けるほうが、最後の問題を最初に直すより速いです。よくある近道、すべての送信元に再帰を開くことは、小さな問題を恒久的な問題に交換します。

プッシュされたDNSオプションがすること、しないこと

サーバーは192.168.50.53をPi-holeホストと仮定し、次のディレクティブでリゾルバーを通知します。クライアントはこのオプションを受け取り、 プラットフォームとリゾルバーの統合方法に応じて、トンネルのインターフェースに適用するか、ローカルのスタブを優先して無視します。経路の行はDNSの行と同じくらい重要です。クライアントが届かないリゾルバーはリゾルバーではないからです。これらはいずれもサーバー側からは見えません。

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

オプションを受け取ることは、それを使うことと同じではありません。リゾルバーマネージャーを持つLinuxクライアントはプッシュされたサーバーを受け入れ、特定のドメインだけをそこへ送るかもしれません。DNSを自分で管理するクライアントは設定を完全に上書きすることがあります。プッシュされた経路も一部のプラットフォームでは制限され、オプションが受け入れられてもリゾルバーに届かないことがあります。サーバー側で何を送ったかではなく、クライアント側でどのサーバーが応答するかを確認してください。

オプションはサーバー側についても何も語りません。DNSトラフィックはどのオプションが意味を持つ前に、依然としてクライアントからゲートウェイへ、ゲートウェイからPi-holeへ流れなければなりません。欠けた経路と拒否された問い合わせはクライアントから見ると同じに見えるので、まずゲートウェイの転送を確認してください。

Pi-holeからプールへの戻り経路

クライアントの送信元アドレスが保たれると、Pi-holeはVPNプール内のアドレスへ応答します。Pi-hole自身のルーティングテーブルはそのプールについて何も知らない可能性が高く、応答は既定のゲートウェイへ送られて消えます。問い合わせログには対応する応答のない要求が残り、これをファイアウォールの問題と誤解しやすくなります。

LANルーターにOpenVPNゲートウェイを次のホップとするプールへの静的経路を与えるか、Pi-holeへ転送する前にゲートウェイで送信元を変換してください。前者はクライアントごとのアドレスをPi-holeの問い合わせログに見えたままにします。後者は戻り経路の要件をなくしますが、すべての問い合わせがゲートウェイから来たように見せます。どちらも間違いではなく、別の問いに答えています。

クライアントごとのレポートやポリシーが重要なら、静的経路のほうが良い取引です。LANを別の人が管理していて経路が使えないなら、変換が現実的な選択であり、クライアントの識別情報が失われることを書き留めます。どちらを選んだかを記録してください。以後のログの問いはすべてそれに依存します。

ルーティングされたクライアントに対するPi-holeの待ち受けモード

DNSの下にある設定ページのインターフェース待ち受け動作のドロップダウンは、Pi-holeがどの送信元に応答するかを決めます。最も厳しい選択肢は直接接続されたネットワークのクライアントだけを受け入れます。装置を最大で一ホップ先まで許す選択肢はそれを隣接ルーターの背後のサブネットまで広げ、ルーティングされたVPNクライアントはまさにそう見えます。パケットは確かにLANインターフェースに届きますが、送信元アドレスは別のサブネットに属します。これはルーティングの失敗ではなくポリシーによる拒否であり、ログを読むときにはその違いが重要です。

Pi-holeの待ち受けガイドはローカルに接続された送信元とルーティングされた送信元を分けており、到着インターフェースは判断基準ではありません。インターネット全体を許さずにVPNプールを許すモードを選び、プールからだけDNSを受け入れるファイアウォール規則と組み合わせてください。

最初の問い合わせを通すためにすべての送信元へ再帰を開くのは誤った修理です。私設リゾルバーを公開リゾルバーに変えてしまい、修正は全体許可ではなく範囲を絞った許可です。

応答を問い合わせログと突き合わせる

クライアントに尋ね、次にサーバーを確認し、両者を比較してください。systemd-resolvedのクライアントでは、次のコマンドがどのリゾルバーが応答を作ったか、リンクごとにどのサーバーが設定されているかを報告します。Pi-holeだけが知る名前を使ってください。Pi-holeのアドレスへの直接の問い合わせは設定ではなく到達性を証明するからです。

resolvectl query intranet.example.lan
resolvectl dns

期待される応答は192.168.50.53をサーバーとして示し、そのリゾルバーだけが知るアドレスを返します。次にPi-hole自身の表示を見てください。pihole -tは問い合わせログをリアルタイムで追い、各行に送信元アドレスが付きます。送信元がクライアントのトンネルアドレスならプールの経路は無事です。ゲートウェイのLANアドレスなら送信元変換が働いており、クライアント自身のアドレスは決して現れません。

ログに何も現れなければ問い合わせはPi-holeに届いておらず、次に確認するのはゲートウェイの転送です。問い合わせが現れて応答が返らないなら、問題は戻り経路、つまり前の節です。失敗をこのように分ければ、ルーティングの誤りをファイアウォール規則と取り違えずに済みます。

ゲートウェイの転送規則を確認する

ゲートウェイはクライアントのDNSパケットをPi-holeへ転送しなければならず、それを行う規則は推測せずに読む価値があります。次のコマンドはポート53に触れる規則をカウンター付きで一覧し、nftablesのホストとiptablesのホストで実行します。存在しても一致がゼロと表示される規則は、変換前にトラフィックが捨てられている合図です。

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

規則だけでなくカウンターを読んでください。決して一致しない規則は、パケットが別のインターフェースから出ているか、クライアントがそもそも送っていないことを意味します。すべての問い合わせで一致する規則は、転送が機能しており問題が経路のもっと先にあることを意味します。

ホストがどのツールを使うにせよ、確認は狭く保ってください。プールを送信元、ポート53を宛先、Pi-holeを唯一許可された対象とします。ポート80まで許可する広い転送規則は、起こるのを待っている別の問題です。