normalian blog

Let's talk about Microsoft Azure, ASP.NET and Java!

Azure Firewall の DNS Proxy 機能を利用して、Azure 外部の環境から Azure Private DNS を利用する

DNS サーバを利用した名前解決のうち、オンプレミス・パブリッククラウドを組み合わせた複数環境における閉域網での名前解決は特に複雑化することが多いです。Azure 環境の場合は Azure Public DNS や Azure Private DNS と呼ばれる機能がありますが、閉域網向けで利用される Azure Private DNS はオンプレミスや他プラットフォームからの名前解決ができないという課題があります。昨今では Azure DNS Private Resolver 機能もリリースされましたが、2022年7月時点ではプレビューなことに加え、現時点では Japan East/Japan West ともに利用できません。
docs.microsoft.com
Azure バックボーンネットワークを信じてアメリカ側のリージョンと日本側のリージョンをつなぎ、そちらで Azure DNS Private Resolver を使うという手もありますが、そもそも閉域網を非機能要件等で要求されている時点で高いレベルのコンプライアンスに沿う必要があり、日本国外のリージョンを使うということが厳しいことが多いというのが実態でしょう。

そんな以下の

  • 日本のリージョンだけで閉じたい
  • PaaS サービスだけで DNS を構築したい
  • オンプレや別の環境からでも名前解決をしたい

「ダイエットしたいけど甘いものが食べたい思春期さん」な要件を満たす場合、現時点では Azure FirewallDNS Proxy 機能が有効です(Azure DNS Private Resolver を待てというのは現時点では不問でお願いいたします)。
docs.microsoft.com

今回のアーキテクチャ図としては以下になります。外部環境としては GCP を想定していますが、これは別環境がオンプレミスや AWS であったとしても同様となります。こちらの Azure と GCP 間における VPN 接続は以前に記載した Azure と GCP を HA 構成の BGP VPN で接続する - normalian blog の記事を参照下さい。

上記のアーキテクチャで利用した Azure の各コンポーネント構成としては以下になります。

  • Application Gateway を配置した VNET を作成する
  • VPN で Azure と GCP 接続する
  • Azure Private DNS を VNET に接続する
  • Azure Private DNS に対し、Application Gateway の Private IP レコードを登録
  • 当該 VNET に Azure Firewall を配置し、DNS Proxy を有効化する

Azure FirewallDNS Proxy を利用する設定自体は非常に単純で、Azure Firewall 側の DNSメニューから DNS Proxy 設定を有効化するだけです。

上記に加えて参照する先の DNS サーバを「DNS Servers」のところで個別に IP 等で設定することも可能ですが、Default を指定することで Azure VNET が標準で参照する DNS 先、すなわち設定済の Azure Private DNS を見に行くことになります。

実際の動作例

では GCP 側の VM から Azure Private DNS に登録されている Application Gateway の Private IP を参照してみましょう。先述した通り、Azure Private DNS には既に Application Gateway の Private IP が登録済であり、VNET側に関連付けがなされているものとします。加えて、Azure Firewall 自体の Private IP は 172.19.100.4 として設定済です。

GCP 側の VM は特に DNS サーバの設定等はしていないまっさらな状態として構築し、そこで以下のコマンドを実行例しました。

特に何もせずに nslookup を実行しても Azure Firewall 側に名前解決をしに行かないので当然名前解決に失敗してますが、二回目は Azure Firewall の Private IP を DNS サーバとして指定することにより、無事に名前解決に成功しています。

Azure と GCP を HA 構成の BGP VPN で接続する

昨今のシステム構築時は複数のプラットフォームを活用することが多いと思います。最も多いケースは特定のパブリッククラウド(Azure 等)とオンプレミスとの組み合わせだと思いますが、異なるパブリッククラウドAWS, GCP 等)と接続して利用するケースも必要になると思います。コンプライアンス等によってはすべてをオンプレミス側のルータを起点・経由して異なるプラットフォームに接続することもあると思いますが、あるパブリッククラウドの特定機能を使いたいがために VPN で直接接続したいケースもあります。私が今回試したケースは「別プラットフォームから Azure にアクセスした場合の環境を作りたいな」と思い、出来心で試してみました。GCP から AWS や Azure に VPN 接続する記事としてはトップゲートさんが公開している記事が懇切丁寧に解説してくれているので、非常に参考になります。
www.topgate.co.jp
こちらをそのまま参考にしても良いと思うのですが、同記事は GCP 側で利用しているコンポーネントが Classic VPN となり、本番環境で利用したいであろう 高可用性(HA)VPN になっていないので、こちらを利用した際に Azure 側も含めてどの様に設定するかのポイントを記載したいと思います。
まず、アーキテクチャ図としては以下になります。太字でそれぞれ Azure/GCP でどの様なリソースを追加しなければならないかを明示しました。一点注意が必要なのが、Azure 側の BGP Routers は Virtual Network Gateway 設定の一部となっていますが、対比のためには明記した方が良いと思い記載しております。

ルーティングとして BGP を利用するので、クラウド間で互いに AS 番号を指定して BGP ルータの設定をしています。こちらに加えて VPN Gateway の Public IP や BGP Router の IP を Azure/GCP で互いに設定します。先述した通り「高可用性(HA)VPN 」を実現するためにコンポーネントの数が増えており、混乱しやすいのではと思うので本記事が理解の手助けになれば幸いです。

Azure/GCP で作成するコンポーネント

今回のケースでは以下のコンポーネントを作成する必要があります。設定次第で前後はあると思いますが、作成の流れとしてはおおよそ以下になると思います。

  1. Azure, GCP で Virtual Network, VPC Network を作成、NSG, ファイヤウォール等を設定
  2. Azure 側で Virtual Network Gateway x 1 を作成
  3. GCP 側で Peer VPN Gateway x 1 を作成
  4. GCP 側で Cloud VPN Gateway x 1 を作成
  5. GCP 側で Cloud Router x 1 を作成
  6. GCP 側で VPN Tunnel x 2 を作成
  7. GCP 側で BGP Session x 2 を作成
  8. Azure 側で Local Network Gateways x 2
  9. Azure 側で Connections x 2

流石に 一つ目の項目は説明は不要だと思うので、Azure の Virtual Network Gateway の作成から行きましょう。

Azure 側で Virtual Network Gateway x 1 を作成

以下の例を参考にして頂ければと思います。

特に以下の設定項目は必須です。Second Public IP を新規で作成するので、リソース名等は適宜設定してください。作成時には Configure BGP はいったん off のままで後で設定します。

設定名 設定値
Gateway Type VPN
VPN Type Route-based
Enable active-active mode enabled
SECOND PUBLIC IP ADDRESS Create new

次に Virtual Network Gateway の Configuration メニューを選択し、Configure BGP を有効化します。ここで設定する主な項目は ASN と Custom Azure APIPA BGP IP address の二つです。今回の設定値としては以下にしました。

設定名 設定値
ASN 65510
Custom Azure APIPA BGP IP address 169.254.21.14
Second Custom Azure APIPA BGP IP address 169.254.22.50

ASN は GCP 側(別プラットフォーム側)でも設定し、異なる番号を入力します。ASN に関してはプライベートレンジの範囲で任意に入力して問題ありません。(Second)Custom Azure APIPA BGP IP address については、Azure のサポートする BGP IP のレンジが 169.254.21.* ~ 169.254.22.* である点、後述しますが GCP 側が Peer BGP IP(この場合は Azure BGP IP を指します)が "/30 subnet" 以内に居ないといけない制約がある点に注意が必要ですが、この範囲で有れば任意で問題ありません。

GCP 側で Peer VPN Gateway x 1 を作成

GCP 側に移動して Peer VPN Gateway を作成します(Azure 側でいう Local Network Gateway)。今回は高可用性のオプションを設定しているので、two interfaces のオプションを選択し、以下の様に Azure 側の VPN Gateway の Public IP アドレス x 2を指定します。

GCP 側で Cloud VPN Gateway x 1 を作成

Peer VPN Gateway では「Azure 側の VPN Gateway ってこのアドレスだよ」というガワを作成しているだけなので、GCP 側でも本体である Cloud VPN Gateway を作成する必要があります。VPN Gateway の所属する Network と Region を指定して Cloud VPN Gateway を作成します。作成後、以下の様に Public IP が二つ割り当てられるので、Azure 側で Local Network Gateways を作成する際にはこちらを利用します。

GCP 側で Cloud Router x 1 を作成

GCP 上では Cloud Router を作成します。こちらは BGP の動的ルーティングを行うために必要なコンポーネントになります。この辺り Azure は VPN Gateway 側のリソースに統合されてみえるので、見た目上の違いとして表れている点だと思います。

ここで GCP 側の ASN を指定します。この値はプライベートレンジかつ Azure 側の ASN と異なる必要があります。今回は 65509 を指定しました。

GCP 側で VPN Tunnel x 2 を作成

GCP 側では Cloud VPN Gateway, Peer VPN Gateway, Cloud Router と一通りの登場人物が作成できたので、漸く VPN Tunnel x 2 を作成します。Cloud VPN Gateway の画面から VPN Tunnel を作成できますが、原則は既に作成済のリソースを選ぶだけだと思います。IKE-pre-shaed key をここで pick up し、後で Azure 側で Connection を作成する際に利用する点、VPN Tunnel は二つ作る点に注意してください。

GCP 側で BGP Session x 2 を作成

Configure BGP sessions は後で設定する様に選択し、いったん設定を完了します。その後、VPN Tunnels 一覧から BGP の設定をします。以下に設定例を記載していますが、ここで Azure 側で設定した ASN 番号と Custom Azure APIPA BGP IP address を利用します。

設定名 設定値
Peer ASN 65510(Azure 側で設定した値)
Cloud Router BGP IPv4 address 169.254.21.13
BGP Peer IPv4 address 169.254.21.14(Azure 側で設定した値)

本記事では片方の VPN Tunnel のみ設定を記載していますが、高可用性のために用意したもう一つの VPN Tunnel 側も同様に設定してください。

Azure 側で Local Network Gateways x 2

これで漸く GCP 側は一通りの設定が完了したので、Azure 側に戻り、Local Network Gateway を二つ作成します。以下を参考にリソースを作成して下さい。

設定名 設定値
IP Address 35.242.112.236(GCP 側の Cloud VPN Gateway の Public IP #1)
Address Space(s) 10.101.0.0/16(GCP 側の VPC Network のアドレス )

繰り返しとなりますが、こちらの操作も高可用性のために GCP 側の Cloud VPN Gateway 二つ目にあたる Local Network Gateway も作成を忘れない様にして下さい。

Azure 側で Connections x 2

最後に Azure の Virtual Network Gateway から Connections を二つ作成します。これで設定は完了するはずです。

設定名 設定値
Connection Type Site-tosite(IPSec)
Local network gateway GCP 側の Public IP を指定した上記で作成のリソース
Shared key (PSK) GCP 側で pick up した値
Enable BGP 有効化
Enable Custom BGP Addresses 有効化
Custom BGP Addresses GCP 側で設定した BGP peer IPv4 address を設定

設定が上手くいかない場合

Azure 側では Virtual Network Gateway の Connections メニューで接続状態が確認できます。以下の様に Status が Unknown の場合は VPN の接続自体でこけています。この場合は shared key や各 IP アドレスの設定を見直してください。

VPN 接続が上手くいった場合でも以下の様に BGP sessions status が waiting for peer のままで BGP のルーティングが始まらない場合があります。

当然 BGP ルータの IP アドレス等の設定を再確認が必要ですが、何度も設定を見直しているせいで反映がどうなっているかの把握が難しい状態で BGP の設定が完了しない場合、以下の Azure の Virtual Network Gateway 側で Reset を試すと上手く接続が完了する場合があります。Reset 配下にある VPN troubleshoot も VPN 接続時のトラブルシューティングには参考になります。

Azure Front Door のログ情報を Kusto クエリで眺めてみる

前回は Azure Front Door に対してカスタムドメイン設定とBring Your Own Certificate (BYOC) 設定を行った場合のハマりどころについて紹介しました。今回は Azure Front Door のログデータを Log Analytics に送付し、Kusto Query をいくつか発行してデータを確認してみようと思います。

Azure Front Door 側のログ設定

まずは Azure Front Door 側で Diagnostic setting を有効化します。ここでは FrontDoorAccessLog, FrontDoorHealthProbeLog, FrontDoorWebApplicationFirewallLog のカテゴリがありますが、当然すべて選択して作成済の Log Analytics ワークスペースにデータを転送します。

Azure Front Door に関わらず Log Analytics のログ転送はいちど有効化して安定した後の場合、体感的には遅くとも数分以内に Log Analytics ワークスペース側にログが転送されています。しかし、初回設定時には8時間?程度の時間がかかる場合があるので注意ください。

Azure Front Door の基本的なログ情報

以下に何のひねりもない Kusto Query を発行した結果を張り付けたのでご賞味ください。

AzureDiagnostics テーブルでは通信プロトコル(HTTP/HTTPS)、ステータスコード、ホスト名、Azure Front Door の Origin URI、アクセス元の国等々が取得できるのが確認できると思います。Usage テーブルは Log Analytics ワークスペースに流れ込むデータ量がログとして蓄積されていますが、今回は割愛します。

何カ国かからのアクセスが来ているかは以下の様なクエリで抽出が可能です。私は現在米国におり、テスト用に頻繁にアクセスしたのでデータに表れています。

AzureDiagnostics |
where Category == "FrontDoorAccessLog" |
summarize access_by_country = count() by clientCountry_s

次にどの URI に一番アクセスされたかを以下の Kusto Query で取得してみましょう。

AzureDiagnostics |
where Category == "FrontDoorAccessLog" |
summarize requests_of_each_uri = count() by requestUri_s |
order by requests_of_each_uri 

さらに 404 のステータスコードを返した URI が何かの一覧は以下で取得できます。

AzureDiagnostics |
where  Category == "FrontDoorAccessLog" |
where httpStatusCode_s == 404 |
summarize by requestUri_s

ここまでで FrontDoorAccessLog カテゴリの基本的な情報を操作する方法は理解で来たと思いますので、次は FrontDoorWebApplicationFirewallLog 側を見てみます。

Azure Front Door の WAF 機能のログを確認してみる

FrontDoorWebApplicationFirewallLog は WAF 機能でのマッチングしたリクエストの情報が出力されます。試しに以下のカスタムルールを作成し、当該 Azure Front Door に付与します。

本ルールはアクセス元の地域が米国だった場合に Log Analytics ワークスペース側に情報を転送するものです。実際に Kusto Query を発行して情報を確認します。

AzureDiagnostics |
where Category == "FrontDoorWebApplicationFirewallLog"


ご覧の通り、どの URI にアクセス時、ルールにマッチングしたか、どの様なアクションが取られたか等がログの情報から分かります。スクリーンショットでは action_s は Logであり、ログ情報が出力されるだけの設定です。

感の良い方なら気づいたかもしれませんが、ルール名にある通り最初はアクセスをブロックしようとしました。ログとしては以下です。action_s は Block として出力されているのですが、ブラウザからは普通にアクセスできてしまいました。こちらは私の設定ミスかもしれませんので、何か気づきが有ればまた更新したいと思います。これは policyMode_s に記載があるとおり detection モードで動作していることが原因です。こちらを prevention モードに変更すればブロックされます。

カスタムドメイン&BYOC で Azure Front Door を試した際のハマりどころ

その昔から Azure には Traffic Manager と呼ばれるリージョンレベルで負荷分散が行える機能がありましたが、同機能の位置づけはグローバル DNS 的なものであり、WAF 的な機能、URL の書き換え、SSL オフロードといった機能を利用したい場合、リクエストをリージョンレベルに振り分けた後、リージョン単位でのサービス(Azure 組み込み機能だと Application Gateway が一般的)で制御をおこなうのが一般的でした。Azure Front Door はリージョンを跨いでのリクエスト振り分けが可能なことに加え、上記で記載した機能も同リソースを用いることで実現可能です。
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-overview

Azure Front Door には Standard と Premium と呼ばれる二つの SKU がありますが、特に Premium SKU を利用する場合は Private Link の利用が可能になります。Standard SKU でも機能的に十分なことが多いとは思いますが、いわゆるエンプラ的なお客様のコンプライアンスに沿うために閉域的な通信が必要な場合には必須な機能といえます。
https://azure.microsoft.com/en-us/pricing/details/frontdoor/

生まれも社畜、育ちも社畜、今は外資社畜としてコテコテのエンプラ道を歩んできた身からすれば、上記の Private Link に加えて「カスタムドメイン」と「Bring Your Own Certificate (BYOC) 」を試さざるを得ないと思い色々と試しました。結果的には以下の構成になっております。今回は Azure Front Door で SSL オフロードをしていますが、こちらは要件に合わせて調整下さい。

これに関しては色々とハマりどころがあり、ハマりどころときれいな設定手順を混ぜるとこんがらがりそうだったので、今回はハマりどころに注力して記載しております。

Azure Front Door に証明書を登録する際には Azure AD の Global Administrator 権限が必要になる場合がある

Azure Front Door は Azure Key Vault 経由でしか証明書が読み込めません。そのため Azure Front Door 向けの Service Principal を作成・登録して操作する必要があるのですが、こちらの処理時に当該 Azure AD の Global Administrator 権限が必要になります。

Note

This action requires you to have Global Administrator permissions in Azure AD.
 The registration only needs to be performed once per Azure AD tenant.

https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain-https

ただこちらは Azure AD テナント毎に一度操作を実行すればよいので、Global Administrator に処理を頼むことができれば問題ありません。つまり Azure Front Door のリソースを何個作ろうと同じサービスプリンシパルを使いまわすことになります。この辺りはヘイシャーにお勤めの方とかは Microsoft.AzureFrontDoor-Cdn とかの名前で Service Principal を探せば見つかると思います(以下参照。
Register Azure Front Door CDN with Key Vault - Azure Tech Guy

Azure Front Door はオレオレ証明書をサポートしない

こちらに関しては良く言えば「セキュリティ的に厳密さが高いのがデフォルト設定になっている」ともいえますが、開発時には中々大変です。以下にはっきりと記載がありますが、自己証明書を利用する場合はアクセスがブロックされます。

When you create your TLS/SSL certificate, you must create a complete certificate chain with
an allowed Certificate Authority (CA) that is part of the Microsoft Trusted CA List. If you use 
a non-allowed CA, your request will be rejected.

Certificates from internal CAs or self-signed certificates aren't allowed.

End-to-end TLS with Azure Front Door | Microsoft Docs

トラステッド認証局 (CA) からの署名済み証明書を取得する必要がありますが、ここは Azure Front Door をお試しで試す場合に大きなハードルの一つ目です。こちらに対しては App Service Certificate を利用しました。ご存じない方も居るかも知れませんが、同機能は App Service 専用ではありません。
Add and manage TLS/SSL certificates - Azure App Service | Microsoft Docs

Azure Front Door は HTTPS 通信時に CN がマッチングしないと通信をはじく

開発環境と似たような設定で本番リリースした結果で痛い目を見ることを避けらるようになっているとも言えますが、やはり開発時にはハードルが高いです。節のタイトルに加えて Azure Front Door 自体には「apex/root ドメインは未サポート(normalian.work とかはダメで、www.normalian.work とかならOK」という制約もあります。

Enabling HTTPS via Front Door managed certificate is not supported for 
apex/root domains (example: contoso.com). You can use your own
certificate for this scenario. Please continue with Option 2 for further details.

Tutorial - Configure HTTPS on a custom domain for Azure Front Door | Microsoft Docs

ここで注意が必要なのが、当然ながら App Service Certificate は apex/root ドメイン(normalian.work 等)で作成する必要があるということです。何が問題かというと、Azure Front Door 自身は apex/root ドメインは未サポート( www.normalian.work とかならOK )の点とでドメイン名に不整合が発生します。私は

  • App Service Certificate で normalian.work ドメイン向けの Standard SKU の証明書作成
  • Azure Front Door で www.normalian.work のカスタムドメイン登録

を行い、一通りの設定をしましたが、当然疎通は通らず、Log Analytics のログを確認したところ CertificateNameCheckFailed のエラーが発生していました。

こちらに関しての回避方法は比較的容易で App Service Certificate 側でワイルドカード証明書として作成する方法です。

App Service Certificate 上でワイルドカード証明書として作成した場合、www.normalian.work といったドメインでも対応が可能になります。Azure Front Door には Azure Key Vault 経由で登録されるので以下の様になります。

CNAME レコードの登録、TXT レコードの登録が必要

こちらに関しては大して問題ならないかもしれませんが、Azure Front Door でカスタムドメインを登録する場合はタイトルで記載した二つの処理が必要になります(以下は設定済の環境。

How to add a custom domain - Azure Front Door | Microsoft Docs

私は未だにメールの多さでちょっと辛いお名前ドットコムを使っており、以下が同サイトでの設定画面になっています。一つ目の CNAMEと三つ目の TXT レコードが Azure Front Door 向け、二つ目の TXT レコードが App Service Certificate 向けと言ったところです。

今回はほぼ証明書とカスタムドメインでのハマりどころを記載しましたが、誰かの手助けになれば幸いです。

Completely turn off your AKS clusters to reduce your cost!

As you might know, it was not possible to stop your AKS clusters completely because system pools are always required to be running. I have posted about this like below in past.
normalian.hatenablog.com

Here is quite useful feature to reduce AKS cost much effectively than before.
docs.microsoft.com

It should be really easy to follow the article. I have open Azure Portal and try to stop my AKS cluster like below, and it seems to be fine even if you have never registered "extension aks-preview" like below.
f:id:waritohutsu:20201007120040p:plain

You can find your node pools will be 0 nodes on Azure Portal or command lines after you have completed the commands.
f:id:waritohutsu:20201007120440p:plain

Let's utlize Azure Front Door to route requests globally

Azure Front Door is useful feature to manage and monitor your web traffics with global routing. Azure Front Door enables you to manage and optimize your global(multi-regions) customers easily. I believe readers of my blog want to acquire practical knowledge, so let's start to try!

At first, you need to note that Azure Front Door is global resource as you can confirm on Azure Portal below. This means you're no longer to be bothered by regional perspective at least for Azure Front Door.
f:id:waritohutsu:20200705041348p:plain

What's resources we can setup on Azure Front Door?

Azure Front Door can choose various types of resources like below. You are also possible to route requests out of Azure Platform with "Custom Host" and setup FQDNs. In this post, you can acquire knowledge how to use "Storage", "Public IP Address" and "Custom Host"
f:id:waritohutsu:20200705045658p:plain

Setup a sample scenarios

Here is an example architecture which I have setup as a sample for Azure Front Door.
f:id:waritohutsu:20200705050415p:plain

After creating your Azure Front Door instance, choose "Front Door designer" and add your owned domain on Azure Portal like below.
f:id:waritohutsu:20200705050628p:plain

Next, you can add your backend resources on "Backend pools" menu like below.
f:id:waritohutsu:20200705050804p:plain

You can add "Microsoft Cloud Workshop" site like below by setting up as "Custom host".
f:id:waritohutsu:20200705050950p:plain

Finally, you can setup rules how to forward or redirect HTTP/HTTPS requests into backend pools. In this example, all requests match with "/storage01/*" will be forwarded to my Azure Storage account into "/" path. Don't forget to specify as "/storage01/*" not ""/storage01/"
f:id:waritohutsu:20200705051353p:plain

Access a sample with Azure Front Door

You can confirm each request routings like below.
f:id:waritohutsu:20200705052118p:plain

Azure NAT Gateway enables Azure VMs to access internet without assigning Public IP

I guess some folks are not familiar with Azure NAT Gateway because this feature is quite useful but it's a little bit hard to recognize use cases. Here are my idea for Azure NAT Gateway use cases.

  1. Azure VMs, attached with Standard Internal Load Balancer, are required to assign PIP(Public IP) to access internet. Now, your Azure VMs are possible to access internet with Azure NAT Gateway without PIPs
  2. Azure VMs access Global IPs are identified as PIPs but this forces lots of effort to allow accesses from Azure to environments. Now, you can simplify Azure VMs access Global IPs by using Azure NAT Gateway

Of course, there should be much more use cases for Azure NAT Gateway. Please let me such use cases with comments of this blog. Here are architecture diagram for #1 and #2 scenarios.
f:id:waritohutsu:20200702094921p:plain

You can find each Azure VMs will access to internet via Azure NAT Gateway and their global IPs will be identified as PIP assigned to Azure NAT Gateway.

Create and attach Azure NAT Gateway to subnets

Go to Azure Portal and start to create like below. You need to put your Azure NAT Gateway name and choose region here.
f:id:waritohutsu:20200702095935p:plain

Next, choose your PIP to assign Azure NAT Gateway.
f:id:waritohutsu:20200702100019p:plain

Finally, you need to associate this Azure NAT Gateway to your subnets like below.
f:id:waritohutsu:20200702100104p:plain

PIP access via Azure NAT Gateway

Login to WildFlyVM0 having no PIP but 10.3.0.6 as private IP. Next, run "curl 'https://api.ipify.org?format=json'" to confirm global ip like below.
f:id:waritohutsu:20200702100316p:plain