ダイヤルイン後にサーバー名がVPNアドレスに解決される理由

オフィスのファイルサーバーは午前中ずっとLANアドレスで応答していましたが、その後リモートユーザーがダイヤルインすると、名前は代わりにトンネルアドレスへ解決され始めました。DNSを手で編集したわけではなく、これが手がかりです。レコードはマシン自身が公開したのです。三つの条件が、レジストラ、レコード、クライアントの見え方のどれを直すかを決め、順序を間違えると次の接続後にレコードが戻ります。

二つのアドレス、一つの名前、三つの条件

マルチホームのWindowsサーバーは、LANアドレス、一つ以上のダイヤルインアドレス、場合によっては二枚目のネットワークカードを持てます。各インターフェースは、動的登録が許可されていれば自分のアドレスをDNSに登録できます。PPPアダプターが登録すると、同じホスト名にトンネルの相手だけが到達できるアドレスが加わり、LANのクライアントはそれを有効な応答として受け取ります。

三つの条件が修復を決めます。第一に、追加のアドレスはそれを受け取るクライアントから到達できるか。第二に、その登録にまだ依存している利用者はいるか。第三に、レコードは動的で戻り得るのか、静的で意図的な登録なのか。

何かに触れる前にこれらへ答えてください。アドレスが問い合わせ元のネットワークから到達できないなら、クライアントのキャッシュを消しても長くは直りません。トンネルの相手自身が使う管理経路など、何かがそれに依存しているなら、削除すると代わりにその経路が壊れます。そして公開元に対処せずに消した動的レコードは、次の登録イベントで再び現れます。

レジストラを変える前にレコードを読む

問題を報告しているネットワークから正確な完全修飾名を問い合わせ、その応答をサーバーの実際のインターフェースとリスナーと比べます。一つの名前が複数のアドレスを返すのは正常で、問題はそれぞれが受け取るクライアントにとって使えるかどうかです。

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

最初の問い合わせはローカルのリゾルバーを使い、二番目は特定のDNSサーバーに直接尋ね、三番目はWindowsのPowerShellから同じことをします。これらを比べると、古いクライアントキャッシュと権威ある応答を切り分けられます。直接の問い合わせがすでにトンネルアドレスを返すなら、問題はローカルのキャッシュではなく公開されたデータです。

レコードのタイムスタンプと、DNSコンソールがそれを動的と表示するかを書き留めます。その一つの属性が、上の三つの条件のどれが当てはまるかを教え、五分の掃除と長持ちする修復の違いになります。

公開元を直すかレコードを直すか、どちらかを知る

レコードが動的で不要なら、恒久的な修正はそのインターフェースに登録させないことです。Windowsはインターフェースごとの登録設定を公開し、DNSクライアントサービスは次の接続やアドレス変更で再び公開します。ダイヤルインアダプターの登録を切ってもLANアダプターの登録はそのまま残り、通常はそれが望ましい形です。

マシン全体に効くスイッチには注意してください。動的更新を無効にするグローバル設定は、そのホストのすべてのインターフェースに影響し、他のクライアントが登録に頼っているものも含まれます。ドメインコントローラーでは同じ注意がより強く当てはまり、ホストがクライアントのログオンに必要なサービス位置レコードも持つことがあります。

レコードが静的なら、意図して置かれたものであり、話し合う相手はそれを置いた人です。今日不便だからという理由で静的レコードを消すと、それが存在する理由の唯一の証拠が失われます。どちらの場合も、公開元に対処した後にだけ古い応答を消し、何を変えたかを記録して、次の人が意図的な登録と事故を区別できるようにします。

失敗したクライアントネットワークから検証する

検証は症状を報告したネットワークで行うもので、サーバー側ではありません。クライアントのリゾルバーキャッシュをサポートされた方法で消し、元の問い合わせと名前による元のサービス接続を繰り返します。

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

最初のコマンドはWindowsのリゾルバーキャッシュを消し、二番目は名前が再びキャッシュされたか、どのアドレスが保存されたかを示します。サーバーから自分自身への接続が成功してもLANのクライアントについては何も証明せず、不要なアドレスへの経路を外してもDNSが公開する内容は直りません。

最後に、以前アドレスを持ち込んだ出来事を繰り返します。VPNクライアントを再接続するか、ダイヤルインセッションを更新します。そのライフサイクルの変化の後で、公開された名前をもう一度確認します。次の接続までしか持たない修復は掃除であって修正ではなく、どちらを行ったかを知ることが、チケットを閉じることと来週また開くことの違いです。