LANのホスト名がVPN越しに解決できない：サフィックス、mDNS、ゾーンのどれか

デバイスの隣では、プリンターは短い名前に応答し、ファイルサーバーは愛称に応答します。トンネル越しでは、アドレスはまだ機能しているのに、どちらの名前もタイムアウトします。ルートは役目を果たしており、それらの短い名前を機能させていた名前解決の経路がトンネルを越えたことはありません。この動作を生む仕組みは三つあり、それぞれに別の修正が必要です。

まず、名前がどの仕組みに依存しているかを見極めます。

異なる振る舞いをする三種類の名前

fileserver のような単一ラベルの名前は、通常リゾルバーが付加する DNS 検索サフィックスに依存します。そのサフィックスは多くの場合ローカルの DHCP リースとともに届くため、VPN からアドレスを受け取るリモートクライアントには知る理由がありません。ルートを追加してもサフィックスは届きません。短い名前は、その背後にあるアドレスに到達できても、名前としては存在しなくなります。

RFC 6762 が説明するように、.local で終わる名前は通常、ローカルリンク上のマルチキャスト DNS で解決されます。マルチキャストは、何かが意図的にブリッジやプロキシをしない限りルーティングされたトンネルを越えないため、セグメントを離れた瞬間に名前は解決しなくなります。

完全修飾された社内名は、組織のリゾルバーが提供する内部ゾーンに属します。これは VPN がそれらのリゾルバーをプッシュし、クライアントがそれを使うよう設定されていれば、リモートでも機能します。そして localhost は RFC 6761 により特別用途であり、目の前のマシンを指し、リモートのサービスを指すことは決してありません。

ルートを変える前にリゾルバーを読む

どのネームサーバーが応答し、どのサフィックスが付加されたかを尋ねます。同じ問い合わせでもリゾルバーが違えば答えは変わり、その違いこそが必要な証拠です。

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

完全修飾の問い合わせが解決し、短い方が解決しないなら、原因はサーバーではなくサフィックスです。どちらも解決せずアドレスが機能するなら、クライアントは内部リゾルバーをまったく使っていません。問い合わせのたびにローカルのリゾルバーを保持するクライアントには内部ゾーンが決して見えないため、リゾルバーの一覧を VPN がプッシュするはずの内容と比べてください。

正しい名前をクライアントに届ける

管理者に文書化されたリモートアクセス名を完全な形で求め、サフィックスを推測する代わりにプロファイルでそれを使います。配備が split DNS をサポートするなら、内部ドメインを内部サーバーで解決するよう設定し、それ以外はローカルのリゾルバーを保ちます。クライアントが対応している場所では、検索ドメインを VPN 設定でプッシュします。

結果はゲートウェイではなくクライアントで確認します。サーバーに適用されクライアントに届かない設定は何も変えません。

証明書の同一性を保つ

証明書のエラーを無視するアドレスベースのテストは、ソケットが開いたことしか証明しません。サービスの証明書は名前に対して発行されており、クライアントは当然の理由で不一致を拒否し続けます。証明書が内部名だけを列挙しているなら、その名前を使って解決を直すか、使う予定のアドレスをカバーする証明書を取得してください。

接続に成功した名前、リゾルバー、サフィックスを記録します。その記録は、本当の問題を隠すアドレスベースの回避策を次の人が繰り返すのを防ぎます。