Interne Server, die sich auf Ihren öffentlichen IPS mit statischem bidirektionalem NAT nicht gegenseitig erreichen können
Resolution
Problem
Wenn interne Server mit statischen bidirektionalen NAT-Adressen konfiguriert sind, sind einige Server nicht in der Lage, über ihre öffentlichen IP-Adressen miteinander zu kommunizieren. Dies wird erwartet, Verhalten aufgrund der Bewertung der Richtlinien auf den Palo Alto Networks-Geräten. Dieses Dokument schlägt eine Alternative Konfiguration als Workaround vor.
Ursache
Palo Alto Networks Firewalls evaluieren die NAT-Politik in einer Top-Down-Manier. Wenn eine Regel abgestimmt ist, wird diese Regel ausgewählt, um die Pakete zu verarbeiten, und es wird kein weiterer Lookup durchgeführt. Um zu verstehen, wie sich dieses Verhalten auf die Konnektivität zu Servern auswirkt, betrachten Sie das Szenario unten:
SRV A: Private IP = 192.168.89.206, Public IP = 10.66.25.101, FQDN = myserverA.com
SRV B: Private IP = 192.168.89.210, Public IP = 10.66.25.102, FQDN = myserverB.com
SRV C: Private IP = 192.168.89.209, Public IP = 10.66.25.103, FQDN = myserverC.com
Kommunikation sollte für die drei Server kein Problem sein, wenn Sie über ihre jeweiligen privaten IP-Adressen kommunizieren. Das Problem tritt auf, wenn jeder Server nur von den öffentlichen IP-Adressen oder FQDN-Namen der anderen Server weiß, und jeder der Server eine statische bidirektionale NAT-Richtlinie hat.
Für jede der bidirektionalen NAT-Anweisungen, die geschrieben wurden, gibt es zwei Richtlinien, die im dataplane erstellt wurden:
- Eine für die Quelle NAT
- Eine für die Destination NAT
Diese NAT-Richtlinien sind in der Reihenfolge angeordnet, in der Sie Sie konfiguriert haben, und so wird die Konfiguration von BI-NAT1, BI-NAT2 und BI-NAT3 für die drei Server in der laufenden Konfiguration in folgender Reihenfolge erscheinen:
BI-NAT1 (s_NAT1)
BI-NAT1 (dNAT1)
BI-NAT2 (s_NAT2)
BI-NAT2 (dNAT2)
BI-NAT3 (s_NAT3)
BI-NAT3 (dNAT3)
Im folgenden finden Sie einen Ausschnitt der NAT-Richtlinien, die auf der GUI konfiguriert sind und wie die BI-NAT1 in CLI erscheint.
Hinweis: BI-NAT2 und BI-NAT3 CLI-Ausgänge sind weiter unten, aber in diesem Beispiel nicht angezeigt. Um die vollständige NAT-Richtlinie in dataplane zu sehen, geben Sie den Befehl "Show Running NAT-Policy" in CLI aus.
Mit dieser Konfiguration, wenn der Verkehr von Srv_A (192.168.89.206), zu Ziel myserverB.com (10.66.25.102), wird die BI-NAT1 (s_NAT1) aufgrund der Top-Down-Politikbewertung, aber die Kommunikation funktioniert nie. Der daraus resultierende Verkehr erscheint wie folgt:
Wenn der Verkehr von Srv_C (192.168.89.209) bezogen wird, aber an das gleiche Ziel geht myserverB.com (10.66.25.102), beachten Sie, dass die Kommunikation erfolgreich ist, weil das richtige Ziel NAT BI-NAT2 (dNAT2) aufeinander abgestimmt wird. Die Logik findet eine Übereinstimmung mit der Ziel-IP und nur, dass IP übersetzt wird. Der daraus resultierende Verkehr erscheint wie folgt:
Beachten Sie auch, dass für die funktionierende Übersetzung die from-Zone und to-Zone beide Trust-L3 sind (was richtig ist). Für die nicht funktionierende Übersetzung ist die from-Zone jedoch Vertrauen-L3 und die to-Zone ist unvertrauens voll-L3, und Srv_B erhält nie das Ping-Paket.
Lösung
Um sicherzustellen, dass die Server über ihre öffentlichen IP-Adressen miteinander kommunizieren, müssen wir für jeden Server verschiedene Ziel-und Quell-NAT-Anweisungen schreiben und dann diese Destination NATs über dem Quell NATs positionieren. Beachten Sie, dass die Ziel-NAT-Anweisungen die Quell Zone auf "Any" setzen sollten, um den eingehenden Verkehr aus jeder Zone zu ermöglichen.
Das folgende ist, wie die NAT-Anweisungen aussehen, nachdem Sie neu konfiguriert wurden:
Überprüfen Sie auch, ob Srv_A erfolgreich mit allen internen Servern kommunizieren kann.
Besitzer: Tasonibare