VPN接続によりDNSが間違ったDNSサーバーを使用する
私の会社のネットワーク（Active Directoryのメンバー）にWindows 7 PCがあります。お客様のサイトへのVPN接続を開くまで、すべてが正常に機能します。
接続すると、フォルダーリダイレクトポリシーが適用されている「アプリケーションデータ」などのディレクトリを含む、ネットワーク上の共有へのネットワークアクセスが失われます。ご想像のとおり、これはPCでの作業を非常に困難にします。デスクトップショートカットが機能しなくなると、「アプリケーションデータ」がその下からプルされるため、ソフトウェアが正しく機能しなくなります。
ネットワークはルーティングされ（10.58.5.0/24）、他のローカルサブネットは10.58.0.0/16のスコープ内に存在します。リモートネットワークは192.168.0.0/24にあります。
私は問題をDNS関連であるまで追跡しました。 VPNトンネルを開くとすぐに、all私のDNSトラフィックはリモートネットワークを経由します。これはローカルリソースの損失を説明しますが、私の質問はどのようにしてローカルDNSクエリを顧客ではなくローカルDNSサーバーに強制的に送ることができますか？
VPNに接続していない場合のipconfig /allの出力は次のとおりです。
Windows IP Configuration
Host Name . . . . . . . . . . . . : 7k5xy4j
Primary Dns Suffix . . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : mydomain.local
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : mydomain.local
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
Default Gateway . . . . . . . . . : 10.58.5.1
DHCP Server . . . . . . . . . . . : 10.58.3.32
DHCPv6 IAID . . . . . . . . . . . : 250629538
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA
DNS Servers . . . . . . . . . . . : 10.58.3.32
10.58.3.33
NetBIOS over Tcpip. . . . . . . . : Enabled
これは、VPNトンネルが接続されている場合の同じコマンドの出力です。
Windows IP Configuration
Host Name . . . . . . . . . . . . : 7k5xy4j
Primary Dns Suffix . . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : mydomain.local
PPP adapter Customer Domain:
Connection-specific DNS Suffix . : customerdomain.com
Description . . . . . . . . . . . : CustomerDomain
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.0.85(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 192.168.0.16
192.168.0.17
Primary WINS Server . . . . . . . : 192.168.0.17
NetBIOS over Tcpip. . . . . . . . : Disabled
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : mydomain.local
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
Default Gateway . . . . . . . . . : 10.58.5.1
DHCP Server . . . . . . . . . . . : 10.58.3.32
DHCPv6 IAID . . . . . . . . . . . : 250629538
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA
DNS Servers . . . . . . . . . . . : 10.58.3.32
10.58.3.33
NetBIOS over Tcpip. . . . . . . . : Enabled
ルーティングテーブル
ネットワーク宛先ネットマスクゲートウェイインターフェースメトリック
0.0.0.0 0.0.0.0 10.58.5.1 10.58.5.89 20
10.58.5.0 255.255.255.0 On-link 10.58.5.89 276
10.58.5.89 255.255.255.255 On-link 10.58.5.89 276
10.58.5.255 255.255.255.255 On-link 10.58.5.89 276
91.194.153.42 255.255.255.255 10.58.5.1 10.58.5.89 21
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 192.168.0.95 192.168.0.85 21
192.168.0.85 255.255.255.255 On-link 192.168.0.85 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.58.5.89 276
224.0.0.0 240.0.0.0 On-link 192.168.0.85 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.58.5.89 276
255.255.255.255 255.255.255.255 On-link 192.168.0.85 276
インターフェイスのバインド順序は次のとおりです。
リモートエンドでデフォルトゲートウェイを使用するようにVPNトンネルを構成していません。両方のネットワーク上のノードへのネットワーク通信は問題ありません。 （つまり、ネットワークまたはリモートネットワーク上の任意のノードにpingを実行できます）。
PPTP接続プロパティをDNSサーバー10.58.3.32に続いて192.168.0.16を使用するように変更しましたが、クエリはまだ192.168.0.16に送信されます。
編集：
消えるローカルリソースは、ドメインDFSルートでホストされます。これは、関連する場合とそうでない場合があります。
さらに編集：
これはドメインのDFSルートにのみ影響しているようです。サーバー名を使用して共有を参照する場合（つまり、\\server\shareではなく\\dfsroot\share）、共有にアクセスできます。
この答え に対する私のコメントのとおり、ドメインのDNS名をhostsファイルに追加すると、（DFS）ネットワークドライブが表示されなくなるのを防ぐことができますが、私の質問の大胆な部分（上記）誰かが何かアイデアを持っているかどうかを答えます。
OK、ここに素晴らしいリソースが見つかりました： http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/
完璧ではありませんが、うまくいくかもしれません。
バインドの順序は、レジストリの次の場所に格納されています：
HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind。リストには、ネットワークアダプターのすべてのデバイスGUIDとアクティブな接続がバインド優先順位で含まれています。レジストリキーを操作すると、次の事実が明らかになります。
レジストリ内のGUIDの順序を変更すると、VPN接続を含め、バインドの順序に影響します
- キーへの変更はすぐに有効になります
- VPN接続が完了すると、接続のGUIDが存在しない場合は、バインド順序の一番上に追加されます。
- VPN接続が閉じられると、接続のGUIDエントリが削除されます
- 接続に複数のGUIDエントリがある場合、接続が閉じられると1つだけが削除されます
このメカニズムにより、次の回避策の可能性が生まれます。
- Bindレジストリキーを調べる
- VPN接続に接続する
- Bindキーをもう一度確認し、リストの先頭に追加されたGUIDをコピーします
- GUIDエントリをリストの一番下に20回貼り付けます
- キーをエクスポートし、エクスポートしたファイルをクリーンアップして、バインドキーのみを含めます。
結果は、望ましい動作をサポートするキーです。 VPN接続が確立されるたびに、GUIDが存在するため、追加されません。GUIDが下部にあるため、DNS解決はクライアントに対してローカルで行われます。接続が切断されると、1つのGUID=エントリが削除されます。20のVPN接続の後、エクスポートされたレジストリファイルを使用してキーを再インポートできます。
もちろん、GUID）をさらに貼り付けて、キーを再インポートする頻度を減らすことができます。
また、ネットワークアダプターに変更があった場合は、この手順をやり直すことを忘れないでください。
VPNトンネルがローカルエリアインターフェイスよりも優先してDNSトラフィックをVPN DNSサーバーに転送しているようです（これらのサーバーにアクセスできる場合、または誰かがこの動作を確認できる場合は、これらのサーバーの要求を確認してこの動作を確認できます）君は）。
バインディングの順序が異なるため、完全に説明することはできません。これによると ここに投稿 （より高いスコアの回答を参照）これに関してWindowsは異なる認識を持っています。アダプタのバインド順ではなく、接続の速度に応じて優先度の高いチャネルを選択します。したがって、テストのために、この自動動作を変更するために次のことを試してください。1）ネットワーク接続に移動し、それぞれに対して行います。2）IP v4プロパティ3）詳細4）「自動メトリック」を無効にします。 VPN接続（PPP）での接続とメトリック2。これにより、リモートDNSよりもローカルDNSサーバーへのパスが優先されるようになります。
お役に立てれば！
述べたように、これはスプリットトンネリングの問題です。
3つの修正、＃2をお勧めします。VMwareWorkstation 8で優れたボックスを使用すると、簡単でパフォーマンスが向上するためです。
1-スプリットトンネリングを有効にします-安全ではなく、クライアント側での作業が必要になる場合があります。起こりそうにありません、ITセキュリティgestapoがあなたをシャットダウンします。
2-仮想デスクトップアプローチ-既存のデスクトップをP2VしてVMに変換します。 VMを使用してクライアントにVPN接続します。デスクトップを保持し、必要に応じてデスクトップに切り替えたり、デスクトップから切り離したりできます。
3-仮想サーバーアプローチ-既存のデスクトップをP2VしてVMに変換し、無料バージョンのESXiに配置します。デスクトップを維持し、必要に応じてコンソールからVMに切り替えることができます。これには時間がかかる場合があります...
残念ながら、Windows VPNは「Split-DNS」を実行できません。ただし、リモートサイトに接続した後、VPN接続からDNSサーバーを削除できます。
これを行うには、次のコマンドを発行します。
netsh interface ipv4 delete dnsservers name = "VPNの名前" address = all validate = no
VPNネットワークに接続するたびに、これを行う必要があります。
VPNトンネルは、クライアントとクライアントネットワークの間にあります。スプリットトンネリングを使用していないように思われます。これにより、トンネルが稼働している間、自分のネットワーク上のリソースにアクセスできなくなります。
したがって、ユーザー（またはクライアント）はスプリットトンネリングを有効にする必要があります。または、両方のネットワークに同時にアクセスするには、追加のネットワーク接続とカスタマイズされたルートテーブルが必要です。
私は数年前にこの問題を抱えていましたが、VPN接続ファイルを編集して修正しました.vpn.pbkファイル（Googleで見つけることができます）を作成して、メモ帳などのテキストエディターでそのファイルを開き、UseRasCredentials値をゼロに変更すると、問題は解決します。ただし、唯一の問題は、ローカルエリア接続のDNS優先順位がVPN DNSよりも高くなり、名前解決に時間がかかることです（インターネットへの接続にVPNが使用されている場合）。
クライアントVPN構成からこのオプションを削除するだけです
setenv opt block-outside-dns
問題を解決しました
この質問は長い間尋ねられましたが、これは他の人を助ける可能性があるため、この回答を投稿しました。私はVPNで同じ問題を抱えていましたが、ユーザーがリモートVPNに接続するときに、外部DNSが停止していたことがありました。 google.comsplit-dnsに記載されていた、以前は機能していた会社のドメインのみが機能していました。
問題は、使用されたローカルマシンがDNSクエリトラフィックをVPNトンネルに送信し、DNSがトンネルで許可されている場合、フォールバックすることでした。フォールバック時には、最初にipv6を解像度として選択し、その後ipv4に戻ることはありませんでした。
結果をテストするために、最初にローカルマシンのipv6を無効にして、動作を開始しました。すべてのユーザーに対して永続的に修正するために、VPNプールで設定されていない場合にIPv6を無視するASAファイアウォールでclient-bypass-protocolコマンドを有効にしました。
したがって、ファイアウォールを制御できず、スプリットトンネルとスプリットDNSが適切に配置されていることを確認できても、失敗する場合は、ローカルマシンでipv6を無効にしてみてください。リモートネットワークではipv6を使用しないため。
これは私を助けました、これが他の人を助けることを願っています:)
何か経験したことある！
ローカルDNSサーバーとのVPN接続を設定し、nslookupを使用してVPNに接続し、VPNドメイン名を照会します。 VPN LANに対してローカルなIPで応答が返されるはずです。これは、VPN DNSサーバーを使用してクエリを解決したことを意味します。
次に、LAN接続を開き、手動でDNSをローカルまたはISP DNSに設定します。ボリア!!!矢印キーを使用して、nslookupクエリを繰り返します。ローカル/ ISP DNSサーバーを使用してVPNドメインのクエリを解決したことを意味するパブリックIPを受け取ります。バム！