どのリンクが応答するか：スプリットトンネルVPN DNSのルーティングドメイン

通常のブラウジングはローカルリンクに残したまま、会社名はトンネルが提供するDNSサーバーで解決します。VPNのデフォルトルートを切ると前半だけが得られ、後半は未構築のままです。以下では、欠けている設定、その意味を変える記号、そしてどのリンクが実際に応答したかを示す唯一のコマンドを扱います。NetworkManagerとsystemd-resolvedを前提とします。混乱はたいていこの組み合わせから始まるからです。

手順その一：ルートとリゾルバーを分ける

ipv4.never-defaultはルーティングの問いに答える設定で、NetworkManagerがこの接続をすべてのIPv4トラフィックの経路としてインストールするのを止めます。DNSルーティングドメインは別の問いに答えます。一致するサフィックスのクエリを、どのリンクのネームサーバーが受け取るかです。どちらも他方を意味せず、プロファイルは片方を何年も持ちながらもう片方を欠くことがあります。ルートのみとは、トンネルが会社のサブネットを運び、そのリゾルバーが会社名に答える一方、他はすべてそのままという意味です。

ルートのプロパティだけを設定すると、社内名は失敗します。多くは壊れたトンネルのように見えるタイムアウトです。ドメインだけを設定すると、マシン上のすべての短い名前に検索サフィックスを静かに追加したことになります。どちらの誤りもチケットをVPNサーバーへ送りますが、そこが間違っていることはほとんどありません。

手順その二：ルーティング専用ドメインをプロファイルに追加する

接続名がcorp-vpn、会社のサフィックスがinternal.example、トンネルのリゾルバーはすでに到達可能だとします。まず現在の値を読みます。下のコマンドは既にエントリを持つ可能性のあるプロパティを変更するからです。

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

接続名とサフィックスは自分のものに置き換えてください。上の値は例です。プラス記号は見た目より重要です。付けると既存のリストに追加され、付けないとプロパティが置き換わり、昨日まで動いていたプロファイルから無関係なドメインが消えます。チルダは見た目ではなく動作を変え、以下の段落がその選択内容を説明します。書く前に読む手順を守り、置換形式に驚かされないようにしてください。

先頭のチルダはルーティング専用ドメインを示すので、一致するクエリはこのリンクのサーバーへ行き、サフィックスは短い名前に付きません。チルダを外すと同じ文字列が検索サフィックスにもなり、これは人が意図しない別の結果です。上の二つの設定はIPv4なので、デュアルスタックのプロファイルにはipv6.never-defaultとipv6.dns-searchの同じルーティングドメインが必要です。そうでなければIPv6側はデフォルトルートを使い続け、そこでは社内名が失敗します。

手順その三：どのリンクが応答したかをresolvectlに尋ねる

resolvectl statusを実行し、各リンクのDNSサーバーとドメインを読みます。次に、問い合わせが許可されている実際の社内名に対してresolvectl query host.internal.exampleを実行します。二つ目のコマンドだけが、ルーティングドメインが機能している直接の証拠です。応答したリンクを名指しするからです。ステータス一覧だけでは設定が証明され、クエリが解決を証明します。

systemd-resolvedは最も一致するルーティングドメインを選ぶため、別リンクのより具体的なドメインが競争に勝つことがあります。想定外のリンクから応答が返ったら、VPNのDNSサーバーに触る前にドメイン一覧を読んでください。~.のルートドメインはすべてに一致し、すでにある場合、自分の具体的なドメインは自分の名前では勝ちますが、リンクは頼んだ以上に多くに答えます。目的が会社名だけなら、そのルートエントリを削除するか狭めてください。

VPNリンクがDNSサーバーをまったく列挙しないなら、クライアントは一度も登録していません。背後のサーバーがないルーティングドメインは、欠けたドメインとは違う形で失敗するので、まず登録を直します。

手順その四：名前は解決するがサービスが動かないとき

正しい応答は解決が機能したことだけを証明し、アプリケーションには受け取ったアドレスへのルートがまだ必要です。そのルートは今設定した分割デフォルトを越えて存続しなければならないので、再びDNSを責める前に確認してください。次にサービスのポートへの到達性を確認します。ファイル共有やディレクトリサービスは解決・ルーティング・認証のどこでも失敗し、どの場合もよく似たメッセージを出します。結果を報告するときはこの三層を分けてください。そうしないと次の人が、すでに正しいDNSを再確認します。

この問いと一緒に出回るSambaの変更は、アクセス層の話でありDNSの選択ではありません。名前解決の不具合に適用するのは、小さな問題が二つ目を獲得する方法です。

手順その五：欠けたドメインを直すためにリゾルバーを置き換えない

リゾルバーのファイルを上書きしたり別のリゾルバーマネージャーを導入したりする助言は、別の問題を解きます。それらは独自の障害モードを持つシステム統合の変更で、設定されていないルーティングドメインを足すものはありません。置き換える前に、そのマシンで名前解決を所有するコンポーネントを確定してください。systemd-resolvedを備えたNetworkManagerのデスクトップでは、その所有はすでに定義されています。それと戦うことが、動く構成を誰も再現できないものに変える道です。

作業順序：トンネルがリゾルバーを提供することを確認し、ルーティング専用ドメインを追加し、プロファイルの操作で再接続し、応答するリンクを検証し、最後にサービスをそのポートで試します。この順序なら、二度目の聞き取りなしで次の人に渡せる結果が残ります。