スプリットトンネルはアプリに届いてもDNSサーバーには届かない

アプリのサブネットを経路に入れることはスプリットトンネルの明らかな部分ですが、それが仕事のすべてではありません。リゾルバーは提供先のアプリとは別のアドレスにいることが多く、動作しているトンネルでも名前解決がその外に残ることがあります。10.80.0.0/16だけを運ぶプロファイルは、10.90.0.53への問い合わせをローカルインターフェースから送り出し、そこにプライベートゾーンはありません。リゾルバーへの経路を追加したうえで、問題の後半、クライアントが実際にどのサーバーを選ぶかを確認してください。

神話：一本の経路でサービス全体をカバーできる

スプリットトンネルは接続を通る宛先の一覧であり、サービスの説明ではありません。アプリのサブネットとリゾルバーのアドレスは二つの宛先で、プロファイルは片方だけを運ぶことがあります。そうなるとアプリはアドレスでは到達できるのに名前が解決できず、経路の穴ではなくDNSの障害のように見えます。

リゾルバーの周囲のサブネットも自動的にカバーされるわけではありません。単一アドレスへのホストルートはそのリゾルバーには十分で、隣接アドレスを開くことはありません。これがホストルートの要点で、設計上狭く、次のサービスが同じサブネットに現れると忘れられがちです。

名前解決が機能するには、クライアントがリゾルバーのアドレスをトンネル経由で経路に入れること、ゲートウェイがその要求を受け入れて転送すること、リゾルバーが受け取った送信元を受け入れることの三つが必要です。応答も合意した経路で戻る必要があります。どれか一つが欠けると症状は同じなので、構成に触れる前にアドレス表を書き留める価値があります。

プロファイルが運ぶべきアドレスを決める

宛先は、アプリのネットワーク、リゾルバーのアドレス、そしてトンネル自体を終端する公開エンドポイントの順に並べます。三つ目は、外側の接続にはトンネルより前に存在する経路が必要なので、決してトンネル内に経路を入れてはいけません。

実装がUDPだけでなくTCPも支えることが期待され、TCPの経路が遮断されるときれいな失敗ではなく遅く部分的な失敗になるため、DNSにはUDPとTCPの両方を含めます。プライベートゾーンがIPv6でも提供される場合、同等のホスト例外はIPv6アドレスとプレフィックスを使い、別のエントリになります。

何かを追加する前に、プロファイルがすでに何をカバーしているかを記録します。重複した経路は無害ですが、予期しない既存の経路は、プロファイルが渡されたアドレス計画とは別の計画向けに設計されていることを示します。

接続の所有者を通じてホストルートを追加する

ローカルで管理されるネイティブのWindowsプロファイルでは、経路はマシンのグローバルルーティングテーブルではなく接続に属します。まず追加をプレビューし、その後プロファイルが使うのと同じスコープで適用します。

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

最初のコマンドは何もインストールせずに変更をプレビューし、二番目はプロファイルが現在運んでいる経路を一覧します。MicrosoftのAdd-VpnConnectionRouteのリファレンスは、ユーザーごとと全ユーザーのスコープを文書化しており、全ユーザーのプロファイルには独自のスコープパラメーターが必要で、全ユーザーのプロファイルに対するユーザーごとのコマンドは失敗するか間違った場所に着地します。

プロファイルが管理されている場合やベンダーのクライアントから来る場合、変更はその所有者に属します。永続的なシステム経路を接続ポリシーの上に積む方法は、ポリシーが再適用されて経路が消えるまで機能しますが、それは通常テスト中ではなくサポート対応中に起こります。その失敗は静かで、経路が消え、名前が解決されなくなり、誰も二つの出来事を結び付けません。変更は所有者自身の記録に入れて、次の再適用が消すのではなく引き継ぐようにします。

適用後は、経路が効いたと決めつけずにプロファイルを再接続します。稼働中の接続では経路の変更が常に反映されるわけではなく、再接続はユーザーが実際に経験する状態も再現します。

クライアントが実際にどのリゾルバーを使ったかを確認する

経路はリゾルバー宛てのパケットを制御します。どの名前をそこへ送るかは決めず、その選択は別の仕組みです。Windowsでは有効な名前空間の規則がドメインごとにリゾルバーを選ぶことがあり、プロファイルのDNS設定は既定値を与えます。この二つの層はエラーを出さずに食い違うことがあり、だからこそ直接の問い合わせは証拠の半分にすぎません。

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

最初のコマンドは有効な名前空間ポリシーを出力し、二番目はプライベートリゾルバーにアプリの名前を直接問い合わせます。直接の応答は経路とリゾルバーが機能することを証明しますが、アプリ自身の検索がそのサーバーを選んだことは証明しません。同じ名前の通常の検索や、アプリが受け取る応答と比較してください。

ユーザーが入力した名前についてシステムのリゾルバーを完全に迂回することがあるキャッシュやブラウザーレベルの安全なDNSも考慮してください。検索サフィックスも、短い名前を完全修飾名に展開するだけで、どのサーバーが応答するかとは関係がない別の紛らわしい手がかりです。

最後に再接続して通常の検索を繰り返し、通常の閲覧が承認済みのポリシーに従っていることを確認します。無関係な名前を解決するためにプライベートリゾルバーを公開のものに置き換えるのは修正ではなく、プライベートな問い合わせを本来行くべきでない場所へ静かに移します。