Azure Private Endpoint を名前解決観点で詳細に説明してみた
TL;DR
- Azure Private Endpoint と DNS について、PC での名前解決観点で説明しておき隊
- Azure Private Endpoint を作成すると名前解決の結果がどう変わっていくのか、その原因と対策を説明する
- Azure Private Endpoint の理解が深まると嬉しい
はじめに
先日 アット東京 Cloud Lab でハッカソンみたいなのをやってたんですが、Azure Private Endpoint について、DNS とか hosts と組み合わせて説明するのが意外と大変だったので blog にまとめておこうという感じです。
FQDN だけじゃあ通信できない
今回、テスト用に vktgid3fj94pgykh6n28.blob.core.windows.net という Storage Account を作成しています。
この Storage Account と通信する際には、vktgid3fj94pgykh6n28.blob.core.windows.net という 文字列 (Fully Qualified Domain Name、FQDN) を使って通信するわけではなく、IP アドレスにする必要があります。
これには、名前解決 (Name Resolution) という仕組みで、FQDN から IP アドレスを取得します。
名前解決した結果の IP アドレスを確認するための手順はいくつかありますが、ここでは ping と nslookup を使って確認してみます。
ping の結果はこんな感じです。
PS C:\Users\ikko> ping vktgid3fj94pgykh6n28.blob.core.windows.net
Pinging blob.tyo23prdstr04c.store.core.windows.net [20.60.248.97] with 32 bytes of data:
右の方見て >>>>>>>> ^^^^^^^^^^^^ ここを見る
Control-C
nslookup の結果はこんな感じです。
PS C:\Users\ikko> nslookup vktgid3fj94pgykh6n28.blob.core.windows.net
Server: UnKnown
Address: 168.63.129.16 <<<<<<<< ここを見る
Non-authoritative answer:
Name: blob.tyo23prdstr04c.store.core.windows.net
Address: 20.60.248.97 <<<<<<<< ここを見る
Aliases: vktgid3fj94pgykh6n28.blob.core.windows.net
今回の Storage Account のパブリック IP アドレスが 20.60.248.97 であることが確認できました。
また、名前解決に使用した DNS サーバーは 168.63.129.16 です。
この IP アドレスは IP アドレス 168.63.129.16 とは に記載のある、特別な IP アドレスです。
ぱっと見た感じグローバル IP アドレスのように見えますが、あくまで Azure の基盤内部で利用されている IP アドレスです。
ARP とかあるじゃん
Azure Private Endpoint を作成後の名前解決の変化
次に、Azure Private Endpoint を作成してみます。
Azure portal から、以下のような標準的な設定とします。
- privatelink.blob.core.windows.net というプライベート DNS ゾーンを作成する
-
pingやnslookupを実行している Azure VM がある VNet に対して、仮想ネットワーク リンクが作成されている- Azure portal から、Azure Private Endpoint を作成する際に、プライベート DNS ゾーンを一緒に作成すると、暗黙的に仮想ネットワーク リンクが作成される
設定されている仮想ネットワーク リンクはここから確認できます。
Private DNS zone - Virtual network links
このような Azure Private Endpoint 作成後、ping や nslookup の結果は以下のとおりです。
PS C:\Users\ikko> ping vktgid3fj94pgykh6n28.blob.core.windows.net
Pinging vktgid3fj94pgykh6n28.privatelink.blob.core.windows.net [10.0.0.5] with 32 bytes of data:
右の方見て >>>>>>>> ^^^^^^^^ ここ
Control-C
PS C:\Users\ikko> nslookup vktgid3fj94pgykh6n28.blob.core.windows.net
Server: UnKnown
Address: 168.63.129.16 <<<<<<<< ここ
Non-authoritative answer:
Name: vktgid3fj94pgykh6n28.privatelink.blob.core.windows.net
Address: 10.0.0.5 <<<<<<<< ここ
Aliases: vktgid3fj94pgykh6n28.blob.core.windows.net
それぞれ、名前解決の結果が 10.0.0.5 に変化したことが分かります。
DNS サーバーに 168.63.129.16 を指定している際の名前解決の動き
Azure Private Endpoint を作成するときに Private DNS ゾーンを関連付けておくと、その Azure Private Endpoint に紐づいた IP アドレスのレコードが Private DNS ゾーンに登録されます。
今回だと、vktgid3fj94pgykh6n28.privatelink.blob.core.windows.net の A レコードは 10.0.0.5 だよ、というレコードが登録されています。
Private DNS zone - Recordsets
Storage Account の本来のエンドポイント URL である vktgid3fj94pgykh6n28.blob.core.windows.net ではなく vktgid3fj94pgykh6n28.privatelink.blob.core.windows.net なので少し注意してください。
これらの設定が組み合わさっているときにのみ、この動作になります。
繰り返しですが、1) 仮想ネットワーク リンクがある仮想ネットワーク から 2) 168.63.129.16 で名前解決をしたときのみ、Private DNS ゾーンに登録されたレコードを参考に応答が返される という動きになります。
Azure VM から 168.63.129.16 に対して名前解決要求が送られ、仮想ネットワーク リンクの設定されているプライベート DNS ゾーンの情報を参照しながら名前解決が行われ、その応答が返される、ということです。
もーっと詳細について知りたい方は
DNS サーバーに違うものを設定している場合の名前解決の動き
では次に、168.63.129.16 ではなく、適当に 8.8.8.8 を設定したうえで動作を確認してみます。
設定変更を反映させるため、Azure VM は一度再起動します。
Virtual network - DNS server
再起動後、ping や nslookup を実行してみます。
PS C:\Users\ikko> ping vktgid3fj94pgykh6n28.blob.core.windows.net
Pinging blob.tyo23prdstr04c.store.core.windows.net [20.60.248.97] with 32 bytes of data:
右の方見て >>>>>>>> ^^^^^^^^^^^^ ここ
Control-C
PS C:\Users\ikko> nslookup vktgid3fj94pgykh6n28.blob.core.windows.net
Server: dns.google
Address: 8.8.8.8 <<<<<<<< ここ
Non-authoritative answer:
Name: blob.tyo23prdstr04c.store.core.windows.net
Address: 20.60.248.97 <<<<<<<< ここ
Aliases: vktgid3fj94pgykh6n28.blob.core.windows.net
vktgid3fj94pgykh6n28.privatelink.blob.core.windows.net
ということで、元の状態に戻ってしまいました。
先ほど書いた条件のうち、2) 168.63.129.16 で名前解決をしたときのみ、を満たさなくなってしまったため、別の対応が必要です。
何で 168.63.129.16 から変更したのか疑問に思う方もいらっしゃるかもですが、本番環境で利用している場合には以下のようなケースで 168.63.129.16 を DNS サーバーとしていないケースが結構あります。
- Azure の内部において
- VNet の DNS サーバーとして AD サーバーが指定されている (AD のフォワーダーとして 168.63.129.16 が指定されている場合は別)
- Azure の外部において
- ExpressRoute などで閉域で接続されていたとしても、168.63.129.16 は Azure 内部からしか到達しない
- Azure 外部の PC やエンドポイントでは 168.63.129.16 以外の IP アドレスが設定されているため、プライベート DNS ゾーンの内容が参照されずに名前解決される
いくつかの解決方法
これらの問題、というか、Azure Private Endpoint として利用するための名前解決を実現するためには、いくつかの方法があります。
一般的には、少ない台数での PoC の場合には hosts で動作確認し、問題が無ければ AD サーバーの条件付きフォワーダーで実装、という順序になるかと思います。
hosts を使った解決方法
最初に、hosts ファイルを使った解決方法を紹介します。
Windows では C:\Windows\System32\drivers\etc\hosts が hosts ファイルなので、いったんデスクトップにコピーし、編集します。
# から始まるコメントの行の下に、以下のように追記します。
<snip>
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
10.0.0.5 vktgid3fj94pgykh6n28.blob.core.windows.net
保存し、C:\Windows\System32\drivers\etc\hosts を上書きし、ping や nslookup を実行してみます。
PS C:\Users\ikko> ping vktgid3fj94pgykh6n28.blob.core.windows.net
Pinging vktgid3fj94pgykh6n28.blob.core.windows.net [10.0.0.5] with 32 bytes of data:
右の方見て >>>>>>>> ^^^^^^^^ ここ
Control-C
PS C:\Users\ikko> nslookup vktgid3fj94pgykh6n28.blob.core.windows.net
Server: dns.google
Address: 8.8.8.8 <<<<<<<< ここ
Non-authoritative answer:
Name: blob.tyo23prdstr04c.store.core.windows.net
Address: 20.60.248.97 <<<<<<<< ここ
Aliases: vktgid3fj94pgykh6n28.blob.core.windows.net
vktgid3fj94pgykh6n28.privatelink.blob.core.windows.net
今までとは異なり、結果が一緒になりません。
これは、hosts が DNS サーバーへの問合せより優先されたためです。
一般的に DNS のトラブルシュートには nslookup を使用するかと思いますが、hosts を考慮した名前解決の動きを確認する際には (通信先が ping 応答しなかったとしても) ping を利用するのが効果的です。
この方法では、1 台の PC に対して影響を与えるため、PoC などでは有用ですが、社内インフラストラクチャー全体で適用するためには手間がかかりすぎます。
また、エンドユーザーに PC の管理者権限を与えていない場合には、hosts を編集することができません。
AD サーバーの条件付きフォワーダーを使った解決方法
AD サーバーを利用している場合には AD サーバー (に付随する DNS サーバー) の条件付きフォワーダーを設定することで、Azure Private Endpoint を考慮した名前解決が可能です。
こちらは AD サーバーでの設定変更となるため、エンドユーザーの PC での作業は不要です。
そのほかの解決方法
自分の書いたブログを紹介するにとどめますが、Windows Client OS で条件付きフォワーダー的なことをやってみる など、そのほかのやり方もあります。
proxy があるときの解決方法
proxy に hosts は効かない とか Re: proxy に hosts は効かない を見てください。
大企業だと proxy があることが多いので、別の考慮が必要です。
まとめ
Azure プライベート エンドポイントの DNS 統合 の焼き直しなような気もするんですが、自分として説明しやすい流れで記事を書いてみたという感じです。
Azure Private Endpoint の作成前後で、ping と nslookup の値がどう変わるか、また、hosts はどちらのコマンドに有効なのか、そこらへんを含めながら説明してみました。
Hub-spoke 構成などにおいては、プライベート DNS ゾーンをどのサブスクリプションで作成し、Azure Private Endpoint とどう関連付けていくのか、どう名前解決してくのかが結構悩みポイントです。
この記事をもとに動作の詳細を理解し、Azure Private Endpoint を含む名前解決の設計に活かしていただければ幸いです。
参考
- IP アドレス 168.63.129.16 とは
- Azure プライベート エンドポイントの DNS 統合
- Windows Client OS で条件付きフォワーダー的なことをやってみる
- proxy に hosts は効かない
- Re: proxy に hosts は効かない
- Azure Private Endpoint のための DNS 構成パターン
- Azure Storage Explorer – クラウド ストレージ管理
- PowerToysWindows 用の Hosts File Editor ユーティリティ
-
アット東京 Cloud Lab
ExpressRoute を使った検証が可能な環境 (部屋) を 1 日単位でお貸しいただける 神 みたいなサービスです！
-
dig の全てのコマンドラインオプションを一覧にしたシートを作成しました #dns
+noall +answerはこちらで知りました、便利！
Update log
- Hosts File Editor ユーティリティ についての内容を追加 - 2024/07/09
- スマートフォンで見たときに右の方に注目がいかないかもなのでテキストをちょっと追加 - 2024/07/09
- privatelink が含まれているゾーン名なのになんでうまくいくのかの詳細な説明を追加 - 2024/07/09
- Microsoft Hiyama-san の神記事を追加 - 2024/07/14
Discussion