Azure FirewallのDNSプロキシ機能を試してみた(前編 ～Azure Private EndpointとAzure DNS Private Zone～)

みなさんおはようございます。
今はやりの朝活で、6時40分頃からこの記事を書きだしました。
構想はありましたが、構成図や文章、検証もまだ行っておりませんので記事を書きながらこれらを並行しております。
果たして9時までに投稿できるでしょうか？

#検証するに至った経緯
[SC-400](https://docs.microsoft.com/ja-jp/learn/certifications/exams/sc-400)の勉強中に「Azure FirewallってDNSプロキシ使えるんだよ」という事を学び、またしても<font color="red">Azure始まったな</font>と思いました。
そこで[公式ドキュメント](https://azure.microsoft.com/ja-jp/blog/new-enhanced-dns-features-in-azure-firewall-now-generally-available/)を調べてみると、
![01_集中線.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/3d6344df-54d5-3785-6e00-3106f99699a1.png)
ありました！
やっぱり<font color="red">Azure始まってますね。</font>
素晴らしいです。

#何が<font color="red">素晴らしい</font>のか？
[公式ドキュメント](https://azure.microsoft.com/ja-jp/blog/new-enhanced-dns-features-in-azure-firewall-now-generally-available/)にある通りAzure Firewallの機能でDNSプロキシ機能が実装された、というのが<font color="red">「素晴らしい」</font>になるわけですが、これの一体何が素晴らしいのか、をお判り頂くために、まずはAzure Private Endpoint、Azure DNS Private Zoneの仕様についてお判り頂く必要があるので説明します。

#Azure Private Endpointとは？
Azure上のPaaSはPublic IP Address(以下Public IP、一般的にはグローバルIPアドレスとも言われている)で提供されているサービスです。
PaaSのリソースにアクセスするためにはPublic IP宛の通信を行う、つまり<font color="red">インターネット経由の通信になる</font>という事です。
当然httpsでの暗号化通信がデフォルトで実装されており、かつ送信元Public IPを限定する機能などもほとんどのPaaSで実装されているのでセキュアなアクセスは可能なのですが、日本のお客様の場合、<font color="red">社内のデータをインターネット経由で保存するなど、けしからん！</font>というセキュリティポリシーを持つことがほとんどなので、PaaSの利用が制限されてしまいます。
例えばAzure Filesのように5TBのSMB通信が可能なPaaSのマネージドストレージも、このセキュリティポリシーに阻まれて利用することができません。
そこで登場するのが<font color="red">Azure Private Endpoint</font>です。
これはPaaSリソースにAzure上の仮想ネットワーク内に切られたサブネット上の<font color="red">ローカルIPアドレス</font>を割り当てるサービスです。
Azure Private Endpointを使えばインターネットVPN接続や専用線接続された仮想ネットワーク内にPaaS宛の通信を閉じ込めることが可能になります。
比較で構成図を描きました。
通常のPaaSだと以下のようにセキュリティポリシーで禁止されたインターネット経由の通信となるところが
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/f7e2ae22-2849-2a54-0371-ffb94982211d.png)

Azure Private Endpointを利用するとVPN接続内にパケットを閉じ込めることが可能になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/1e8bb479-c249-d19f-f147-0db24937e661.png)
これは便利ですね。
しかしこのAzure Private Endpointを利用するにも制限があり、これはAzure上の制限というよりもネットワークの仕様なのですが、当然PaaS宛の通信をPrivate IPに<font color="red">名前解決</font>できなければなりません。
PaaSリソースが1つか2つくらいならオンプレミスのDNSに直接Aレコードを記載することも可能ですが、PaaSリソースを無数に使っている場合は大変手間で設定ミスの原因にもなります。
これではクラウドの利点を活かしきれません。
そこでこの<font color="red">名前解決そのものもAzureに任せてしまおう</font>という発想になると思うのですが、これを実現するのが<font color="red">Azure DNS Private Zone</font>です。

#Azure DNS Private Zoneとは
読んで字の如く、Azure DNS内にPrivate空間(≒ローカルIPアドレス)で名前解決できるZoneを作ってしまう、というサービスです。
蛇足かもしれませんが、このAzure DNS、なんとSLA100%です。
![02_集中線.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/43b9deac-6291-7e4d-2708-1c6d9113e1bb.png)
<font color="red">Azure、始まってますね。</font>
しかしこの便利なAzure DNS、一つ制約があります。
Public Cloudの「公共性」と「セキュリティを担保する」という相反する条件を満たすためには致し方ないので<font color="red">「制約」</font>と表現しました。

##Azure DNSの制約とは？
Azure DNSもDNSサービスですので、その基本機構はDNS RequestとRequestに対するResponseです。
Azure DNSはDNSサーバに相当するので、クライアントからのDNS Requestを受け付けて、Requestに対してResponseを返すという動作ですね。
一般的なDNSの動作です。
ですがAzure DNSがRequestを受け付けるクライアントを制限しており、<font color="red">Azure内のリソースに限る</font>という点です。
構成図でこの通信を描くとこうなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/8c590c4f-f03f-a758-5abe-bc5e6a0669a4.png)
当然名前解決できないのでPaaSのPrivate IP宛(この構成図ではAzure Files)の通信も行われません。
そもそもパケットが生成されない、ということですね。
実際にパケットダンプを採って確認しても、名前解決でこけているのでパケットが生成されていません。
Azure Private Endpointを利用して思っている通りの通信ができない場合はこの点確認してみると良いかもしれません。
ポイントは<font color="red">パケットが生成されていない＝名前解決できていない</font>という動作になります。
もう少し詳しく言及すると<font color="red">名前解決に失敗することにより宛先のIPアドレスが返ってこないのでパケット生成のしようがない</font>ということになります。
これはネットワークの仕様としては正常な動作となり、DNSでこけていることに他なりません。

##考えられる解決策
以前の記事[Azure Kubernetes Serviceにオンプレミスのローカル環境からアクセスしてみる](https://qiita.com/hidekko/items/732b9cac80fe695eb481)でも記載しましたが、Azure上にDNSサーバを立てて、これで名前解決を行う、という方法が一般的ですし、Microsoftの推奨です。
構成図にするとこうなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/37bf0257-acfe-5eda-5843-00bdae5399cd.png)
まぁ一般的なDNS Proxyの構成ですね。
本記事の表題が[Azure FirewallのDNSプロキシ機能を試してみた]とあるように、この構成図内の[DNS Server]がAzure Firewallで代替できる、というのが主題です。

#それでは実際に動作するか検証しましょう！

とここで時間となりました。
記事を書きたいがあまりに起きてから絶飲食で記載していたのでお腹も空きましたし今日はここまで。