☰

固定ドメインのリストに対して常にVPN内部ネームサーバーを使用するようにパーティションDNSリゾルバを設定します。

tag-icon • tag-icon networkmanager vpn dnsmasq resolv.conf systemd-resolved
固定ドメインのリストに対して常にVPN内部ネームサーバーを使用するようにパーティションDNSリゾルバを設定します。

VPNがダウンしてアクセスできない場合でも、内部ドメインの固定リストを常に内部ネームサーバーを介して確認しながら、他のすべてのタスクにネイティブネームサーバーを引き続き使用させる最も安定した構成は何ですか？

KDE（または他のデスクトップ環境）で適切なインターフェイスまたはネットワークを選択した後、NetworkManagerは接続を確立します。

この質問は、特に次の理由でVPNドメインの静的リストを定義することに関するものです。

  • VPN内の内部ネームサーバーにのみ知られている3つの内部ドメインがあるとします。それらの2つは、/etc/resolv.confVPN接続を確立すると自動的に「検索」ドメインとして追加され、VPN接続を確立すると内部ネームサーバー（ファイルの前に追加）を行うように構成されたクライアントです。
  • プライマリVPNの内部ドメインが「.int」、「.org」、および「.test.net」であると仮定し、クライアントがファイルを変更するように設定されている場合、最初の2つのドメインが検索ドメインとして追加されますresolv.conf。
  • /etc/resolv.conf接続が確立された後にVPNクライアントが変更されると、すべてのDNS要求は内部ネームサーバーに送信されます。このサーバーは3つの内部ドメインのみを処理し、他のドメインは処理しません。
  • VPN接続が失われるたびに、VPNクライアントはresolv.confDHCPによって割り当てられ、NetworkManagerによって追加された標準ネームサーバーのみを残し、自動的にファイルをリセットします。したがって、VPNが終了するたびに内部DNS要求が停止します。方法を提供;標準のネームサーバーに送信されますが、標準のネームサーバーはそれを知らないか、他の外部IPで確認します。
  • このファイルは、KDEで接続が確立されるたびにDHCP割り当てネームサーバーに書き込まれます。 NetworkManagerはこれを処理します。のみを含むファイルへのリンクの場合は、受信したネームサーバーのIPアドレスをリゾルバーが使用するファイルnameserver localhostに書き込む必要があります。uplink.conf
  • resolv.confファイルがファイルのみを含むシンボリックリンクで、ローカルリゾルバがnameserver localhostドメインに基づいてクエリを渡す方法を常に知っている場合は、ファイルを変更する必要はありません。
  • 内部ネームサーバーのIPアドレスは、内部ドメインリストと同様に静的です。これらの内部ドメインに対するDNSクエリは、例外なく内部ネームサーバーにのみ送信できます。
  • 通常どおり、他のドメインに対するDNSクエリは標準のネームサーバーで処理する必要があります。同様の問題はネームサーバーを手動で構成することで解決されましたが、この場合、システムはDHCP割り当てネームサーバーを使用する必要があります。
  • dnsmasqを使用したクイック試行に失敗しました。構成などを行った後も、依然としてserver=/int/10.1.1.1標準ネームサーバーにクエリを送信します。xxx.intログファイルには、DHCP割り当て標準ネームサーバーの場所using nameserver 10.1.1.1#53 for domain intと場所が表示されますusing nameserver 192.168.1.1#53 for domain int（したがってDNSクエリが漏れています）。192.168.1.1systemd-resolvedを使用するソリューションが好まれますが、他のソルバーの構成例も歓迎します。
  • 問題の焦点は、VPN接続状態であるか、2番目のVPN接続が現在アクティブであるかに関係なく、ローカルリゾルバ（systemd-resolvedなど）の設定です。
  • この質問は特定のディストリビューションに関するものではありません。 systemdを使用し、KDEを含むすべてのディストリビューションで動作します。例えば、Fedora 33はsystemd-resolvedを使用しています。基本的に、これの設定例は良いでしょう。
  • dig、、、hostなどnslookupの標準ツールがping機能する必要があります（たとえば、間違ったネームサーバーにクエリを送信しないなど）。

このサイトには同様の質問があり、一般的にリーククエリは必要なく、他のサイトにも同様の質問があります。例えば、gnome.orgの記事「分割DNSの問題」を解決しているようです。会社のVPNにルーティングドメインがありません。どうすればいいですか？「しかし期待される。みんなVPN クライアントによって設定され、次を説明する内部ドメインです。

...残念ながら、既存の非分割DNSでは重要ではないため、すべてのVPNが実際にこれを正しく実行しているわけではありません。悪いことに、GNOMEシステム設定にはこの問題を解決するためのグラフィック構成はありません。本当になければなりません。しかし、今は使用する必要がありますnmcli ...

そのようなコマンドを使用する必要があるのは、安定した構成のようには見えません。そして一時的に切断された場合、DNSクエリは漏えいしてはいけません。。記事は続きます：

これを台無しにする必要がないことを願っています。

そうだったらどうでしょうか？これはあまり珍しくないはずです。標準ソリューションが少なくとも1つ必要です。

参考までに、次のdnsmasqを設定しようとしましたが、DHCPがデフォルトで提供する標準ネームサーバーの要件を満たしていません。

/etc/dnsmasq.d/dns-int.conf:

no-resolv
server=/int/10.1.1.1
server=/org/10.1.1.1
server=/test.net/10.1.1.1
server=/google.com/8.8.8.8 # example
server=9.9.9.9 # not wanted
log-queries

の/etc/NetworkManager/NetworkManager.conf下部[main]：

dns=dnsmasq

dnsmasqを直接起動するときに使用する設定ファイルを指すNetworkManagerが使用する設定ディレクトリにシンボリックリンクを追加しますsystemctl start dnsmasq。

`/etc/NetworkManager/dnsmasq.d/dns-int.conf` -> `/etc/dnsmasq.d/dns-int.conf`

ただし、上記のように、この構成は完全に正確ではありません。

ベストアンサー1

この質問は主にsystemd-resolvedに関するものですが、dnsmasqに対する私の試みを別々の答えとして説明するのが役に立つと思いました。私は他の答えが最初に出てくるように私の答えを反対投票し、最初になぜそれがうまくいかなかったのか明確ではなかったので反対しました。編集：私の投稿に反対投票をすることはできないようです。たぶん、他の人がこれを行うことができます。

DNS

まず、NetworkManagerがdbusを介してdnsmasqにこのリストを送信するため、デフォルトのネームサーバーリストとして「アップリンク」プロファイルを指定する必要はありません。ただし、何らかの理由でこれが機能しない場合は、ネットワークに接続または再接続するときにNetworkManagerによって生成されるファイルをdnsmasqとして指定して明示的に指定できます。

resolv-file=/run/NetworkManager/no-stub-resolv.conf

dnsmasq 構成ファイル: /etc/dnsmasq.d/dns-int.conf:

no-resolv
server=/int/10.1.1.1
server=/org/10.1.1.1
server=/test.net/10.1.1.1
no-poll
domain-needed
strict-order
clear-on-reload
no-negcache
log-queries

/etc/NetworkManager/NetworkManager.confの[main]セクションで：

dns=dnsmasq

systemctl start dnsmasqを使用してdnsmasqを直接起動するときに使用する設定ファイルを指すNetworkManagerによって使用される設定ディレクトリにシンボリックリンクを追加します。

`/etc/NetworkManager/dnsmasq.d/dns-int.conf` -> `/etc/dnsmasq.d/dns-int.conf`

注：dnsmasqがすべてのクエリを上記の内部ドメイン（内部ネームサーバーだけでなく10.1.1.1DHCP割り当てデフォルトネームサーバー）に渡すため、初期試行は失敗しました。

$ sudo grep dnsmasq /var/log/messages | grep forward | grep test.net
May  3 10:06:52 ... dnsmasq[4128385]: forwarded foo.test.net to 10.1.1.1
May  3 10:06:52 ... dnsmasq[4128385]: forwarded foo.test.net to 192.168.1.1

今はもうこれをやっていないようです。そもそもなぜそんなことをしたのかわかりません。

また、設定ファイルに以下を追加して、検索ドメイン「intern」のクエリをブロックしようとしました。

address=/intern/

マニュアルページによると、Queries in the domains are never forwarded代わりに次のことを行います。

forwarded foo.intern to 192.168.1.1

偽のアドレスを試しました:

address=/intern/127.0.0.2

... dnsmasq[95222]: query[A] foo.intern from 127.0.0.1
... dnsmasq[95222]: config foo.intern is 127.0.0.2
... dnsmasq[95222]: query[AAAA] foo.intern from 127.0.0.1
... dnsmasq[95222]: forwarded foo.intern to 192.168.1.1

$ host foo.intern localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases: 

foo.intern has address 127.0.0.2
Host foo.intern not found: 3(NXDOMAIN)
Host foo.intern not found: 4(NOTIMP)

このようにしてIPv6クエリが漏洩する。この特定の設定を使用すると、次のようになります。

address=/intern/#

MXクエリが漏洩しています。

... dnsmasq[97107]: query[AAAA] foo.intern from 127.0.0.1
... dnsmasq[97107]: config foo.intern is ::
... dnsmasq[97107]: query[MX] foo.intern from 127.0.0.1
... dnsmasq[97107]: forwarded foo.intern to 192.168.1.1
... dnsmasq[97107]: reply error is not implemented

言い換えれば、DNS漏れを止めたと思う瞬間、新しいDNS漏れが現れます。これは、NetworkManagerがdnsmasqを起動したときに発生します。 （address=/intern/dnsmasqが手動で起動すると動作しているようです。）

それ以外は、ほとんどの場合動作しているように見えますが、システム解決タスク構成を持つ方がまだ良いです。

おすすめ記事