Windows で OpenConnect の DNS 設定を実際に適用するのは誰か
Windows はリゾルバーの状態を三か所に保持します。アダプターの DNS を手作業で編集したり名前空間ルールを追加したりする前に、接続を所有するヘルパーを見つけてください。
トンネルを立ち上げることは、その DNS 値をインストールすることと同じではありません。OpenConnect はネゴシエートし、Windows 側のヘルパーが適用します。この二つの手順の間の隙間が、このクライアントでのプライベート名の失敗のほとんどを説明しますが、ヘルパーは Windows の VPN 設定ページであることはほとんどありません。
ゲートウェイが提示したものと Windows がインストールしたものを分ける
クライアントは接続データをスクリプトインターフェースに渡し、Unix 版と Windows 版は別々のプログラムです。Windows では実装は通常 JavaScript ヘルパーで、内部 DNS サーバーや内部ドメインといった変数を読み取ってからアダプターに触れます。トンネル自体はリゾルバーの状態を書き込みません。
この分離が重要なのは、値がネゴシエーションの中に存在してもアダプターに届かないことがあるからです。欠けている、途中で失敗する、あるいは GUI ラッパーに同梱された古いコピーであるヘルパーは、Windows をまったく元のままにします。セッションは接続済みに見え、プライベート名は今もローカルプロバイダー経由で解決され、クライアント画面には違いを示すものは何もありません。どの段階で壊れたかを知る唯一の確実な方法は、ヘルパー自身の出力を読むことです。
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI ラッパーがクライアントとヘルパーの独自コピーを同梱することがあるため、ディスク上の別の場所にある二つ目の openconnect.exe は何の証明にもなりません。構成を判断する前に、セッションを開始した実行ファイルを見つけてください。
リゾルバーの状態を変更せずに読む
読み取り専用の三つのクエリでよくある混乱をカバーでき、それぞれが別の問いに答えます：
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveアダプターレベルのサーバーが、多くの人が VPN DNS と呼ぶものです。接続固有のサフィックスは、短い名前がそもそも展開されるかどうかを決めます。名前空間ポリシーの一覧は、アダプターの順序に関係なく一致する名前に適用されます、また、ヘルパーがそもそも作成するつもりがなかった場合、そこが空でも不具合ではありません。編集前に三つすべてを読むことが、症状を別の場所へ移すだけの修正を防ぎます。
完全修飾名から始めます。FQDN が解決して短い名前が解決しないなら、隙間はサーバーアドレスではなくサフィックスか検索リストです。
二番目の手順として、すでにインストールされている任意のリゾルバーツールで目的のサーバーに直接問い合わせます。直接の応答は、サーバーに到達できそのゾーンに対して権限があることを証明します。アプリケーションが既定でどのサーバーに問い合わせるかは何も証明しません。
接続を所有するコンポーネントに名前を付ける
よくある構成は二つです。ターミナルから起動したクライアントはスクリプトのパスを明示的に渡すため、所有者は実行されたコマンドに現れます。パッケージ化されたアプリケーションはクライアントを代わりに起動し、ヘルパーを自身のディレクトリ内に保持するので、いつ変わるかはベンダーが決めます。
何かを入れ替える前に、インストール間でヘルパーのバージョンを比較してください。ファイル名が見慣れているという理由でミラーから取得したヘルパーを昇格した権限で実行すると、DNS の隙間がセキュリティインシデントに変わります。
所有者がわかれば、修復対象は明らかです。ランチャー内のサポートされたスクリプトパス、パッケージの更新、またはゲートウェイ上の修正済みプロファイルであり、どれもアダプターのプロパティを手作業で編集する必要はありません。
修復するのは所有者であり、アダプターではない
アダプターに手作業で設定した DNS は切断後も残ることが多く、そのため機能しているように見えて次のネットワークで問題を起こします。すべてのインターフェースにボルトで固定したパブリックリゾルバーは、プライベート名前空間の問題を解決するのではなく隠します。ヘルパーが DNS 値を一度も受け取っていないなら、見るべきはゲートウェイのプロファイルです。受け取ったのにアダプターがまだ古いサーバーを示しているなら、ヘルパーは接続中に失敗しており、クライアントログは通常トンネル設定の行の近くにそれを記録します。
サポートされた経路で状態を再構築し、その後、接続してプライベート FQDN を解決し、サービスを開き、切断し、アダプターが以前のサーバーに戻ったことを確認する一サイクル全体を検証します。
実際に失敗しているアプリケーションを確認する
独自の暗号化 DNS 設定を持つブラウザーは上記すべてを無視し、パブリックリゾルバーから答え続けます。トンネルが上がる前の否定応答をキャッシュしているアプリケーションも同じように振る舞います。リゾルバーアドレスを再び変更する前に、同じマシン上の単純なシステムクエリと比較してください。
システムクエリが正しくアプリケーションが誤っているなら、残る不具合はそのアプリケーションの DNS 設定の中にあり、VPN の経路にはありません。