静的双方向 NAT を使用して、パブリック ip 上で互いに到達できない内部サーバー
Resolution
問題
内部サーバーが静的双方向 NAT アドレスを使用して構成されている場合、一部のサーバーは、パブリック IP アドレスを使用して相互に通信できません。これは、ポリシーがパロアルトネットワークデバイスでどのように評価されるかによって予想される動作です。このドキュメントでは、代替の構成を回避策として提案します。
原因
パロアルトネットワークファイアウォールは、トップダウン方式で NAT ポリシーを評価します。ルールが一致すると、そのルールがパケットを処理するように選択され、それ以上のルックアップは実行されません。この動作がサーバーへの接続にどのように影響するかを理解するには、以下のシナリオを検討してください。
Srv A: プライベート ip = 192.168.89.206、パブリック ip = 10.66.25.101、FQDN = myserverA.com
Srv B: プライベート ip = 192.168.89.210、パブリック ip = 10.66.25.102、FQDN = myserverB.com
Srv C: プライベート ip = 192.168.89.209、パブリック ip = 10.66.25.103、FQDN = myserverC.com
通信は、それぞれのプライベート IP アドレスを介して通信する場合、3つのサーバーの問題ではありません。この問題は、各サーバーが他のサーバーのパブリック IP アドレスまたは FQDN 名を認識していて、各サーバーが静的双方向の NAT ポリシーを持っている場合に発生します。
書き込まれた双方向 NAT ステートメントのそれぞれについて、dataplane で作成された2つのポリシーがあります。
- ソース NAT 用の1つ
- 宛先 NAT 用の1つ
これらの NAT ポリシーは、構成した順序で配置されるため、3つのサーバーに対して NAT1、bi NAT2、および bi NAT3 を構成すると、次の順序で構成が実行されます。
双 NAT1 (s_NAT1)
双 NAT1 (dNAT1)
双 NAT2 (s_NAT2)
双 NAT2 (dNAT2)
双 NAT3 (s_NAT3)
双 NAT3 (dNAT3)
以下は、GUI で構成された NAT ポリシーのスニペットと、CLI での NAT1 の表示方法です。
メモ: NAT2 および bi NAT3 CLI 出力は、この例では示されていませんが、さらに以下に示します。dataplane で完全な nat ポリシーを表示するには、CLI で「実行中の nat ポリシーを表示」コマンドを発行します。
この構成では、トラフィックが Srv_A (192.168.89.206) から供給され、宛先 myserverB.com (10.66.25.102) になると、トップダウンポリシー評価のために bi NAT1 (s_NAT1) が照合されますが、通信は動作しません。結果のトラフィックは次のように表示されます。
ただし、トラフィックが Srv_C (192.168.89.209) から供給される場合、同じ宛先 myserverB.com (10.66.25.102) に移動すると、正しい宛先 NAT bi-NAT2 (dNAT2) が一致するため、通信が成功したことに注意してください。ロジックは、宛先 ip の一致を検出し、その ip のみが翻訳されます。結果のトラフィックは次のように表示されます。
また、作業用の翻訳では、from ゾーンと to ゾーンは両方とも信頼 L3 (正しい) であることに注意してください。ただし、非動作変換では、from-ゾーンはトラスト-l3 であり、to ゾーンは untrust であり、Srv_B は ping パケットを受信しません。
解決方法
サーバーがパブリック IP アドレスを介して相互に通信するようにするには、各サーバーに対して別個の宛先と送信元の nat ステートメントを記述し、それらの宛先 nat をソース nat の上に配置する必要があります。宛先 NAT ステートメントは、任意のゾーンからの着信トラフィックを許可するために、ソースゾーンを ' any ' に設定する必要があることに注意してください。
次に、NAT ステートメントが再構成された後の様子を示します。
また、Srv_A がすべての内部サーバーと正常に通信できることを確認します。
所有者: tasonibare