Los servidores internos no pueden comunicarse entre sí en sus IPS públicas con NAT bidireccional estático

Incidencia

Cuando los servidores internos están configurados con direcciones NAT bidireccional estáticas, algunos servidores no pueden comunicarse entre sí a través de sus direcciones IP públicas. Este comportamiento se espera debido a cómo se evalúan las políticas en los dispositivos de Palo Alto Networks. Este documento propone una configuración alternativa como solución temporal.

Causa

Los cortafuegos de Palo Alto Networks evalúan las políticas NAT de una manera descendente. Cuando se empareja una regla, se selecciona esa regla para procesar los paquetes y no se realiza ninguna búsqueda adicional. Para entender cómo afecta este comportamiento a la conectividad a los servidores, considere el siguiente escenario:

SRV A: IP privada = 192.168.89.206, IP pública = 10.66.25.101, FQDN = myserverA.com

SRV B: IP privada = 192.168.89.210, IP pública = 10.66.25.102, FQDN = myserverB.com

SRV C: IP privada = 192.168.89.209, IP pública = 10.66.25.103, FQDN = myserverC.com

La comunicación no debe ser un problema para los tres servidores si se comunican a través de sus respectivas direcciones IP privadas. El problema se produce si cada servidor sólo conoce las direcciones IP públicas o nombres de FQDN de los demás servidores, y cada uno de los servidores tiene una directiva NAT bidireccional estática.

Para cada una de las declaraciones NAT bi-direccionales escritas, hay 2 directivas creadas en el plan de la misma:

• Uno para el NAT de origen
• Uno para el destino NAT

Estas directivas NAT se organizan en el orden en que las ha configurado, por lo que la configuración de BI-NAT1, BI-NAT2 y BI-NAT3 para los tres servidores aparecerá en la configuración de ejecución en el siguiente orden:

BI-NAT1 (s_NAT1)

BI-NAT1 (dNAT1)

BI-NAT2 (s_NAT2)

BI-NAT2 (dNAT2)

BI-NAT3 (s_NAT3)

BI-NAT3 (dNAT3)

A continuación se muestra un fragmento de las directivas NAT configuradas en la GUI y cómo el BI-NAT1 aparece en CLI.

Nota: las salidas BI-NAT2 y BI-NAT3 CLI están más abajo, pero no se muestran en este ejemplo. Para ver las directivas NAT completas en el plan de datos, emita el comando ' Mostrar ejecución de NAT-Policy ' en CLI.

Con esta configuración, cuando el tráfico se origina desde Srv_A (192.168.89.206), yendo a Destination myserverB.com (10.66.25.102), el BI-NAT1 (s_NAT1) se iguala debido a la evaluación de políticas de arriba hacia abajo pero la comunicación nunca funciona. El tráfico resultante aparece de la siguiente manera:

Sin embargo, cuando el tráfico procede de Srv_C (192.168.89.209), va al mismo destino myserverB.com (10.66.25.102), tenga en cuenta que la comunicación es satisfactoria porque el destino correcto de NAT BI-NAT2 (dNAT2) se iguala. La lógica encuentra una coincidencia para la IP de destino y sólo esa IP se traduce. El tráfico resultante aparece de la siguiente manera:

Observe también que para la traducción de trabajo, la de-zona y la a-zona son ambos confianza-L3 (Cuál es correcto). Sin embargo, para la traducción no laboral, la de-zona es Trust-L3 y la a-Zone es Untrust-L3, y Srv_B nunca recibe el paquete de ping.

Resolución

Para asegurarse de que los servidores se comuniquen entre sí a través de sus direcciones IP públicas, necesitamos escribir declaraciones de NAT de destino y origen distintas para cada servidor y, a continuación, colocar los NATs de destino por encima de los NATs de origen. Tenga en cuenta que las instrucciones NAT de destino deben tener la zona de origen establecida en ' any ' para permitir el tráfico entrante desde cualquier zona.

A continuación se encuentra la forma en que las instrucciones NAT se fijan después de haber sido reconfiguradas:

Además, compruebe que Srv_A puede comunicarse satisfactoriamente con todos los servidores internos.

Propietario: tasonibare