【Paloalto×Azure】送信元IPが固定されるかどうか検証してみた

Azure上に構築したpaloaltoでインターネット側のインターフェースにパブリックIPを明示的に付与しない場合に、Azureからインターネットに出ていくときの送信元IPが変化するのかを検証してみました。

今回利用する環境は、以下の以前の記事で作成した環境を利用します。

Azure上でpaloaltoを作成して、Azure上にある仮想マシンからインターネットに向かう通信をすべてpaloalto経由にする構成を試してみました。paloaltoのデプロイ、Azure側の設定、paloaltoの設定、最後にpaloaltoに通信を通すところまで試し、気づいた点などまとめてみました。

上記の記事を見ていただければわかりますが、この環境ではpaloaltoのインターネット向けのインターフェース(eth1)にはAzure上でパブリックIPを明示的に付与していません。

なので、eth1からインターネットに出ていく際にはAzure基盤側でNATされたIPで出ていくことになります。

このとき、「eth1に明示的にパブリックIPを付与しないとIPが変わりそうだな。paloaltoの送信元IPでなにかしらのアクセス制限をかける場合には不便だな。」、と思ったのでどうなるのかを調べてみました。

検証した構成
検証① eth1のNICにパブリックIPを付与しない場合に送信元IPが変化するのかを調べる
検証② eth1のNICにパブリックIPを付与した場合の挙動を調べる
結果まとめ
気づいたこと
1. paloaltoの停止と起動には時間がかかる
さいごに

検証した構成

今回は別の記事で作成した環境のテスト用仮想マシンからpaloaltoを経由してインターネット越しにIISをインストールした別の仮想マシンにアクセスして、IISのログから送信元IPを調べてみました。

構成としては以下の通りです。

今回の検証ではIISのサーバもAzure仮想マシンで作成しています。

検証① eth1のNICにパブリックIPを付与しない場合に送信元IPが変化するのかを調べる

以下の手順で検証を実施しました。

①‐１．テスト用仮想マシンでIISに通信をする（1回目）
①‐２．webサーバ(IIS)側でログを見て送信元IPを確認する（1回目）
①‐３．paloaltoの仮想マシンを再起動する
①‐４．テスト用仮想マシンでIISに通信をする（2回目）
①‐５．webサーバ(IIS)側でログを見て送信元IPを確認する（2回目）

①‐１．テスト用仮想マシンでIISに通信をする（1回目）

テスト用仮想マシンからブラウザでIISサーバにアクセスしてみます。

IISには[hogehogehoge.com]という仮のドメインを付与し、テスト用のhtmlを配置しています。

paloaltoのログも確認してみます。

ポートが5580で通信しているログを確認することができました。

①‐２．webサーバ(IIS)側でログを見て送信元IPを確認する（1回目）

IIS側のログも確認します。

paloaltoのログの時間と少し誤差がありますが、11:28のログとして確認できた［20.222.171.18］がpaloaltoがインターネットに出ていくときに利用されるIPであることが分かりました。

①‐３．paloaltoの仮想マシンを再起動する

今回はAzureポータル上から「停止」をクリックして一度完全に停止させてから、「開始」をクリックして起動するといった方法で仮想マシンを再起動します。

①‐４．テスト用仮想マシンでIISに通信をする（2回目）

テスト用仮想マシンからブラウザでIISサーバにアクセスし、paloaltoのログも確認します。

①‐５．webサーバ(IIS)側でログを見て送信元IPを確認する（2回目）

IIS側のログも確認します。

確認してみると、再起動前は送信元IPが［20.222.171.18］であったのに今回はなんと［13.78.12.205］に変わっていました。

予想はしていましたが、paloaltoのeth1のNICにパブリックIPを付与しない場合には、再起動などが起きると送信元IPが変化するということが分かりました。

検証② eth1のNICにパブリックIPを付与した場合の挙動を調べる

「paloaltoのeth1のNICにパブリックIPを付与しない場合」では、「再起動などが起きると送信元IPが変化する」といった結果となりましたが、

eth1のNICにパブリックIPを付与した場合には、送信元IPが変化するのかどうか？そもそも付与したパブリックIPのIPアドレスが利用されるのか？についても調べてみました。

流れとしては以下の通りです。

②‐１．eth1にパブリックIPを付与する
②‐２．仮想マシンでIISに通信をする（IP付与後）
②‐３．webサーバ(IIS)側でログを見て送信元IPを確認する（IP付与後）
②‐４．paloaltoの仮想マシンを再起動する
②‐５．テスト用仮想マシンでIISに通信＋各ログを確認する

②‐１．eth1にパブリックIPを付与する

パブリックIPを新規作成し、paloalto仮想マシンのeth1のNICにパブリックIPを付与します。

Azureポータルにて実施していただいてもOKですし、AzureCLIのコマンドを利用して付与したのでこれも参考にしていただければ幸いです。

#PubllicIPを作成
$publicip = az network public-ip create -n "PublicIP-eth1" -g "Test-RG" --sku "Standard" | ConvertFrom-Json

#NICの情報を取得
$nic_id =  az vm nic list -g "Test-RG" --vm-name "paloaltopayg01" | ConvertFrom-Json
$nic_id_eth1 = $nic_id | Where-Object {$_.id -like "*eth1"}
$nic_id_eth1_name = $nic_id_eth1.id.Split("/")

#PublicIPをNICに付与
az network nic ip-config update -g "Test-RG" --nic-name $nic_id_eth1_name[-1] -n "ipconfig-untrust" --public-ip-address $publicip.publicip.name

今回新規に作成するパブリックIPは[Stadard]で作成しているので必然的に[静的IP]として払い出されます。

また、この作業に伴うpaloalto内での追加設定は必要ありません。

今回付与したパブリックIPは［52.253.104.17］でした。

②‐２．仮想マシンでIISに通信をする（パブリックIP付与後）

テスト用仮想マシンからブラウザでIISサーバにアクセスし、paloaltoのログも確認します。

②‐３．webサーバ(IIS)側でログを見て送信元IPを確認する（パブリックIP付与後）

IIS側のログも確認します。

新しく付与したパブリックIP［52.253.104.17］が送信元IPとしてログ上で確認することができました。

従って、paloaltoのインターネット向けのNICに付与したパブリックIPが送信元IPとして利用されるということが分かりました。

この状態で再度paloaltoを再起動してIPが変化するのかどうかも見てみました。

②‐４．paloaltoの仮想マシンを再起動する

先ほどと同様に、Azureポータル上から「停止」をクリックして一度完全に停止させてから、「開始」をクリックして起動するといった方法で仮想マシンを再起動します。

②‐５．テスト用仮想マシンでIISに通信＋各ログを確認する

テスト用仮想マシンからブラウザでIISサーバにアクセスし、paloaltoのログも確認します。

IIS側のログも確認します。

paloalto仮想マシンの再起動後も新しく付与したパブリックIP［52.253.104.17］が送信元IPとしてログ上で確認することができました。

従って、eth1のNICにパブリックIPを付与した場合には、送信元IPは変化しないということが分かりました。

結果まとめ

今回実施した検証結果のまとめです。

　※今回の構成でeth1はインターネットに出ていく際に利用するインターフェースです。

検証① eth1のNICにパブリックIPを付与しない場合に送信元IPが変化するのかを調べる

paloalto仮想マシンのeth1のNICにAzure上で明示的にパブリックIPを付与しない場合には、再起動などが起きると送信元IPが変化する

検証② eth1のNICにパブリックIPを付与した場合の挙動を調べる

paloalto仮想マシンのeth1のNICにAzure上で明示的にパブリックIPを付与した場合には、NICに付与したパブリックIPが送信元IPとして利用される
paloalto仮想マシンのeth1のNICにAzure上で明示的にパブリックIPを付与した場合には、再起動などが起きても送信元IPが変化しない

気づいたこと

paloaltoの停止と起動には時間がかかる

本筋とは関係ない話となりますが、「おっ。」と思ったので書いておきます。

今回はpaloaltoの再起動方法として、Azureポータル上から「停止」をクリックして一度完全に停止させてから、「開始」をクリックして起動するといった方法を利用しました。

このとき「停止」クリックから仮想マシンが完全に停止するまではすぐでした（今回は２分くらい）。

一方、「開始」クリックから起動して、paloaltoのログイン画面が表示されるまでには10分かかりました。

より正確に言うとAzure上での仮想マシンの起動は1分くらいで起動完了しましたが、その後、paloaltoのIPにアクセスして、ログイン画面が表示されるまでに時間がかかりました。

paloaltoの仮想マシンを起動して実際に利用できる状態になるまでには思ったより時間がかかった印象でした。

また、ポリシーやオブジェクトがたくさん設定されているpaloaltoを起動する場合にはもっと時間がかかるのかもしれないなとも思いましたので、その辺の起動時間にいてもいつか調べてみたいと思います。

さいごに

paloalto内から実際に利用しているパブリックIPが確認できれば楽なのですが、現状はできなさそうなのでひと手間かけて今回のような手段で確認してみました。

今回の検証結果から、paloalto仮想マシンのインターネット向けのNICに対してパブリックIPを付与したほうが送信元IPが変化しないので、実際に構築する際にはパブリックIPを付与したほうがよさそうかなと思いました。