複数のリバースプロキシ向けにローカルDNSオーバーライドを設定する方法

各アプリケーション名に対して信頼できるローカルマッピングを1つ作成し、クライアントネットワークごとに正確に1つのリバースプロキシアドレスを指定します。複数のDNSサーバーに競合するワイルドカード上書きを作成しないでください。

同じパブリックドメインを内部でも再利用すると、複数のプロキシが混乱の原因になります。ノートパソコンはルーターに問い合わせ、コンテナはローカルリゾルバーに問い合わせ、スマートフォンは暗号化DNSを使用する場合があります。その結果、クライアントが誤ったアドレスを受け取っただけなのに、プロキシや証明書の障害のように見えることがあります。レコードを追加する前に、名前、リゾルバー、プロキシのリスナー、証明書を一覧化してください。

名前をプロキシの境界に割り当てる

すべてのアプリケーションFQDNと、TLS接続を終端するプロキシを一覧にします。例外には具体的なレコードを使用し、ワイルドカードは名前空間全体を1つのプロキシが管理するドメインにのみ使用します。

両方のプロキシが意図的に稼働し、同一の設定になっている場合を除き、同じ名前に2つのプライベートAレコードを割り当てないでください。DNSが返すのはサービスの健全性ではなくアドレスです。そのため、安易なラウンドロビンレコードによって、クライアントの半数がルートや証明書を持たないプロキシに送られる可能性があります。

管理用の名前とユーザー向けの名前は分けてください。管理者用ホスト名をゲストネットワークで決して解決させたくない場合は、後からプロキシで隠すのではなく、信頼済みVLANでのみ利用できるビューまたはリゾルバーに配置します。

クライアントが実際に使用するリゾルバーに上書きを配置する

そのネットワークのDHCPで通知されるDNSサービスに、ローカルゾーンまたはホスト上書きを作成します。各アプリケーション名は、所有するプロキシのLANアドレスを指すようにします。アプリケーションコンテナを指すのではなく、また自動的にパブリックWANアドレスを指すようにもしないでください。

クライアントとアプリケーションは異なるリゾルバーライブラリやキャッシュを使用することがあるため、DNSの動作が見えないままになることがあります。ルーターの上書きが参照されたと決めつけず、クエリ出力に表示されるサーバーを確認してください。

テスト中は、クライアント側の暗号化DNSを無効にするか、その影響を考慮してください。クライアントが意図的にローカルDNSを迂回する場合、スプリットホライズンの上書きは影響を与えられません。その場合は、管理対象のDNSポリシー、ヘアピンルーティングを伴うパブリックレコード、またはVPNが提供するリゾルバーを選択します。

プロキシのルート、TLS、アプリケーションURLを一致させる

各プロキシでは、そのプロキシに割り当てられたホスト名だけを設定し、証明書がそれらの名前をカバーしていることを確認します。正しいDNS応答の後に誤った証明書が返る場合、トラフィックがリスナーには到達したことは分かりますが、目的の仮想ホストに到達したとは限りません。

まずプロキシ自体から上流へのルートをテストし、次にクライアントからパブリックホスト名をテストします。上流へ直接アクセスできるのにホスト名でデフォルトサイトが返る場合は、DNSを再度変更する前にプロキシのホストマッチを修正してください。

パス配下でホストされるアプリケーションでは、プロキシのルートとアプリケーションのベースURLを一致させます。Jellyfinの公開を安全に解除する方法に関するZimaSpaceのガイドでも、DNS、プロキシルート、フォワーディング、ACLをまとめて管理する必要がある理由を説明しています。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

各ネットワークを検証し、ロールバックを定義する

まずFQDNを意図したローカルリゾルバーに直接問い合わせ、次にオペレーティングシステムの通常の経路を通して問い合わせます。どちらの応答も、そのネットワークでは同じプロキシを指し、TTLもローカルポリシーと一致している必要があります。

該当する場合は、信頼済みLAN、ゲストまたはメディアVLAN、VPNからアプリケーションを開きます。解決されたアドレス、証明書名、HTTPステータス、最終リダイレクトを記録してください。これらの情報から、障害がDNS、TLS、プロキシルーティング、アプリケーションのどれに起因するかを特定できます。

すべてのクライアントが正常に通過した後でのみ、古い重複レコードを削除します。クライアントごとにプロキシが切り替わる場合は、最新の上書きをロールバックし、失敗したすべてのリクエストにどのサーバーが応答したかをリゾルバーのログで確認できるまで、ワイルドカードの適用範囲を広げないでください。