🎉

Azure FirewallのVnet間ハブ＆スポーク構成で色々な接続パターンを試してみた

2023/10/10に公開

Azure

ハブ&スポーク手順

構成図

確認したいこと

ハブ&スポーク構成でのVnet間通信において、Firewallのルールは必要になるのか
プライベートエンドポイントも同じ構成で接続実現できるのか。(NFSマウント）
ストレージアカウントへのアクセスはsourceはどのIPになるのか？（パブリック・プライベート？）

Firewallのルールは必要になるのか？

確認観点は以下の２つ。主にVM間の通信を確認。

ブラウザアクセス(HTTP通信）

結論、Firewallのルールは必要。
ルールが無い状態で画面アクセスをすると、No match ruleのようなエラーが出てしまう。
アプリケーション規則に以下を追加したところ、IISサーバ側の画面が表示されるようになった。

TIPS
宛先がIPの時でも、HTTP/HTTPSアクセスの時にはアプリケーションルールの方が正しく動く。
IPだからネットワークルールかと思い、tcp:80で追加したがうまく動作しなかった。
→ 後から再度確認したら、アプリケーションルールでなくても動作した。反映がうまくいっていなかったのだろうか？

RDP

同じくルールが必要。ルールが無い状態だと認証画面に到達しない。
ネットワーク規則に以下を追加したところ、RDP認証画面まで到達した。

プライベートエンドポイントも同じ構成で接続実現できるのか。

確認観点はAzure Filesへのマウントを実施する。
結論、Firewallのルールは必要。ルールが無い状態でマウントコマンドを実行すると、やはりAccess Deniedが出てしまう。
ネットワークルールに以下を追加したところ、マウントが問題なくできるようになった。

プライベートエンドポイントのIPアドレスを直に開けてみた時。
マウント成功画面。（IP指定でマウントを実施。緑ハイライトなのでマウント成功。）
FQDNベースだと反応なしで失敗。この後、Conectioned Timed outが出た。
FQDNで開けてみたとき
結論、ルールの追加は不要！
ただし、Firewallと接続元VMのVnetにおいて、仮想ネットワークリンクが必要になる。
https://learn.microsoft.com/ja-jp/azure/private-link/tutorial-inspect-traffic-azure-firewall#link-the-virtual-networks-to-the-private-dns-zone

仮想ネットワークリンクを両Vnetに張るのは、最終的には接続元のVnetでの名前解決が必要になるということなのだろう。一方で、FQDNの穴あけが必要ないのはなぜなのだろうか…最終的には解決されたIPアドレスでアクセスするかということか？サポートにも確認してみたいところ。ちなみに先で開けていたIPベースもネットワークリンクを張ることでルール自体不要になった…

ネットワークルールでFQDNを指定するときには、DNSプロキシの有効化が求められる。DNSプロキシとは簡単に言うと、クライアント仮想マシンから DNS サーバーへの DNS 要求の仲介役である。

Azure内部通信（ex.ストレージアカウントへのアクセス)を行う際のsourceはどのIPになるのか？（パブリック・プライベート？）

Azure CLIでBlobのオブジェクトをダウンロードしてくる。

Firewallのルールは必要。
対象は以下の記事＋接続先のBlob(ストアカ名.blob.core.windows.net）が必要。
まずはこの状態で、ストレージアカウント側のIP制限は掛けない状態で、Blobのアップロードが可能になった。
ストレージアカウント側での制限をかけたいとき
穴あけとしては、接続元のVnetを指定するのみでよく、Azure FirewallのパブリックIPを開けるのは不要だった。逆に、Azure FirewallのパブリックIPだけを開けた場合は、IP制限にかかって接続できなかった。
Azure内での通信の場合は、インターネットには出ないからというのが理由なのだろうか。サポートにも確認をしてみたい。（おそらく、以下の注意事項が理由かとは推測）

(2023/10/23追記）
サポートへの確認結果をまとめると以下の通り。

同じリージョンの時にはプライベートでのアクセスになる。そのためパブリックIPの穴あけは不要。プライベートで通信が来るときには、MSのDC内でのSNATになり固定では無いため、いわゆるストレージアカウントのIP規則での追加ではなく、仮想ネットワーク規則での追加を行うしか方法はないとのこと。
接続元のVnetのみでよかったのは、サービスエンドポイントが有効になるためである。有効なルートに、ストレージ向けのルートが追加されるため、Firewallを経由しなくなるのが理由である。実際の接続元としてはVMになる。ただし、CLIでの通信の場合はストレージアカウントのエンドポイント以外の通信が発生するため、そのルールはFirewallに登録が必要。
Firewall を接続元としたいときには、Firewallサブネットにてサービスエンドポイントを有効化する必要がある。
Firewallを接続元にする時には、VM→Firewallの経路になり、Firewallのルールで一度宛先のフィルタリングがされることになる。接続元がVMの時とは違うのは、Blobエンドポイントへのルールは追加が必要になる点である。あくまでサービスエンドポイントは、NW経路の話のため、フィルタリングの結果として通信して問題なければサービスエンドポイントによってMSバックボーンNWを通ったアクセスになる。

リクエスト元の解釈が必要な気がしたので、以下のパターンで試してみた。

IP制限をAzreuFirewallSubnetのみにした場合
　→ できない！
IP制限をFirewall配下のVMサブネットのみにした場合
　→ Blobアクセス可能

上記より、実際の接続元のVnetで穴をあけるのが良い。あくまでFirewallはハブ的な役割でリクエストの転送を行うのみで、実際のリクエスト元としてはVMサブネットで認識をされるのだろうか。

javaベースでダウンロードを実施する。

javaのプログラムを作成して同じようにアクセスを行った。
CLIと同じルールでBlobのダウンロードが確認できた。追加のルールは不要である。Javaの場合もAzureでよしなにマネージドIDでの認証を行ってくれる。マネージドIDがアタッチされていない状態だと認証エラーが発生した。

参考手順
https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-blob-download-java

まとめ

Azure Firewallを介したVnet間通信であっても、Firewallのルールは必要になる。Azure内部通信だからと言って不要というわけではない。

MS手順との変更箇所

Vnet間の通信だけを試したいのであれば、ゲートウェイリソースは不要。
Vnetピアリングをする際には、<ハブVnet> からのトラフィック転送の受信を<スポークVnet>に許可するのチェックを入れること。これを入れることで、スポーク間の通信が可能になる。

全体TIPS

Managed IDをAzureリソースに付与している場合は、az login --identityでログインが非対話式のログインが可能
az コマンドは、--debug をつけることでデバッグ動作が可能になる。

おまけ

Azure Firewallのドキュメントを見ていたところ、以下の記述があり実態を確認してみた。

Azure Firewall は、パブリック IP アドレスへのすべての送信トラフィックに対して SNAT 機能を提供します。既定では、宛先の IP アドレスが IANA RFC 1918 のプライベート IP アドレスの範囲または IANA RFC 6598 の共有アドレススペースに含まれているときは、Azure Firewall でネットワークルールによる SNAT を行いません。アプリケーションルールには、宛先 IP アドレスに関係なく、透過プロキシを使用して常に SNAT が適用されます。

細かい設定は割愛して実際の動確結果だけ記載する。

ネットワークルールの場合

Azure Firewallを経由して、VMからVMへのRDPを行う。また、Firewallのルールは入れたままである。

NSG設定	結果
FirewallのプライベートIP(/32)だけ許可	NG
VMのIP(/32)だけ許可	OK

RDPはAzure Firewallとしてはネットワークルールであり、SNATされないという記述が正しいことがわかる。当然だが、Firewallのルールを削除するとRDP自体不可である。

アプリケーションルールの場合

Azure Firewallを経由して、IISサーバへのHTTPブラウジングを行う。

NSG設定	結果
FirewallサブネットのIPレンジだけ許可	OK
FirewallのプライベートIP(/32)だけ許可	NG
FirewallのパブリックIP(/32)だけ許可	NG
VMのIP(/32)だけ許可	NG

SNAT によって AzureFirewallSubnet のいずれかのファイアウォールプライベート IP アドレスに変換され…

という記述が関係していると推測している。

NGの場合は、以下の画面が出る。

FirewallのプライベートIPが、10.0.2.4なのでFirewallサブネットのいずれかのIPでSNATされるようである。