こんにちはやまぱんです。
今回は Azure にP2S VPN接続したときに既定のDNSサーバーが 168.63.129.16 になるという事象がおきました。
今回は Azure に関係しますが、Windows 要素が強いのでこちらで記載します、Azure 関係は普段はこちらのqiita に書いてます。
事象
Azure 上の環境 (Vnet-Hub / 10.100.0.0/24) に P2S VPN で手元の端末から Azure につなぎました(疎通確認済)。
下記のようにVPN接続の10.200.0.9のIPアドレスとルート情報が降っていることが分かります。
-
ipconfig の結果
cmd で下記のコマンドを実行します。ipconfig
- route print の結果
cmd で下記のコマンドを実行します。route print
その接続先の Azure 環境には IaaS VM (Windows Server)で立てたDNSサーバー(10.100.1.5)があり、そのDNSサーバーを参照して名前解決をするようにしようとしました。
P2S VPN をつないだところ、nslookup した時の既定のサーバーが 168.63.129.16 となってました。
このアドレス 168.63.129.16 はWire Serverと呼ばれており、 Azure 上のVMを作ったと時の既定のDNSサーバ(他にも役割はありますが割愛します)となっています。
一方で Azure 上のネットワーク以外からはアクセスすることができません。なので、手元の環境(オンプレ環境)からは直接通信することができませんので、この Wire Server (168.63.129.16) を使って名前解決をすることはできません。実際に失敗します。
なので、オンプレ環境の規定のDNSサーバがこうなるのは気持ちいなと思ていました。
この状態だと nslookup での名前解決は何も通りません。
しかし、ブラウザだとインターネットにアクセスできます。
つまりどこかで名前解決はされている。
やったこと
インターネットにつながってる物理NIC(Wi-Fi2)のDNSサーバーを確認し、何も値が入っていないことを確認します。
念のためIaaS VM DNSサーバー(10.100.1.5)を入力しましたが、それでも下記の結果はかわりません。
もちろん名前解決は失敗します。
原因
VPNをつないだ時のDNSの設定はまた別にありました。
Windows 環境の DNSの設定を確認する
- netsh interface ip show config の結果を確認する
cmd で下記のコマンドを実行します。netsh interface ip show config上記の結果の抜粋の画面ショットです
ここで VPN の NIC Vnet-Hub の欄で 168.63.129.16 の値を見つけることができました。そのメトリックの値は25
またみたところ、普段つかっているインターネットにつながってる物理NIC(Wi-Fi2)の方はDHCPで8.8.8.8が振ってきていることもわかります。そのメトリックの値は35
ここで、メトリックは小さい値が優先されることが分かります。
→ つまり、メトリックの小さいほうのDNSサーバーの宛先設定を変える(またはメトリックの値を変える)ことで nslookup 既定のDNSとして利用できることが推測されます。
VPN の NIC の設定を変更する
今回はメトリックの値は変えずにDNSサーバーの宛先設定を設定します。
VPN で検索して下記の画面にいって設定します。
下記のように設定します。(設定先は Azure 上のIaaS VM DNSサーバー(10.100.1.5))
そうすれば下記のメッセージがでるので一度VPNを切断し、再度接続します。
確認
nslookup して既定のDNSサーバーとして Azure 上のIaaS VM DNSサーバー(10.100.1.5) が使われていることがわかります
まとめ
- Windows の DNS 設定はNICごとにある
- 複数の DNS がそれぞれのNICに設定されているときはメトリックの値の小さい方が既定の DNS として優先される
参考
・Windowsで2つ(複数)のNICにDNSを設定した場合の動作について
https://turningp.jp/server-client/windows/dns-multiple
・Wire Server/ 168.63.129.16 について
https://learn.microsoft.com/ja-jp/azure/virtual-network/what-is-ip-address-168-63-129-16