dnsmasq の VPN ドメインはゾーン転送ではありません

クライアントの dnsmasq 設定で企業ゾーンを探し、見つからないので VPN がドメインをプッシュしなかったと結論します。プッシュされたのはルーティングのヒントであり、ゾーンではありません。クライアントはドメインと、それに応答すべきリゾルバーを記録し、管理された backend がそれを条件付き転送に変えます。間違った場所を見ると、自信に満ちた完全に誤った診断が生まれます。

クライアントが受け入れたものは、ゲートウェイが提示したものではありません

ゲートウェイはリゾルバー、ドメイン、そのリゾルバーに到達するための経路を提示でき、クライアントは三つすべてを受け入れることも、どれも受け入れないこともできます。インポートされたプロファイル、ヘルパースクリプト、プッシュされたオプションを無視するポリシーは、サーバー側が正しく見えるのに受け入れ済みの集合を空のままにすることがあります。サーバーの設定ではなくクライアントの記録された状態から始めてください。リゾルバーが実際に受け取るのはその状態だからです。受け入れられたドメインがなければ、その先は何も重要ではありません。キャッシュを調べる前に接続の DNS プロパティを確認してください。

その違いが、決して届かなかったドメインに関する報告のほとんどを説明します。提示はされ、適用されませんでした。

ドメインエントリーの二種類

接続は通常の検索ドメインとルート専用ドメインを運ぶことができ、二番目の種類はチルダで始まります。検索ドメインはクエリをルーティングし、短い名前の展開を可能にします。これはワークステーションでは便利で、サーバーでは驚きです。ルート専用ドメインは、そのサフィックスのクエリが短い名前の解決方法を変えずに特定のサーバーへ行くべきだと述べます。同じドメインを両方の方法で書くのは冗長ではありません。二つのエントリーは別の仕事をするからです。

プライベートな名前空間には、通常はルート専用の形式が適しています。企業のサフィックスを企業のリゾルバーに向けたまま、ほかのすべてをそのままにします。

resolv.conf の localhost はバグではありません

ローカルのキャッシュリゾルバーを使っているとき、システムファイルはループバックアドレスだけを指し、ほかの何も指しません。そのエントリーはローカルのリスナーを識別するもので、マネージャーが渡した上流サーバーではありません。企業のアドレスがファイルにないのは正当です。

そのエントリーを公開リゾルバーに置き換えるのは典型的な誤修正です。公開の名前解決を復元する一方で、同じ編集で条件付きポリシーを捨ててしまいます。

backend を混同しないでください

管理された dnsmasq インスタンスとシステムリゾルバーは、異なる設定と異なる状態表示を持つ別のプログラムです。一方の状態コマンドは、もう一方について役立つことを何も伝えません。

マネージャーがどの backend を使うように設定されているかを特定し、その backend の生成された設定を読んでください。偶然存在するディストリビューション全体のファイルではありません。マネージャーは独自のインスタンス設定を書き、そのインスタンス向けのカスタムオプションをサポートするので、無関係なグローバルファイルを編集しても何も変わらず、効果のない変更に見えます。ポート 53 で二つ目のデーモンを起動するのは無益どころか有害です。いまや二つのプログラムがポートの所有者について一致しないからです。まず所有者を確定し、その所有者が読む場所を編集してください。

名前空間をテストしてください。答えだけでなく

アプリケーションの通常の経路で、許可されたプライベート名を一つと公開の対照名を一つ問い合わせてください。企業サーバーへの直接クエリはレコードが存在することを証明しますが、クライアントがそのサーバーを選んだことは証明しません。二つ目のクエリがポリシーをテストします。

そのあと、再接続後と切断後に繰り返してください。関連付けは接続のライフサイクルに従うべきで、プライベート名はトンネルがなくなったときに解決をやめるべきです。同じサフィックスに応答する公開リゾルバーへフォールバックしてはいけません。フォールバックするなら、それは漏洩であり、壊れた検索とは別の欠陥です。どの backend が動いていたか、どのドメインが適用されたか、各クエリが何を返したかを書き留めてください。