みなさんおはようございます。
今はやりの朝活で、6時40分頃からこの記事を書きだしました。
構想はありましたが、構成図や文章、検証もまだ行っておりませんので記事を書きながらこれらを並行しております。
果たして9時までに投稿できるでしょうか？
検証するに至った経緯
SC-400の勉強中に「Azure FirewallってDNSプロキシ使えるんだよ」という事を学び、またしてもAzure始まったなと思いました。
そこで公式ドキュメントを調べてみると、
ありました！
やっぱりAzure始まってますね。
素晴らしいです。
何が素晴らしいのか？
公式ドキュメントにある通りAzure Firewallの機能でDNSプロキシ機能が実装された、というのが「素晴らしい」になるわけですが、これの一体何が素晴らしいのか、をお判り頂くために、まずはAzure Private Endpoint、Azure DNS Private Zoneの仕様についてお判り頂く必要があるので説明します。
Azure Private Endpointとは？
Azure上のPaaSはPublic IP Address(以下Public IP、一般的にはグローバルIPアドレスとも言われている)で提供されているサービスです。
PaaSのリソースにアクセスするためにはPublic IP宛の通信を行う、つまりインターネット経由の通信になるという事です。
当然httpsでの暗号化通信がデフォルトで実装されており、かつ送信元Public IPを限定する機能などもほとんどのPaaSで実装されているのでセキュアなアクセスは可能なのですが、日本のお客様の場合、社内のデータをインターネット経由で保存するなど、けしからん！というセキュリティポリシーを持つことがほとんどなので、PaaSの利用が制限されてしまいます。
例えばAzure Filesのように5TBのSMB通信が可能なPaaSのマネージドストレージも、このセキュリティポリシーに阻まれて利用することができません。
そこで登場するのがAzure Private Endpointです。
これはPaaSリソースにAzure上の仮想ネットワーク内に切られたサブネット上のローカルIPアドレスを割り当てるサービスです。
Azure Private Endpointを使えばインターネットVPN接続や専用線接続された仮想ネットワーク内にPaaS宛の通信を閉じ込めることが可能になります。
比較で構成図を描きました。
通常のPaaSだと以下のようにセキュリティポリシーで禁止されたインターネット経由の通信となるところが
Azure Private Endpointを利用するとVPN接続内にパケットを閉じ込めることが可能になります。
これは便利ですね。
しかしこのAzure Private Endpointを利用するにも制限があり、これはAzure上の制限というよりもネットワークの仕様なのですが、当然PaaS宛の通信をPrivate IPに名前解決できなければなりません。
PaaSリソースが1つか2つくらいならオンプレミスのDNSに直接Aレコードを記載することも可能ですが、PaaSリソースを無数に使っている場合は大変手間で設定ミスの原因にもなります。
これではクラウドの利点を活かしきれません。
そこでこの名前解決そのものもAzureに任せてしまおうという発想になると思うのですが、これを実現するのがAzure DNS Private Zoneです。
Azure DNS Private Zoneとは
読んで字の如く、Azure DNS内にPrivate空間(≒ローカルIPアドレス)で名前解決できるZoneを作ってしまう、というサービスです。
蛇足かもしれませんが、このAzure DNS、なんとSLA100%です。
Azure、始まってますね。
しかしこの便利なAzure DNS、一つ制約があります。
Public Cloudの「公共性」と「セキュリティを担保する」という相反する条件を満たすためには致し方ないので「制約」と表現しました。
Azure DNSの制約とは？
Azure DNSもDNSサービスですので、その基本機構はDNS RequestとRequestに対するResponseです。
Azure DNSはDNSサーバに相当するので、クライアントからのDNS Requestを受け付けて、Requestに対してResponseを返すという動作ですね。
一般的なDNSの動作です。
ですがAzure DNSがRequestを受け付けるクライアントを制限しており、Azure内のリソースに限るという点です。
構成図でこの通信を描くとこうなります。
当然名前解決できないのでPaaSのPrivate IP宛(この構成図ではAzure Files)の通信も行われません。
そもそもパケットが生成されない、ということですね。
実際にパケットダンプを採って確認しても、名前解決でこけているのでパケットが生成されていません。
Azure Private Endpointを利用して思っている通りの通信ができない場合はこの点確認してみると良いかもしれません。
ポイントはパケットが生成されていない＝名前解決できていないという動作になります。
もう少し詳しく言及すると名前解決に失敗することにより宛先のIPアドレスが返ってこないのでパケット生成のしようがないということになります。
これはネットワークの仕様としては正常な動作となり、DNSでこけていることに他なりません。
考えられる解決策
以前の記事Azure Kubernetes Serviceにオンプレミスのローカル環境からアクセスしてみるでも記載しましたが、Azure上にDNSサーバを立てて、これで名前解決を行う、という方法が一般的ですし、Microsoftの推奨です。
構成図にするとこうなります。
まぁ一般的なDNS Proxyの構成ですね。
本記事の表題が[Azure FirewallのDNSプロキシ機能を試してみた]とあるように、この構成図内の[DNS Server]がAzure Firewallで代替できる、というのが主題です。
それでは実際に動作するか検証しましょう！
とここで時間となりました。
記事を書きたいがあまりに起きてから絶飲食で記載していたのでお腹も空きましたし今日はここまで。