Azure Application Gateway 強制トンネリング、プライベート構成

Application Gateway v2 で Private IP のみの構成と強制トンネリングの対応がパブリックプレビューとなりました。Application Gateway v1 では以前からプライベート IP アドレスのみの構成はサポートされておりました。また、強制トンネリングは v1/v2 共にサポートされておりませんでした。検証して留意点をまとめてみましたので、利用になる際は参考にしていただけたら幸いです。

利用シナリオ

• Public IP なしで Application Gateway を利用したい
• デフォルトルート (0.0.0.0/0) をオンプレまたは NVA に向けたい
• NSG で Inbound (GWM), Outbound (Internet) を拒否したい

検証の構成 その 1 (NSG で In/Out を拒否)

以下のようなシンプルな構成です。

検証手順

ドキュメントの手順で "EnableApplicationGatewayNetworkIsolation" のプレビュー登録を行い、20-30 分待てばポータルから通常の手順でデプロイができるようになります。

ポータルからデプロイを試みて、以下の様に "プライベート" のみを選択し、警告が出なければ利用可能な状態です。

ここで入力するフロントエンドの IP は以下の公開ドキュメントの推奨事項に従い、アドレス範囲内の末尾から割り当てます。
https://learn.microsoft.com/ja-jp/azure/application-gateway/configuration-infrastructure#size-of-the-subnet

今後のゲートウェイに使用する次のアドレスを決定し、フロントエンド IP 用に連続したアドレス指定のテーマを使用できるようにするには、定義済みのサブセット領域の上半分からフロントエンド IP アドレスを割り当てることを検討してください。 たとえば、サブネットのアドレス空間が 10.5.5.0/24 の場合、10.5.5.254 で始まるゲートウェイのプライベート フロントエンド IP 構成を設定し、今後のゲートウェイで 10.5.5.253、10.5.5.252、10.5.5.251 などが続くことを検討してください。

その他の項目はいつも通りの感じで適切に設定します。

Application Gateway 用のサブネットには以下のような NSG の規則を割り当てました。以下の最低要件となっております。

• Inbound
  • Azure LoadBalancer からの通信を許可する
  • クライアントからの通信のみを許可する
• Outbound
  • バックエンドのへの通信のみを許可する
    
    

確認結果

デプロイ後、Application Gateway 経由で EndtoEnd の SSL/TLS 通信ができるように構成変更します。リスナーの証明書は Let's Encrypt を利用。
構成変更後、クライアント VM から接続を試し、問題なくつながることを確認できました。

サポートされてないころは強制トンネリング環境などでログやメトリックが正しく取れないといった問題がありましたが、この構成でも問題なく情報が取れておりました。

検証の構成 その 2 (UDR でデフォルトルートを NVA にむける)

以下のようなシンプルな構成です。

確認結果

Application Gateway の NSG でアウトバウンドを一応許可しましたが、NSG の構成と同様で特に問題はありませんでした。

検証の構成 その 3 (NVA 経由で Application Gateway にアクセス)

以下のような構成です。NVA の public IP 宛ての通信は Application Gateway 宛てに DNAT し、Application Gateway からインターネット宛ての通信は NVA の Private IP アドレスで SNAT するようにします。(※後者はアウトバウンドの通信で Public IP アドレスとして SNAT するための要件です。)

確認結果

Application Gateway の NSG で送信元の Public IP からのインバウンドも許可する必要がありましたが、NSG の構成と同様で特に問題はありませんでした。
この構成のメリットとして、NVA でインバウンドを SNAT する必要がないので、送信元の IP アドレスをそのまま Application Gateway の ClientIP として利用することができます。

Application Gateway のアクセスログにも送信元の Public IP が記録されておりました。

留意点

以下のようなシナリオに該当する場合、Virtual Network NAT または仮想アプライアンスを利用して Public IP アドレス経由でアウトバウンドの通信ができるように構成する必要があります。

• プライベート エンドポイントまたはサービス エンドポイントを使用せずにキー コンテナーに通信する
  Application Gatewayに直接アップロードされた pfx ファイルは対象外です。

• インターネット経由のバックエンド ターゲットへの通信

• インターネットに接続する CRL または OCSP エンドポイントへの通信

特に 3 点目の CRL, OCSP はどういった構成が該当するかが不明でしたのでわかる範囲で以下にまとめてみました。

Application Gateway の CRL, OCSP について

CRL, OCSP は証明書の失効確認に利用されます。動作についてはこちらによくまとまっておりました。
https://qiita.com/kj1/items/dacc3f341c91f8196c75
https://www.infraexpert.com/study/sslserver13.html

CRL, OCSP はクライアント側で動作し、OCSP Stapling についてはサーバー側で動作しますが、Application Gateway の場合は L7 リバースプロキシですので、クライアント、サーバーどちらのパターンにも該当する可能性があります。
そのため、以下のような環境では証明書の失効確認のために CRL, OCSP 用のアウトバウンド通信を許可しておくことが望ましいでしょう。

• リスナーを https で構成し、公的機関が発行した証明書を利用している
• エンドツーエンドで SSL/TLS を構成しており、公的機関が発行した証明書を利用している

どちらを使うべきかは利用する証明書によっても異なります。また、両方利用できる場合、どちらか一方でも動作はすると考えられますが、両方通信できるようにしておくことが多いようです。

また、Application Gateway では OCSP もサポートされております。

Application Gateway では、OCSP と OCSP のステープリングはサポートされていますか。

はい。Application Gateway では、サーバー証明書のための OCSP 拡張機能と OCSP ステープリングを使用した証明書がサポートされています。

試しにこの環境でクライアント側でパケットキャプチャを取りながら、Web ブラウザで Application Gateway にアクセスしてみましたが、OCSP の Response があることも確認できました。

同時刻に NVA でパケットキャプチャをしてみましたが、以下の様に証明書の "Authority Info Access" に記載がある OCSP の URL に　Application Gateway からアクセスがあったことも確認できました。※ バックエンド側の証明書は AppService 証明書を使っておりますのでクライアントとの通信における OCSP Stapling による証明書の検証だと考えられます。

参考情報 : OCSP, CRL の URL の確認方法

以下の URL にあるように中間証明書、サーバー証明書の詳細から確認できます。
https://jp.globalsign.com/support/cert-management/crl-ocsp-url.html

制限事項

Pirvate Link 対応や共存環境等、いくつか制限がありますので事前にご確認ください。