Split DNSは、自宅内でのみ動作しないセルフホスト型アプリを修正できますか？

はい、スプリットDNSは、パブリックホスト名が自宅の異なるローカルアドレスに解決されるべき場合に、内部のみの障害を修正できます。

セルフホスト型アプリは、パブリックDNSが自宅のWANアドレスを指しているためモバイルデータから動作することがありますが、LAN内のデバイスはルーターがその接続をパブリックNATルールを通じてループバックできないため失敗します。スプリットDNSは、ローカルのリバースプロキシやアプリのアドレスを自宅のクライアントに返すことでそのループを回避しますが、同じホスト名、証明書、プロキシルート、アプリケーションのベースURLが両方の経路で有効な場合にのみ成功します。

まず外部からパブリック名が機能することを確認する

モバイルデータや他の外部ネットワークから正確なアプリケーションURLをテストします。DNS解決、TLS、リバースプロキシのルーティング、ログイン、リダイレクト、および現在自宅内で失敗しているアプリケーションの機能を確認してください。

TailscaleはスプリットDNSを、内部と外部のユーザーを同一のルートに強制するのではなく、コンテキストに応じてクライアントに異なるDNS応答を提供する方法として説明しています。

もしアプリが外部でも失敗する場合、スプリットDNSは最初に修正すべきものではありません。パブリックDNS、トンネルやポートフォワード、プロキシルーティング、TLS、またはアプリケーション設定を修正してから、元の問題を隠す可能性のある二つ目の応答を作成してください。

内部の障害がハーピンNATかどうか確認する

自宅のクライアントからパブリックホスト名を問い合わせて返されたアドレスを記録します。もしそれが自宅のパブリックIPに解決されるなら、その転送サービスに対してルーターがNATループバックまたはハーピンNATをサポートしているか追跡してください。

Level1Techsのトラブルシューティングスレッドでは、ハーピンNATが信頼できない場合にローカルDNSオーバーライドでドメインを内部サーバーアドレスに向ける方法を推奨しています。

パブリック名の障害とローカルのリバースプロキシアドレスへの直接アクセスを比較してください。もし直接のローカルアクセスが意図したプロキシやアプリに到達し、パブリックIPが内部からのみ失敗するなら、スプリットDNSが適しています。

内部の応答を同じ論理的な入口に向ける

既存のパブリックホスト名に対して内部DNSレコードを作成し、リバースプロキシや制御されたローカルの入口ポイントのLANアドレスを指すようにします。外部ユーザーが通常プロキシを通過する場合は、バックエンドを直接指さないようにしてください。

スプリットDNSの比較では、ローカルクライアントが同じドメインをプライベートな内部アドレスに解決できる一方で、外部クライアントは引き続きパブリックアドレスを受け取ることが説明されています。

両方の経路を同じプロキシに保つことで、ホスト名ベースのルーティング、アクセスポリシー、ヘッダー、証明書が維持されます。ホームクライアントをプロキシの回り道にするとページは読み込めても、認証、コールバック、WebSocket、またはプロキシにのみ存在するセキュリティ制御が壊れる可能性があります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

必要なすべてのクライアントが内部リゾルバーを使用していることを確認する

内部の応答を受け取るべき電話、ノートパソコン、テレビ、コンテナ、VPNクライアントが使用しているDNSサーバーを確認してください。ブラウザのセキュアDNS、モバイルのプライベートDNS、VPNリゾルバー、またはハードコードされたパブリックDNSサーバーは自宅のリゾルバーをバイパスする可能性があります。

セルフホスティングのスプリットDNSガイドは、VPNやクライアントが内部ネットワークにいても誤ったリゾルバーコンテキストを使い続けると障害が頻発すると警告しています。

内部DNSサーバーに直接問い合わせ、その応答を通常のクライアントのルックアップと比較してください。サーバーがローカルアドレスを返すのにクライアントが返さない場合は、DHCPのDNS配布、暗号化DNS、VPNポリシー、クライアントのオーバーライドを修正してからレコードを再編集してください。

TLSとアプリケーションのコールバックに同じホスト名を維持する

内部レコードが有効になった後は、通常のドメインでアプリにアクセスしてください。プライベートIPのブックマークに置き換えないでください。HTTPS証明書やリバースプロキシルートは一般的にホスト名に紐づいています。

内部経路はアプリのパブリックベースURL、OAuthリダイレクトURI、Webhookアドレス、転送ヘッダーも維持しなければなりません。スプリットDNSは宛先アドレスを変えるものであり、ブラウザやプロバイダーが使うべきホスト名は変えません。

もしアプリがパブリックIPにリダイレクトしたり、内部ホスト名を生成したり、ホストヘッダーを拒否する場合は、プロキシとアプリのURL設定を修正してください。DNSだけでは一貫しないID設定のサービスは修復できません。

両方の経路が予測可能なままの場合にのみスプリットDNSを維持する

自宅Wi-Fi、ゲストWi-Fi、VPN、モバイルデータ、プライベートDNSを使う1台のデバイスからテストしてください。各クライアントが意図したアドレスを受け取り、同じアプリケーションIDに到達することを確認します。

ZimaSpaceのプライベートクラウドが特定のネットワークでのみ動作する理由のガイドは逆の症状を示し、二つのDNSビューが意図的に異なるままであることを検証するのに役立ちます。

スプリットDNSは、壊れたパブリックループを除去しつつ、同じドメイン、TLS証明書、プロキシルート、アプリケーション動作を維持する場合に適切な修正です。ルーターが信頼性高く処理でき、二つのDNSビューを維持するリスクが価値を上回る場合は、代わりにハーピンNATを使用してください。