みなさまおはようございます。
はやりの朝活第3回目です。
1回目は一昨日のAzure FirewallのDNSプロキシ機能を試してみた(前編 ～Azure Private EndpointとAzure DNS Private Zone～)こちらの記事です。
2回目は昨日のAzure FirewallのDNSプロキシ機能を試してみた(中編 ～Azure Firewall構築～)こちらの記事です。
今は7時15分、寝坊しました。今日こそ記事を書ききれるでしょうか？
#それでは実際に動作するか検証しましょう！
実は昨日のAzure FirewallのDNSプロキシ機能を試してみた(中編 ～Azure Firewall構築～)で殆どの構築は終わっています。
集中線をつけた設定値、[ファイアウォールポリシー]内の[DNS]の項目、こちらの以下のように設定します。
大事なのは最後の[DNS Proxy]を[enable]にする部分です。
これでAzure FirewallのDNSプロキシ機能が有効になりますので、最後に[Apply]をクリックします。
これにてAzure FirewallのDNSプロキシ設定は完了です。
続いて動作確認をしていきましょう。
#動作確認
Azure Private EndpointのリソースはAzure Storage ServiceのAzure Filesにしました。
Azure Private Endpointの設定方法や概念の説明は別の記事に譲るとし、接続、動作確認を行っていきます。
まずはAzure Files宛の通信がAzure FirewallのDNSプロキシ機能を利用していない状態、つまり通常の状態でPublic IPアドレスが返ってくるか確認します。
構築したAzure Filesはこちらです。
まぁ可もなく不可もなくって感じですね。
Public IPアドレスはAzure Portal上から確認する術はないので、Azure Private Endpointの設定がなされているか確認します。
##Private IPアドレス設定確認
該当のストレージアカウント内の[ネットワーク]をクリックし、[プライベートエンドポイント接続]のタブをクリックすると、接続の項目があります。
これがあればAzure Private Endpointの設定がされていることになります。
ここから更に[プライベート エンドポイント]の項目にある[pe-stadfdnstest01]をクリックします。
すると今度はプライベート エンドポイント接続の画面が開きますので[概要]画面内の[ターゲットサブリソース]が[file]になっていることを確認しつつ[DNSの構成]をクリックします。
Azure FilesにAzure Private Endpointの設定で割り当てられたNICの設定画面が出てきますので、割り振られているPrivate IPアドレスを確認します。
今回は[172.16.102.132]が割り当てられていますね。
続いてAzure FilesのエンドポイントURLも併せて確認します。
再度Azure Storage Account、今回のリソース名[stafdnstest01]の画面に戻り、[エンドポイント]の設定項目を開きます。
Azure FilesのエンドポイントURLは[https://(対象のStorage Account名).file.core.windows.net]になります。
ここまででAzure Portal側で確認できる設定は以上になります。
続いてオンプレミス側にある手元のWindows 10で確認作業を行います。
##オンプレミス側のWindows 10からのDNS確認
もうここからはわかりきった作業ですが、念のため画像を交えて確認します。
コマンドプロンプトを開いて先ほど調べたAzure Filesのエンドポイント宛にPingでも打ってみましょう。
はい。
正しくPublic IPアドレスが返ってきていますね。
想定通りの動作です。
Azure Filesのエンドポイント、Public IPアドレス宛にPingを打っても返ってこないのはAzureの標準仕様です。
##オンプレミス側のルーターの参照先DNSにAzure FirewallのPrivate IPアドレスを追加する。
弊社ではYAMAHA RTX1210を使っていますので、以下のような設定を追加します。
[dns server 172.16.102.4]の部分ですね。
昨日のAzure FirewallのDNSプロキシ機能を試してみた(中編 ～Azure Firewall構築～)を見返してみるとAzure FirewallのPrivate IPアドレスを確認していなかったのでこちらで捕捉します。
Azure Portalから該当のAzure Firewallを選択し、[概要画面]内の[ファイアウォールのプライベートIP]です。
まんまですね。
##再度オンプレミス側のWindows 10からのDNS確認
今度はPingではなくnslookupで確認します。
なぜ今度はICMPではなくnslookupなのかというと、Windowsの持つ[DNS Cache]という機能に惑わされないためです。
ICMP通信だとこのDSN Cacheを見てしまい、DNSを参照せずに名前解決を行ってしまう場合があります。
ですのでこういった標準機能に惑わされないためにもDNSサーバに直接名前解決を行うnslookupをここでは使います。
前半はDNSクエリが通っておらずタイムアウトしていますが、最後にちゃんと前の手順で調べたAzure Private Endpointで設定されたPrivate IPアドレスを返してくれています。
素晴らしいですね！
Azure、始まってますね！
これで今回の記事の本旨である、「Azure FirewallのDNSプロキシ機能」の基本的な確認は終わりなのですが、ついでなのでこのPrivate IPアドレスのままAzure FilesをWindows 10の一ディレクトリとしてネットワークマウントできるか確認します。
これができればAzure Filesという便利なPaaSをVPN内にパケットを閉じ込めて安全に利用することができます。
Azure FirewallのDNSプロキシ機能を試してみた(前編 ～Azure Private EndpointとAzure DNS Private Zone～)こちらの記事で書いていた
「社内のデータをインターネット経由で保存するなど、けしからん！」という意見に対する技術的回答になりますからね。
##Azure FilesがPrivate IPアドレスでマウントできるか確認する
再度Azure Portalに戻り、該当のAzure FilesのリソースからAzure Filesの共有ポイントを作成します。
[ファイル共有]から[+ファイル共有]のボタンをクリックし、適当に名前を付けて[作成]をクリックします。
デプロイが確認出来たら作成した共有ポイントの右端にある[･･･]をクリックし、[接続]をクリックします。(この機能便利なんですが探し辛いです・・・)
接続対象が[Windows]になっていることを確認し、ドライブ文字を任意で選択し、[認証方法]は[ストレージ アカウント キー]を選択します。
大きな赤枠内にPowerShellでマウントする用のコマンドを自動生成してくれるので、これをコピーします。
実はこの大きな赤枠内にストレージアカウントのストレージアカウントキーというアクセスパスワードが平文で書かれているので、これもQiitaにそのまま晒すのは良くないのですが、このリソースはAzure Firewallも含めて全て削除済みなので問題ないです。
読者のみなさまが業務でお使いになるときはくれぐれも注意が必要です。
それではPowerShellを実行しましょう。
PowerShellを管理者権限で開き、コマンドをコピーして実行たところ・・・
はい。
見てください。
素晴らしいですね！
ちゃんとPrivate IPアドレスで名前解決されています！
コマンドが正しく実行されると
こんな感じでZドライブでマウントされます。
エクスプローラーを開いて確認すると・・・
ちゃんとマウントされています！
完璧ですね！
素晴らしいですね！
Azure、始まってますね！
本日何回目かわからない、素晴らしいですね！、ですがホントに素晴らしいです。
三日にわたる本記事もこれにて無事書き終えました。
Azure Firewallが毎月10万円かかるのですが、機能的には申し分ないので、このDNSプロキシ機能もAzure Firewallの導入の一助になれば良いなと思います。
本日はここまで。