Serveurs internes incapables de s'atteindre les uns les autres sur leur IPS publique avec NAT bi-directionnelle statique

Demande client

Lorsque les serveurs internes sont configurés avec des adresses NAT bi-directionnelles statiques, certains serveurs ne peuvent pas communiquer entre eux via leurs adresses IP publiques. C'est le comportement attendu en raison de la façon dont les stratégies sont évaluées sur les appareils de Palo Alto Networks. Ce document propose une configuration alternative comme solution de contournement.

Cause

Les pare-feu de Palo Alto Networks évaluent les politiques NAT de façon descendante. Lorsqu'une règle est mise en correspondance, cette règle est sélectionnée pour traiter les paquets et aucune autre recherche n'est effectuée. Pour comprendre comment ce comportement affecte la connectivité aux serveurs, considérez le scénario ci-dessous:

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

La communication ne doit pas être un problème pour les trois serveurs s'ils communiquent via leurs adresses IP privées respectives. Le problème se produit si chaque serveur connaît uniquement les adresses IP publiques ou les noms de FQDN des autres serveurs, et que chacun des serveurs possède une stratégie NAT bi-directionnelle statique.

Pour chacune des instructions NAT bi-directionnelles écrites, il existe 2 stratégies créées dans le dataplane:

• Un pour le NAT source
• Un pour le NAT de destination

Ces stratégies de nat sont arrangées dans l'ordre que vous les avez configurés, et ainsi la configuration bi-NAT1, bi-NAT2 et bi-NAT3 pour les trois serveurs apparaîtra dans l'exécution de configuration dans l'ordre suivant:

bi-NAT1 (s_NAT1)

bi-NAT1 (dNAT1)

bi-NAT2 (s_NAT2)

bi-NAT2 (dNAT2)

bi-NAT3 (s_NAT3)

bi-NAT3 (dNAT3)

Voici un extrait des stratégies NAT configurées sur l'interface graphique et la façon dont le bi-NAT1 apparaît dans CLI.

Remarque: les sorties CLI bi-NAT2 et bi-NAT3 sont plus en dessous mais ne sont pas affichées dans cet exemple. Pour afficher les stratégies NAT complètes dans dataplane, émettez la commande'afficher l'exécution de la stratégie Nat'dans CLI.

Avec cette configuration, lorsque le trafic est source de Srv_A (192.168.89.206), aller à destination myserverB.com (10.66.25.102), le bi-NAT1 (s_NAT1) est apparié en raison de l'évaluation de la stratégie de haut en bas, mais la communication ne fonctionne jamais. Le trafic résultant apparaît comme suit:

Cependant, lorsque le trafic provient de Srv_C (192.168.89.209), allant à la même destination myserverB.com (10.66.25.102), Notez que la communication est réussie car la destination correcte NAT bi-NAT2 (dNAT2) est appariée. La logique trouve une correspondance pour l'IP de destination et seulement que l'IP est traduit. Le trafic résultant apparaît comme suit:

Remarquez également que pour la traduction de travail, les zones de-zone et de zone sont à la fois Trust-L3 (ce qui est correct). Toutefois, pour la traduction non-travail, la zone de-est Trust-L3 et l'à-zone est Untrust-L3, et Srv_B ne reçoit jamais le paquet de ping.

Résolution

Pour garantir que les serveurs communiquent entre eux via leurs adresses IP publiques, nous devons écrire des instructions NAT de destination et de source distinctes pour chaque serveur, puis positionner ces NAT de destination au-dessus des NAT source. Notez que les instructions NAT de destination doivent avoir la zone source définie sur'any'pour autoriser le trafic entrant de n'importe quelle zone.

Voici comment les instructions nat s'occupent de leur nouvelle configuration:

Vérifiez également que Srv_A peut communiquer correctement avec tous les serveurs internes.

propriétaire : tasonibare