El NAT de origen oculta las direcciones de los clientes a un firewall posterior

Una regla escrita para clientes de personal y de laboratorio se coloca en el nuevo firewall de borde, y coincide en silencio con todo o con nada. La razón está más arriba: una puerta de enlace ya reescribió las direcciones de los clientes, así que la regla ve una sola dirección de tránsito en lugar de dos grupos. Añadir un equipo no restaura la información que el camino eliminó. Encuentre el último punto donde la distinción aún existe antes de escribir la política.

Por qué la regla de borde ve una sola dirección

La traducción de muchos a uno asigna cada par interno de dirección y puerto a una dirección externa compartida con un puerto asignado. Las conversaciones siguen siendo distinguibles para el traductor gracias a esas vinculaciones de puerto, pero un dispositivo posterior que hace una simple coincidencia de prefijo de origen solo ve la dirección compartida. Eso basta para que dos grupos sean idénticos en la regla. Los paquetes siguen llegando; la agrupación no.

Compruebe qué observa realmente la interfaz del firewall, no qué promete el diagrama. Ambos difieren más a menudo de lo que nadie espera.

Encuentre la última identidad aplicable

Empiece en el punto de aplicación y retroceda hasta que aparezca el prefijo original. Dos comandos suelen localizar la frontera.

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

La tabla NAT muestra qué tráfico se traduce y mediante qué regla, mientras que el listado de conntrack muestra las tuplas originales y traducidas de los flujos activos. Donde el firewall anterior solo ve la dirección traducida, las reglas de origen por grupo no pueden funcionar allí, por muy bien escritas que estén. Avance o retroceda por el camino hasta llegar a un dispositivo en el que los dos prefijos de cliente sigan siendo distintos. Anote el origen en cada salto en lugar de confiar en una etiqueta de dentro o de fuera.

Tres ubicaciones y lo que cuesta cada una

La política puede vivir en la puerta de enlace que traduce, donde los orígenes originales aún son visibles. Puede vivir en el firewall anterior si el tránsito pasa a ser enrutado en lugar de traducido, lo que significa añadir rutas de retorno y eliminar la reescritura de origen. O puede aplicarse sobre la identidad en lugar de las direcciones, mediante un control autenticado que conoce al usuario o al dispositivo. Cada elección tiene un propietario y un modo de fallo, y solo las dos primeras mantienen la regla puramente sobre direcciones de origen.

Elija lo que elija, documente la regla junto con la dirección a la que corresponde. Una regla cuya suposición de dirección ha cambiado en silencio es peor que ninguna regla, porque sigue coincidiendo con el tráfico mientras protege algo completamente distinto.

Aceptación: un cliente permitido y otro denegado

Pruebe con un par de clientes, uno de cada grupo, y capture cómo llega cada uno al punto de aplicación. Conserve ambas tuplas junto al resultado de la regla, para que la evidencia muestre que la distinción sobrevivió y no que existe otro firewall. Repita la prueba tras un cambio de NAT o de enrutamiento, porque la dirección presentada es la parte que se rompe en silencio. Mantenga la autenticación donde haya que distinguir personas, ya que una dirección de origen es una entrada de política, no una prueba de identidad.

Escriba el punto de aplicación, el origen observado y la regla en el ticket. De lo contrario, el siguiente ingeniero añade un segundo firewall y la misma regla.