Está en la página 1de 13

Ordenamiento de NAT y Firewall de procesamiento

Comprender el orden en el que se produce fi rewalling y NAT es importante cuando las reglas
de con fi guración de NAT y cortafuego. El orden lógico básico se ilustra en la

figura Ordenamiento de NAT y Firewall de procesamiento . En la figura se representa también


en donde los lazos de tcpdump, ya que su uso como herramienta de solución

de problemas se describe más adelante en este libro en La captura de paquetes . Cada capa no
siempre es golpeado en configuraciones típicas fi, pero el uso de reglas

flotando o NAT saliente manual u otras con fi guraciones más complicados puede golpear cada
capa en ambas direcciones. El diagrama sólo cubre escenarios básicos

para entrante y saliente tráfico c.

Traf fi c de LAN a WAN se procesa como se describe en la siguiente lista más detallada. Si un
tipo de normas no existen o no son iguales, que se pasan por

alto.

• Puerto hacia delante o 1: 1 NAT en la interfaz de LAN (por ejemplo proxy o DNS redirige)

• Las reglas de firewall para la interfaz LAN: reglas flotantes entrante on LAN, entonces las
reglas para los grupos de interfaces, incluyendo la interfaz LAN, entonces las reglas

pestaña LAN.

• 1: 1 NAT o NAT saliente normas sobre la WAN

• reglas flotantes que coinciden salientes en la WAN

En este caso, no se aplican las reglas de puerto remite pestaña fi cortafuego WAN y WAN. Para
tráfico c

iniciado en la WAN, el orden es el mismo pero la dirección se invierte:

• puerto remite o 1: 1 NAT en la interfaz WAN (por ejemplo, servicios públicos)

• Las reglas de firewall para la interfaz WAN: reglas flotantes entrante en WAN, entonces las
reglas para los grupos de interfaz incluyendo la interfaz WAN, entonces las reglas de

la ficha WAN.

• 1: 1 NAT o NAT saliente normas sobre LAN

• reglas flotantes que coinciden salientes on LAN

tcpdump es siempre la primera y la última cosa para ver trá fi co, dependiendo de la dirección.
En primer lugar, en la interfaz entrante antes de cualquier procesamiento NAT

y cortafuegos fi, y por último en la interfaz de salida. Se muestra lo que es en el cable. (Ver La
captura de paquetes )

Ver también:

Ver Regla de procesamiento de pedidos para obtener más información sobre el orden de
procesamiento de reglas fi cortafuegos.
220 Capítulo Traducción de Direcciones de Red 13.

El libro pfSense, Liberación

Fig. 13.9: Orden de NAT y Firewall Processing

13.3. Ordenamiento de NAT y Firewall de procesamiento 221

El libro pfSense, Liberación

Extrapolando a interfaces adicionales

El diagrama anterior y las listas solamente ilustran una implementación básica LAN y WAN dos
interfaz. Cuando se trabaja con interfaces adicionales, se

aplican las mismas reglas. Trá fi co entre dos interfaces internas se comporta igual que LAN a
WAN trá fi co, aunque las reglas NAT defecto no se traducirán

trá fi co entre las interfaces internas por lo que la capa de NAT no hace nada en esos casos. Si
existen reglas de salida NAT ese partido trá fi co entre las

interfaces internas, se aplicará como se muestra.

Reglas para NAT

En el camino hacia una interfaz, NAT se aplica antes que las reglas fi cortafuego, así que si el
destino se traduce en el camino en adelante (por ejemplo, portuarias o 1: 1

NAT en la WAN), entonces las reglas cortafuego debe coincidir con el destino traducida. En el
caso típico de un puerto de reenvío a la WAN, esto significa que la regla debe

coincidir con un destino de la dirección IP privada de destino en la LAN. Por ejemplo, con un
puerto hacia delante para el puerto TCP 80 en WAN con una regla de

cortafuego añadido de forma automática, la figura Regla de firewall para Port Forward al
anfitrión LAN Muestra la regla cortafuego resultante sobre la WAN. La dirección IP

interna en el puerto hacia adelante es 10.3.0.15. Si el uso de puerto remite o 1: 1 NAT, reglas
de cortafuego en todas las interfaces WAN deben utilizar la dirección IP interna

como destino.

Fig. 13.10: reglas de firewall para Port Forward a Host LAN

A la salida de una interfaz, de salida NAT se aplica antes que las reglas fi cortafuego, por lo que
cualquier regla flotantes juego de salida en una interfaz debe coincidir

con la fuente después de que ha sido traducido por NAT saliente o 1: 1 NAT.

NAT La reflexión

NAT reflexión se refiere a la capacidad de acceder a servicios externos de la red interna


utilizando la dirección IP externa (normalmente público), lo mismo que si el

cliente estuviera en Internet. Muchos rewalls fi comerciales y de código abierto no son


compatibles con esta funcionalidad en absoluto. Cuando sea posible, la división
de DNS es el medio preferido para acceder a los recursos para que el cortafuego no está
involucrado en el acceso a los servicios internos internamente. pfSense tiene

un buen soporte para NAT reflexión, aunque algunos entornos requieren una infraestructura
DNS dividido para dar cabida a esta funcionalidad. Dividir el DNS está

cubierta al final de esta sección en DNS dividido .

Con fi gurar NAT reflexión

Para activar NAT La reflexión a nivel mundial:

• Navegar a Sistema> Avanzado sobre el Cortafuegos y NAT

• localizar el Traducción de Direcciones de Red sección de la página

• Con fi gura las opciones de reflexión NAT Re de la siguiente manera:

NAT Re modo de reflexión para el puerto reenvía Hay tres opciones disponibles para el modo
de reflexión NAT Re

para los delanteros del puerto, que son:

Inhabilitar no se realizará NAT La reflexión, pero puede ser activada en función de cada regla.

NAT + Proxy Permite NAT La reflexión usando un programa de ayuda para enviar paquetes a la
meta

del puerto hacia delante. Esto es útil en configuraciones donde la interfaz y / o la dirección IP
de la pasarela se utiliza para

la comunicación con el objetivo no puede determinarse con precisión en el

222 Capítulo Traducción de Direcciones de Red 13.

El libro pfSense, Liberación

tiempo las normas se cargan. Re no se crean reglas fl exión para su uso con el proxy para los
rangos de más de 500

puertos y no serán utilizados por más de 1000 puertos en total entre todos los desvíos de
puerto. Este modo no funciona

con UDP, sólo que con TCP. Debido a que este es un proxy, la dirección de origen del trá fi co,
como se ve por el servidor,

es la dirección IP fi cortafuegos más cercano al servidor.

pura NAT Permite NAT La reflexión usando reglas sólo NAT en pf dirigir paquetes a la

objetivo del puerto hacia delante. Tiene mejor escalabilidad, pero debe ser posible determinar
con precisión la dirección de la

interfaz y la puerta de enlace IP utilizado para la comunicación con el objetivo en el momento


se cargan las reglas. No hay

límites inherentes al número de puertos que no sean los límites de los protocolos. Todos los
protocolos disponibles para los
delanteros cuentan con el apoyo de puerto. Si los servidores están en la misma subred que los
clientes, la Habilitar NAT

saliente automático para la reflexión opción enmascarar el origen del trá fi co por lo que fluye
correctamente a través del

cortafuego.

Reflexión Tiempo de espera Esta opción sólo es relevante para NAT + Proxy de modo, y
controla el tiempo que la NAT

daemon proxy transcurrir antes de cerrar una conexión. Especificar el valor en cuestión de
segundos.

Habilitar NAT La reflexión de 1: 1 NAT Esta opción permite a los clientes en las redes internas
para alcanzar localmente

servicios alojados mediante la conexión a la dirección IP externa de un 1: 1 entrada NAT. Para


activar plenamente la función, compruebe tanto Habilitar

NAT La reflexión de 1: 1 NAT y Habilitar NAT saliente automático para la reflexión. Esta última
opción sólo es necesario si los clientes y

servidores se encuentran en la misma subred.

Habilitar NAT saliente automático para la reflexión Cuando está activada, esta opción activa
NAT adicional

reglas para el 1: 1 NAT reflexión y puro fl exión NATmode NAT Re para los delanteros del
puerto. Estas reglas adicionales enmascaran la dirección

de origen del cliente asegurarse de respuesta de trá fi co fluye de vuelta a través del
cortafuego. Sin esto, las conexiones entre el cliente y el

servidor se producirá un error que el servidor responderá directamente de vuelta al cliente


utilizando su dirección IP interna. El cliente va a

interrumpir la conexión, ya que espera una respuesta de la dirección IP pública.

• Hacer clic Salvar para activar las nuevas opciones de NAT reflexión

NAT Re Advertencias reflexión

NAT reflexión es un truco, ya que los bucles de trá fi co a través del cortafuego cuando no es
necesario. Debido a las limitadas opciones PF prevé la

adaptación de estos escenarios, hay algunas limitaciones en el pfSense NAT + Proxy reflexión
aplicación. Intervalos de puertos de más de 500 puertos

NAT no tienen reflejo activado en modo NAT + proxy, y que el modo está también limitada a
trabajar sólo con TCP. Los otros modos requieren NAT

adicional a suceder si los clientes y los servidores están conectados a la misma interfaz del
cortafuego. Este NAT adicional oculta la dirección de origen

del cliente, haciendo que el trá fi co parece originarse en el cortafuego en su lugar, por lo que
la conexión se puede establecer correctamente.
Dividir el DNS es la mejor manera de acomodar grandes rangos de puertos y 1: 1 NAT. El
mantenimiento de una infraestructura de DNS dividido es requerido por muchos fi

comercial rewalls incluso, y por lo general no es un problema.

DNS dividido

Una alternativa preferible a NAT reflexión está desplegando una infraestructura DNS dividida.
Dividir el DNS se refiere a un DNS con fi guración donde, por un nombre

de host dado, DNS de Internet público resuelve a la dirección IP pública, y DNS en la red
interna se resuelve a la dirección IP interna y privada. Los medios para

conseguir esto puede variar dependiendo de la especificación CS de la infraestructura DNS de


una organización, pero el resultado final es el mismo. NAT reflexión no

es necesario ya que los nombres de host a resolver las direcciones IP privadas dentro de la red
y los clientes pueden llegar a los servidores directamente. Dividir el

DNS permite a los servidores de ver la verdadera dirección IP del cliente, y las conexiones
entre servidores y clientes en la misma subred irá directamente, en lugar

de la participación innecesariamente el cortafuego.

13.4. NAT La reflexión 223

El libro pfSense, Liberación

El único caso que no funciona correctamente con la división de DNS es cuando los números de
los puertos externos e internos son diferentes. Con la división de DNS, el número de

puerto tiene que ser el mismo en ambos lugares.

De resolución de DNS Forwarder / anulaciones

Si pfSense está actuando como el servidor DNS para los hosts internos, a continuación, el
anfitrión de las anulaciones en el Resolver DNS o promotor de DNS puede proporcionar la
funcionalidad

de DNS dividido. Para agregar una anulación de la resolución DNS:

• Navegar a Servicios> Resolución DNS

• Hacer clic lo de abajo anulaciones de acogida para llegar a la página de opciones del host
Override

• Con fi gura la anulación de acogida, según sea necesario, utilizando la dirección IP interna del
servidor. Ver anulaciones de acogida . Figura

Añadir resolución de DNS de anulación para example.com muestra un ejemplo de una


anulación de DNS para example.com y

www.example.com.

• Hacer clic Salvar

• Hacer clic Aplicar cambios


Fig. 13.11: Añadir resolución de DNS de anulación para example.com

El DNS Forwarder funciona de forma idéntica en este sentido. Si el Forwarder DNS está
activado en lugar de la resolución DNS, agregue las anulaciones de allí.

Se requiere un reemplazo para cada nombre de host en uso detrás del cortafuego.

Los servidores DNS internos

Cuando se utiliza un servidor DNS independiente en una red interna, tales como Microsoft
Active Directory, las zonas deben ser creados por el administrador del

servidor DNS para todos los dominios alojados dentro de la red, junto con todos los demás
registros de los

224 Capítulo Traducción de Direcciones de Red 13.

El libro pfSense, Liberación

dominios (A, CNAME, MX, etc.).

En entornos que ejecutan el servidor DNS BIND en el DNS público está alojado en el mismo
servidor que el DNS privada, vistas de BIND característica se utiliza para

resolver DNS diferente para hosts internos que las externas. Otros servidores DNS pueden
apoyar una funcionalidad similar. Comprobar su documentación para

obtener información.

NAT salientes

De salida NAT, también conocido como Fuente NAT, pfSense controla cómo se traducirá la
dirección de origen y los puertos de trá fi co dejando una interfaz.

Para con fi gura de salida NAT, vaya a Firewall> NAT, sobre el saliente lengüeta. Hay cuatro
posibles modos para la salida de NAT:

Automático de salida NAT La opción por defecto, que realiza automáticamente NAT de inter
interna

caras, tales como LAN, a las interfaces externas, tales como WAN.

Híbrido de salida NAT Utiliza las reglas manuales mientras que también el uso de reglas
automáticas para tráfico c No corresponde

por reglas introducidas manualmente. Este modo es el más flexible y fácil de usar para los
administradores que necesitan un poco de control

adicional, pero no quieren para gestionar toda la lista manualmente.

Manual de salida NAT Logros las reglas introducidas manualmente, y nada más. Ofrece la
mayor parte

control, pero puede ser difícil de manejar y los cambios realizados en las interfaces internas o
WAN deben tenerse en cuenta en las

reglas de la mano. Si la lista está vacía cuando se cambia de automático a manual, la lista se
rellena con normas equivalentes al
conjunto generado automáticamente.

Desactivar la salida NAT Desactiva todos los NAT saliente. Es útil si el cortafuego contiene sólo
ad- enrutable

vestidos (por ejemplo, direcciones IP públicas) en todas las redes LAN y WAN. Al cambiar el
Modo Valor,

haga clic en el Salvar botón para almacenar el nuevo valor.

En redes con una única dirección IP pública por la WAN, por lo general hay ninguna razón para
activar NAT saliente manual. Si algún control manual es necesario, el

modo híbrido es la mejor opción. En los entornos con múltiples direcciones IP públicas y
requisitos complejos NAT, de salida manual de NAT ofrece más fi el control

de grano fino sobre todos los aspectos de la traducción. Para entornos de alta disponibilidad
utilizando con la carpa, es importante NAT trá fi co de salida a una

dirección CARP VIP, como se discutió en Alta disponibilidad . Esto se puede lograr en cualquier
híbrido o el modo manual. Al igual que con otras reglas de pfSense,

reglas NAT salientes son considerados desde la parte superior de la lista de abajo, y se usa el
primer partido de fi. Incluso si las reglas están presentes en la pantalla

de salida NAT, que no serán aceptadas a menos que el Modo se establece en

Híbrido de salida NAT o NAT de salida manual.

Nota: NAT saliente sólo controla lo que ocurre con trá fi co ya que deja una interfaz. Lo hace
no controlar la interfaz a través del cual tráfico c saldrá del cortafuego. Eso está en

manos de la tabla de enrutamiento ( Rutas estáticas ) O encaminamiento de políticas ( la


política de enrutamiento ).

Por defecto Reglas de salida NAT

Cuando se establece en el valor por defecto Automático de salida NAT modo, pfSense
mantiene un conjunto de reglas de NAT para traducir tráfico c dejar cualquier

red interna a la dirección IP de la interfaz WAN que las fi c hojas TRAF. redes de rutas estáticas
y las redes VPN de acceso remoto también se incluyen en las reglas

NAT automáticas. Cuando saliente NAT es con fi gurado para Automático o Híbrido modos, las
reglas automáticas se presentan en la sección inferior de la pantalla

con la etiqueta Reglas automáticas.

Si la lista de reglas de salida NAT está vacía, el cambio a Manual de salida NAT y el ahorro va a
generar un conjunto completo de normas equivalentes a las reglas

automáticas.

13.5. NAT salientes 225

El libro pfSense, Liberación

puerto estático
Por defecto, pfSense reescribe el puerto de origen en todas las conexiones salientes, excepto
para el puerto UDP 500 (IKE para VPN trá fi co). Algunos sistemas

operativos hacen un mal trabajo de la aleatorización de puerto de origen, si lo hacen en


absoluto. Esto hace que la dirección IP spoo fi ng fácil y hace que sea posible fi

huella digital alberga detrás del cortafuego de su salida trá fi co. Reescribir el puerto de origen
elimina estos potenciales (aunque improbable) vulnerabilidades de

seguridad. reglas NAT salientes, incluyendo el

reglas automáticas, mostrarán en el puerto estático columna de reglas establecidas para


aleatorizar el puerto de origen.

puerto de origen aleatorización rompe algunas aplicaciones raras. El valor por defecto de
salida automática NAT conjunto de reglas desactiva el puerto

aleatorización fuente de UDP 500, ya que casi siempre se rompe por reescribir el puerto de
origen. saliente

reglas NAT que preservan el puerto fuente original se denominan puerto estático reglas y
tienen en el estado en el Estático

Puerto columna. Todos los demás trá fi co tiene el puerto de origen reescrito por defecto.

Otros protocolos, como los utilizados por las consolas de juegos, pueden no funcionar
correctamente cuando se reescribe el puerto de origen. Para desactivar esta funcionalidad,
utilice el puerto

estático opción. Para añadir una regla para un dispositivo que requiere puertos de origen
estáticas:

• Navegar a Firewall> NAT, Saliente lengüeta

• Seleccionar Híbrido de salida NAT generación de reglas

• Hacer clic Salvar

• Hacer clic para añadir una nueva regla de NAT a la parte superior de la lista

• Con fi gura la regla para que coincida con el trá fi co que requiere puerto estático, como una
dirección de origen de un PBX o una consola de juegos (Ver Trabajar

con Manual salientes reglas NAT abajo)

• Comprobar puerto estático en el Traducción sección de la página

• Hacer clic Salvar

• Hacer clic Aplicar cambios

Después de hacer ese cambio, se conservará el puerto de origen en el tráfico saliente fi c juego
la regla. La mejor práctica es utilizar reglas estrictas cuando se utiliza el puerto

estático para evitar cualquier posible conflicto si dos anfitriones locales utilizan el mismo
puerto de origen para hablar con el mismo servidor remoto y el puerto utilizando la

misma dirección IP externa.


Desactivación de salida NAT

Si se utilizan direcciones IP públicas en las interfaces locales, y por lo tanto no se requiere NAT
para pasar trá fi co a través del cortafuego, desactivar NAT para enrutar

la subred. Esto se puede lograr de varias maneras:

• Si NAT no es necesario para cualquier interfaz, establecer el modo NAT saliente a Inhabilitar

• El uso de híbridos de salida NAT, con un conjunto de reglas No hacer NAT puede desactivar
NAT para hacer coincidir tráfico c

• Utilizar el manual de salida NAT, eliminar (o no crean) cualesquiera reglas NAT que coinciden
con las subredes que puedan establecerse rutas en cualquiera de los casos anteriores,

de salida NAT ya no estarán activas para aquellas direcciones IP de origen y pfSense


direccionará entonces direcciones IP públicas sin necesidad de traducción.

Trabajar con Manual salientes reglas NAT

reglas NAT salientes son muy flexibles y son capaces de traducir trá fi co de muchas maneras.

226 Capítulo Traducción de Direcciones de Red 13.

El libro pfSense, Liberación

Las reglas NAT se muestran en una sola página y la Interfaz columna es una fuente de
confusión para algunos; Como tráfico c deja una interfaz, sólo las reglas

NAT salientes fijados para que específica Interfaz son consultados.

Hacer clic desde la página de salida NAT para añadir una regla a la parte superior de la lista.
Hacer clic añadir una regla a la parte inferior.

Coloque normas especí fi cas en la parte superior, y las reglas más generales en la parte
inferior. Las reglas son procesadas por el cortafuego a partir de la parte superior de la lista y
trabajando

hacia abajo, y la primera regla fi para que coincida se utiliza. Las reglas pueden ser
reordenados para que coincida con la forma deseada.

Las opciones para cada regla de salida NAT son:

Discapacitado Alterna si esta regla está activa.

No hacer NAT Al activar esta opción hace que los paquetes que coincidan con la regla no NAT
tiene que aplicar como

salir. Esto es necesario si el trá fi co de otro modo que coincida con una regla de NAT, pero no
debe tener NAT AP- ejercía. Un uso común para esto es

agregar una excepción de la regla de manera que las direcciones IP fi cortafuego no reciben
NAT aplicados, especialmente en el caso de la carpa, donde

tales NAT romper la comunicación por Internet desde un nodo secundario mientras está en el
modo de copia de seguridad.
Interfaz La interfaz donde se aplicará esta regla cuando NAT trá fi co se va a través de esta
interfaz. Típicamente

este Iswan o un OPTWAN, pero en algunos casos especiales que podrían ser LAN u otra
interfaz interna.

Protocolo En la mayoría de los casos, de salida NAT se aplicará a alguna protocolo, pero a
veces es necesario

restringir el protocolo sobre el cual el NAT actuará. Por ejemplo, sólo para realizar puerto
estático NAT para UDP tráfico c de un PBX.

Fuente La Fuente es la red local que se habrá traducido su dirección ya que deja el
seleccionado

Interfaz. Esto es típicamente una subred LAN, DMZ, o VPN. El puerto de origen casi siempre se
deja en blanco para que coincida con todos los puertos.

Este campo es compatible con el uso de alias si el Tipo se establece en Red.

Nota: Evitar el uso de una dirección de origen de alguna como que también coincidirá con trá fi
co de la fi cortafuegos en sí. Esto causará problemas

con vigilancia de puerta de enlace y otra fi cortafuegos iniciada tráfico c.

Destino En la mayoría de los casos, el Destino permanece establecido a alguna de manera que
tra fi co ir a ninguna parte de

esta Interfaz serán traducidos, pero el destino puede ser restringido, según sea necesario. Por
ejemplo, para traducir de una manera determinada

cuando se va a un destino específico, por ejemplo, sólo haciendo puerto estático NAT para
direcciones SIP tronco. Este campo es compatible con el

uso de alias si el Tipo se establece en Red.

Traducción los Dirección campo interior de la Traducción sección controla lo que ocurre con la
fuente

dirección del tráfico coincidiendo esta regla c. Por lo general, esto se establece en interfaz
Dirección por lo que el trá fi co se traduce a la dirección

IP Interfaz, por ejemplo, la dirección IP WAN. los Dirección desplegable también contiene
todas las direcciones IP de fi ne virtuales, alias de host, y otra

subred para introducir manualmente una subred para la traducción.

Nota: Un alias que contiene subredes no se puede utilizar para la traducción. Sólo el anfitrión
de alias o una sola subred introducida manualmente puede

ser utilizado.

El uso de un alias de host o subred introducida manualmente, una regla de NAT saliente puede
traducir a un grupo de direcciones. Esto puede ayudar

en grandes implementaciones NAT o en áreas donde se requiere puerto estático para varios
clientes. Cuando se traduce a un alias de host o subred,
una Opciones de la piscina desplegable está disponible con varias opciones. Solamente round
Robin tipos trabajan con los alias de host. Cualquier tipo

se puede utilizar con una subred.

Defecto ¿No definen ningún algoritmo específico para la selección de una dirección de la
traducción

piscina.

round Robin Recorre cada dirección de traducción potencial en el alias o subred en

giro.

13.5. NAT salientes 227

El libro pfSense, Liberación

Round Robin con pegajoso Dirección Funciona igual que round Robin pero mantiene la

misma dirección de traducción de una dirección de origen determinado, siempre y cuando los
estados de la fuente de acogida existen.

Aleatorio Selecciona una dirección de traducción para el uso de la subred de forma aleatoria.

Al azar con pegajoso Dirección Selecciona una dirección al azar, pero mantiene la misma

Traducción de direcciones de una dirección de origen determinado, siempre y cuando los


estados de la fuente de acogida existen.

fuente Hash Utiliza un hash de la dirección de origen para determinar la dirección de la


traducción, ensuring

que la dirección traducida es siempre el mismo para una dirección IP determinada fuente.

máscara de bits Se aplica la máscara de subred y mantiene la última porción idéntica. Por
ejemplo si el

dirección de origen es 10.10.10.50 y la subred traducción es 192.2.0.0/24, la regla va a cambiar


la dirección

de 192.2.0.50. Esto funciona de manera similar a 1: 1 NAT, pero sólo en la dirección de salida.

Puerto Especi fi ca un específico fuente puerto para la traducción. Esto casi siempre se deja en
blanco, pero podría ser necesario

si el cliente selecciona un puerto de origen al azar, pero el servidor requiere un puerto de


origen especí fi co.

puerto estático Hace que el puerto de la fuente original del trá fi co cliente que se mantiene
después de la dirección IP de origen

ha sido traducido. Algunos protocolos requieren esto, como IPsec sin NAT-T, y algunos
protocolos se comportan mejor con esto,

como SIP y RTP. Al activar esta opción desactiva la Puerto cuadro de entrada.
Sin sincronización XML-RPC Esta opción sólo es relevante si una con fi guración HA Cluster está
en uso, y debe

omitir lo contrario. Cuando se utiliza un clúster de HA con la sincronización con fi guración,


comprobando de esta caja evitará que la

regla de ser sincronizado con los otros miembros de un clúster (ver Alta disponibilidad ).
Normalmente todas las reglas deben

sincronizar, sin embargo. Esta opción sólo es eficaz en nodos maestros, lo hace no prevenir
una regla que se sobrescriba en los

nodos esclavos.

Descripción Una referencia de texto opcional para explicar el propósito de esta regla. Estas
reglas pueden

acomodar a casi cualquier escenario NAT, grande o pequeña.

Seguimiento de los cambios a las reglas de NAT salientes

Como se ha mencionado en la figura Sellos de reglas de cortafuegos Tiempo para las reglas de
cortafuego, se añade una marca de tiempo a un saliente de entrada NAT que

indica cuándo se creó o modificados por última vez. Esta marca de tiempo muestra el usuario
que creó la regla, y la última persona que editar la regla. Cuando se cambia de

modo automático de salida NAT para el modo NAT de salida manual, las reglas creadas se
marcan como ser creado por ese proceso.

La elección de una fi guración Con NAT

La mejor fi guración NAT con un despliegue determinado depende principalmente del número
de direcciones IP públicas disponibles y el número de servicios

locales que requieren acceso entrante desde Internet.

Única dirección IP pública por la WAN

Cuando sólo una única IP pública por la WAN está disponible, las opciones de NAT son
limitadas. 1: 1 reglas NAT se puede utilizar con direcciones IP WAN, pero que pueden tener

inconvenientes. En este caso, sólo se recomienda el uso de redirecciones de puertos.

228 Capítulo Traducción de Direcciones de Red 13.

El libro pfSense, Liberación

Múltiples direcciones IP públicas por la WAN

Cuando varias direcciones IP públicas están disponibles por la WAN, numerosas opciones están
disponibles para la entrada y salida de NAT con fi guración. Puerto

hacia delante, 1: 1 NAT, y el híbrido o Manual de salida NAT puede todo ser deseable,
dependiendo de las necesidades del sitio.

NAT y Protocolo de compatibilidad


Algunos protocolos no funcionan bien con NAT y otros no van a funcionar. protocolos
problemáticas incrustar direcciones IP y / o números de puerto dentro de los

paquetes (por ejemplo, SIP y FTP), algunos no funcionan correctamente si se reescribe el


puerto de origen (SIP desde una PBX, IPsec), y algunos son difíciles

debido a las limitaciones de pf (PPTP ). Esta sección cubre una muestra de protocolos que
tienen di fi cultades con NAT en pfSense, y cómo evitar estos

problemas cuando sea posible.

FTP

FTP plantea problemas con ambos rewalls NAT y fi Debido al diseño del protocolo. FTP fue
diseñado inicialmente en la década de 1970, y la

corriente estándar de fi nir las especificaciones del protocolo fue escrito en 1985. Desde FTP
fue creado más de una década antes de la NAT, y

mucho antes de rewalls fi eran comunes, actúa de maneras que son muy antipáticos hacia NAT
y rewalls fi.

También podría gustarte