Introducción: Network Address Translation (NAT)
Resolution
Después de configurar el cortafuegos siguiendo las anteriores entregas de la serie Getting Started, es posible que desee iniciar la configuración de servidores. A menos que tenga el lujo de poseer una subred IP pública suficientemente grande como para albergar todos los hosts internos, los datos a continuación enseñarle cómo configurar la traducción de direcciones de red (NAT) o traducción de dirección de puerto (PAT) para hosts accesibles desde el exterior, o usar una dirección IP específica a internet.
En esta entrega, voy a comentar algunas situaciones que pueden ser útil para determinar cómo configurar NAT o PAT para servir mejor a sus necesidades y lanzar en un par de advertencias a tener en cuenta.
Muchos a uno, ocultar NAT, Source NAT
Para cubrir los aspectos básicos, ocultar NAT es el uso más común de la dirección de traducción que hay. Todas las subredes internas detrás de una sola IP pública externa se esconde y se verá similar a esta:
Esta política NAT traducirá todas las sesiones que se origina en la zona de confianza, ir a la zona untrust y cambia la dirección origen a la IP asignada a la interfaz física externa. También le aleatorizar el puerto de origen.
Devolver paquetes serán automáticamente reverso traducido como cortafuegos mantiene una tabla de estado seguimiento de todas las sesiones activas y sus acciones de NAT
NAT muchos a muchos
Una variación en la piel de la simple política de NAT, es agregar más direcciones de fuente si más están disponibles. Si, por ejemplo, su ISP proporciona una subred pública de 29 o más, tienes más direcciones IP que pueden ser utilizadas para todo tipo de cosas. Si su red interna es bastante grande, estas direcciones adicionales pueden ser necesarias para evitar la sobresuscripción del pool NAT.
Para esta configuración se cambia el tipo de dirección de 'Interfaz' 'traducido dirección.' Luego se añaden las direcciones IP disponibles como un rango IP o una subred IP:
El firewall Seleccione una IP de la piscina disponible basada en un hash de la dirección IP origen. Esta dirección fuente seguirá siendo el mismo para todas las sesiones desde IP fuente. El puerto de origen todavía ser aleatorios.
Si los puertos fuente necesitan permanecer igual (algunas aplicaciones pueden requerir un puerto fuente específica) se puede establecer el tipo de traducción para IP dinámica, que conservará el puerto de origen del cliente por sesión. Se le asigna la dirección traducida por ' siguiente disponible ' que significa que hay algunas advertencias:
- No más de 32,000 direcciones IP consecutivas son compatibles
- La piscina de direcciones traducido debe ser del mismo tamaño o mayor que su número interno de los ejércitos, como cada host interno se le asigna su propia dirección traducida
Si los criterios anteriores se cumplen generalmente pero a veces pueden ser rotos, una copia de seguridad puede establecerse no a Dynamic IP y el puerto. Tanto la dirección de traducción y las opciones de dirección de la interfaz están disponibles, el valor predeterminado es ninguno:
NAT uno a uno, NAT estática
Si necesita disponer de un servidor de internet, como un local SMTP o servidor Web, una política NAT uno a uno necesita crearse remitirá las conexiones entrantes a un servidor específico. Hay algunas maneras para lograrlo:
Política bidireccional:
En una política bidireccional, se crea una directiva NAT estática salida regular al igual que las mencionadas políticas NAT, y se fija la bandera bi-direccional, que permite el sistema para crear una directiva entrante implícita (invisible).
La política será fuente de confianza y se destinarán para untrust, con una dirección fuente IP interna y fuente traducción siendo su dirección pública del NAT del servidor. Se creará una política implícita con una zona de fuente de untrust y el destino de cualquier IP de destino de la dirección pública de NAT y traducción a dirección IP del servidor de destino.
Es una manera fácil de crear varias traducciones uno a uno y funciona perfectamente si varios servidores tienen su propia dirección IP pública única, que nos lleva a:
Política de la Uni-direccional:
NAT unidireccional permite un poco más control sobre la política que bidireccional y permite PAT o traducción de direcciones de puerto. PAT le permite compartir una única dirección IP pública a través de diversos servicios internos.
En las siguientes 3 reglas puede ver 3 ejemplos diferentes de entrante NAT estático:
- La regla #1 es una regla tradicional de uno a uno que traduce todos los puertos entrantes al servidor interno, manteniendo el puerto de destino
- La regla #2 traduce sólo las conexiones entrantes en el puerto de destino 80 al servidor interno en el puerto 8080
- La regla #3 traduce las sesiones entrantes para la misma dirección IP pública que la regla #2, pero para el puerto 25 de destino a un servidor interno diferente mientras se mantiene el puerto de destino 25
- ¿Por qué se establecen las zonas de destino en untrust y ¿qué pasa con las interfaces de destino?
- '' Utilizable como dirección de destino para un entrantes (untrust para untrust) NAT
La política de seguridad debe configurarse para la zona de la fuente es untrust, destino zona (destino final) es la confianza y el destino las direcciones son las direcciones públicas, pre-NAT.
NAT de origen y de destino
En algunos casos puede requerirse para llevar a cabo origen y destino NAT al mismo tiempo. Un ejemplo común es una situación de giro de 180 grados, donde hosts internos tiene que conectar a un servidor interno, que está en la misma red que el cliente, en su dirección IP pública.
Ya hay un gran artículo y un tutorial de vídeo que cubren U-Turn con más detalle, pero la breve descripción es la siguiente:
Para poder llegar a recursos internos de una IP pública, una nueva política NAT hay que crear para acomodar la confianza para untrust traducción.
Si traducción de fuente no está incluido en esta política, el servidor recibe los paquetes con la dirección de la fuente original, haciendo que el servidor envíe paquetes de respuesta directamente al cliente.
Esto crea un lazo asimétrico: finalizará la sesión de firewall y cliente de servidor de cliente firewall como viola TCP cordura cheques.
La solución es añadir la traducción de la fuente a, por ejemplo, la IP del firewall, para que paquetes de respuesta del servidor se envían al servidor de seguridad, que permite sesiones de 'estadas'.
Bono: NAT en un VWire
NAT también puede ser implementada en un VWire si la puede editar la tabla de enrutamiento en el router (un router ISP puede no permitirlo). Idealmente, usted tendría un router en cada extremo de la VWire para mantener las cosas simples, pero si tienes ganas de un reto, también puede conseguir que funcione con un enrutador de nivel superior:
Entre los dos routers deben crear una subred punto a punto pequeño, por ejemplo, 10.0.0.0/30. Asignar a cada router una IP y agregar rutas la traduce direcciones IP apuntada a la IP del router remoto en el router ubicado en el lado traducido. por ejemplo. agregar una ruta de 198.51.100.1 del router untrust, apuntada a la IP del router de confianza. El firewall se encargará del resto.
ADVERTENCIAS
- La resolución de la zona se consigue mediante búsquedas de rutas. Cuando un paquete es recibido en el firewall, se realiza una búsqueda de ruta para comprobar que la fuente subred y subred de destino se dirigen a, y la zona apropiada es asignada a la sesión. En el caso de tráfico entrante de internet, la zona de la fuente será untrust, se señala la ruta de predeterminada 0.0.0.0/0 a la interfaz untrust y la IP de destino dirección pre-NAT, es también untrust ya que es la IP a la interfaz no es de confianza (198.51.100.0/24 en los ejemplos anteriores)
- El uso de las interfaces de destino en las directivas NAT puede ayudar a prevenir conflictos cuando se utilizan directivas NAT similares. EG. Si existen dos interfaces externas, a dos ISPs diferentes, manteniendo diferentes direcciones IP públicas, dos normas idénticas de NAT salientes pueden configurar.
- En caso de que se utilice una IP NAT que no esté físicamente configurada en una interfaz (ej. interfaz 198.51.100.1, NAT para el servidor 198.51.100.5), el Firewall enviará paquetes ARP gratuitos para informar a los vecinos que aloja una dirección IP y responderá a las solicitudes ARP de los dispositivos upstream. Gratuito ARP se puede también accionar manualmente:
admin @ MyFW > test ARP interfaz gratuita ethernet1/1 IP 198.51.100.6
PRECAUCIÓN: si una regla NAT está configurada para aplicar la traducción a una subred que no está configurada en una interfaz, el cortafuegos enviará ARP gratuitos para todas las direcciones IP de la subred.
1 Arps fueron enviados
- Debido a que el firewall provee proxy resolución ARP para direcciones figuran en la dirección de destino para el destino (entrante) NAT, la subred de la dirección de destino debe coincidir con la subred de destino traducción. No está permitido utilizar ' any ' como dirección de destino.
- Al crear directivas NAT para clientes internos para llegar a servidores en la DMZ o red de confianza a través de sus IPS públicas, asegúrese de colocarlos por encima de la Directiva Hide-NAT independientemente.
Exceso de suscripción
Suscripción excesiva se produce cuando el cortafuegos ha traducción de múltiples sesiones simultáneas (dos o más) compartiendo el mismo par de dirección y puerto IP y proporciona escalabilidad cuando existen muy pocas direcciones IP públicas por la cantidad de sesiones va a crear. Eg. normalmente la cantidad máxima de sesiones simultáneas sería 64K (65,000 puertos fuente menos 1024 puertos de 'servidor'). exceso de suscripción, dependiendo de la plataforma, permite hasta 512 K sesiones concurrentes por IP con un oversubscription de 8 x.
Algunos artículos relacionados:
Cómo cambiar la tasa de sobresuscripción de NAT
Cómo comprobar la sobresuscripción en una regla NAT
¡Gracias por leerme!
Reaper