Problemas del uso de traductores de direcciones de red (NAT) - The Cable Guy – Octubre de 2004

Problemas del uso de traductores de direcciones de red (NAT)

Publicado: octubre 1, 2004

Por The Cable Guy

Para obtener una lista e información adicional acerca de todas las columnas de The Cable Guy, haga clic aquí

En esta página

Introducción
Funcionamiento de NAT
NAT y la seguridad
Problemas del uso de un servidor tras un NAT
Resumen
Para obtener más información

Introducción

Los traductores de direcciones de red (NAT) permiten que los equipos de redes privadas tengan acceso a recursos de Internet que no están accesibles directamente desde Internet. Los NAT permiten reutilizar el espacio de direcciones privadas IPv4 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) en las redes privadas, reduciendo así la presión de tener que utilizar direcciones IPv4 públicas para todos los nodos que deseen tener acceso a recursos de Internet. Si bien el uso de NAT es claramente ventajoso, esta capacidad también tiene sus inconvenientes.

Originalmente, Internet se diseño para un espacio de direcciones globalmente único. Todas las interfaces que se conectan a Internet tienen una dirección exclusiva basada en la subred a la que estaba unida la interfaz. Independientemente de cómo se agrupen las subredes en las redes privadas unidas directamente a Internet, siempre se puede tener acceso a la interfaz a través de su dirección global exclusiva.

El uso de NAT y el espacio de direcciones privado constituye una infracción del espacio de dirección exclusiva global. Para cada red que utilice NAT, se vuelve a utilizar el espacio de dirección privada. Esto quiere decir que varias interfaces conectadas a distintas redes pueden tener la misma dirección. Si bien estas redes con direcciones privadas no son visibles desde Internet, podrían ser visibles entre sí. La combinación de varias redes privadas en una sola red puede crear conflictos de direcciones (varias subredes con el mismo prefijo de dirección o entradas ambiguas en la tabla de enrutamiento).

Imaginemos que la Compañía A usa el espacio de dirección privada 10.0.0.0/8 para su red interna. La Compañía B también utiliza el espacio de dirección privada 10.0.0.0/8. Si las compañías A y B se fusionan, es muy probable que se produzcan conflictos de direcciones. La compañía resultante debe cambiar el número de parte de la red combinada, proceso costoso y largo. Aunque el uso del Protocolo de configuración dinámica de host (DHCP) en la mayoría de los nodos IP basados en host ayuda, los nodos configurados estadísticamente, como los servidores, se deben volver a configurar manualmente y la infraestructura de enrutamiento se debe volver a diseñar.

Funcionamiento de NAT

El funcionamiento básico de un NAT, descrito en el artículo sobre el Traductor de direcciones de red (NAT) de Windows 2000 (The Cable Guy, marzo de 2001), es el siguiente:

• Para los paquetes salientes, el NAT cambia la dirección de origen privada a una dirección de origen pública y el número de puerto del Protocolo de control de transporte (TCP) o el Protocolo de datagramas de usuario (UDP) a un valor especificado por NAT. Para los paquetes entrantes, el NAT cambia la dirección de destino pública a la dirección original pública y el número de puerto de destino TCP o UDP a su valor original.

Una tabla de traducción del NAT proporciona las asignaciones entre direcciones las públicas y privadas y los números de puerto TCP/UDP. El NAT elimina todo el tráfico entrante no destinado a una dirección asignada al NAT que no coincida con una de las entradas de la tabla de traducción.

Si un equipo situado tras el NAT (conectado a una subred separada de Internet por el NAT) inicia la comunicación con un nodo de Internet, el NAT crea automáticamente la entrada adecuada en la tabla de traducción para permitir el reenvío del tráfico de respuesta al equipo de inicio. Como ejemplo se puede citar un cliente Internet que explore Internet. El tráfico del Sistema de nombres de dominio (DNS) y del Protocolo de transferencia de hipertexto (HTTP) que inicia el equipo cliente crea automáticamente entradas en la tabla de traducción, con lo que permite que el equipo cliente tenga acceso a los recursos de Internet sin tener una conexión de acceso directa con Internet. Por lo tanto, los equipos cliente con NAT pueden, por lo general, tener acceso a servidores que son accesibles directamente en Internet sin que se produzcan problemas.

Para que los servidores situados tras un NAT sean accesibles desde Internet, debe configurar el NAT con entradas de traducción estáticas en la tabla. Consulte el artículo sobre la configuración del acceso a servicios situados tras un Traductor de direcciones de red (NAT) (The Cable Guy, mayo de 2003) para ver un ejemplo.

NAT y la seguridad

Como los NAT rechazan todo el tráfico que no coincida con una entrada de la tabla de traducción, son considerados dispositivos de seguridad. Sin embargo, los NAT no pueden sustituir a los servidores de seguridad. Normalmente, hay dos conjuntos de puertos TCP y UDP abiertos en el NAT:

• El conjunto de puertos correspondiente al tráfico que se traduce, especificado en la tabla de traducción. Contiene los puertos dinámicos que abren los clientes situados tras el NAT y los puertos estáticos configurados para los servidores situados tras el NAT.

• El conjunto de puertos correspondiente a aplicaciones y servicios en ejecución en el NAT.

Los puertos estáticos para los servidores situados tras el NAT y los puertos para las aplicaciones y servicios que se ejecutan en el NAT lo hace vulnerable a los ataques. Los puertos dinámicos no son tan vulnerables porque es difícil que un atacante adivine cuando se abrirán. Si el NAT es un equipo en lugar de un dispositivo dedicado (por ejemplo, un dispositivo de puerta de enlace de Internet), el equipo está expuesto a los ataques.

Por lo tanto, es recomendable que el NAT se use combinado con un servidor de seguridad y que los clientes de la red privada usen también servidores de seguridad basados en host para evitar la difusión de software malintencionado en la red privada.

Problemas del uso de un servidor tras un NAT

Como ya se ha descrito en este artículo, los equipos clientes que usen NAT y tengan acceso a servidores conectados a Internet no suelen tener problemas. Por el contrario, sí se pueden producir problemas si los servidores se encuentran tras un NAT en las situaciones siguientes:

• Aplicaciones para varios equipos

• Aplicaciones del mismo nivel

• NAT-T de IPSec

Aplicaciones para varios equipos

Las aplicaciones para varios equipos son aquellas en que varios equipos acuerdan comunicarse juntos a través de un servidor central para una finalidad concreta. Se pueden citar como ejemplos una aplicación de colaboración o un juego en red para varios jugadores. Si el servidor central y algunos de los clientes están tras el NAT, el uso de direcciones privadas puede crear problemas de configuración.

Por ejemplo, imaginemos que un servidor de colaboración está situado tras un NAT y hay ciertos clientes situados tras el mismo servidor y otros que están situados en Internet. Como consecuencia del espacio de direcciones privado situado tras el NAT y el servidor situado tras el NAT, se debe configurar lo siguiente:

• Entradas estáticas en la tabla de traducción que asignen la dirección pública del NAT y los números se puerto de la aplicación del servidor a la dirección privada del servidor y los números de puerto de la aplicación del servidor.

• Para que los clientes conectados a Internet tengan acceso al servidor mediante su nombre DNS, se deben agregar entradas al DNS de Internet, de manera que el nombre del servidor (por ejemplo, collabsrv.example.com) se puedan resolver como la dirección pública del NAT.

• Para que los clientes conectados a la red privada tengan acceso al servidor mediante su nombre DNS, se deben agregar entradas al DNS de la red privada, de manera que el nombre del servidor se pueda resolver como la dirección privada del servidor.

La configuración de DNS no es necesaria si se usa la dirección privada o pública real del servidor al iniciar la conexión desde los equipos cliente. Con todo, el uso de direcciones IPv4 para establecer conexiones con servidores es complicado para los usuarios finales; hay que garantizar que se indica a los clientes de Internet que utilicen la dirección pública y a los clientes situados tras el NAT que utilicen la dirección privada.

Incluso cuando se ha definido toda esta configuración, los clientes situados tras el NAT y los clientes conectados a Internet no utilizan la misma dirección IPv4 del servidor. Si la aplicación informática de colaboración debe usar una dirección IPv4 común por razones de configuración, sincronización o seguridad, se pueden seguridad produciendo problemas de comunicación.

Aplicaciones del mismo nivel

Otro problema de los NAT es cómo afectan a las aplicaciones del mismo nivel. En el modelo de comunicación del mismo nivel, los equipos del mismo nivel pueden actuar como cliente o como servidor y comunicarse enviando paquetes directamente uno a otro. Si un equipo del mismo nivel está tras un NAT, tiene dos direcciones asociadas, las direcciones privada y pública. Vamos a examinar una configuración sencilla en la que los NAT pueden crear problemas en aplicaciones del mismo nivel. La siguiente figura muestra una red privada con un NAT en el extremo.

Para una aplicación del mismo nivel que se ejecuta en todos los equipos del mismo nivel, el Equipo del mismo nivel 1 puede iniciar una sesión con el Equipo del mismo nivel 2 (accesible directamente en su subred) y con el Equipo del mismo nivel 3. Sin embargo, el Equipo del mismo nivel 1 no puede comunicar al Equipo del mismo nivel 3 la dirección pública del Equipo del mismo nivel 2 porque no la sabe. Además, el Equipo del mismo nivel 3 no puede iniciar una sesión con el Equipo del mismo nivel 1 ni el Equipo del mismo nivel 2 sin configurar manualmente el NAT con una entrada estática de la tabla de traducciones que convierta los paquetes de petición de conexión entrantes en la dirección privada o el puerto del Equipo del mismo nivel 1 o el Equipo del mismo nivel 2. Incluso con dicha entrada en la tabla, el Equipo del mismo nivel 3 no puede iniciar una sesión con el Equipo del mismo nivel 1 ni el Equipo del mismo nivel 2, porque ambos host usan la misma dirección IPv4 pública y el mismo número de puerto de aplicación.

Para complicar las cosas, es más frecuente que haya equipos del mismo nivel de Internet tras dos NAT distintos. Por ejemplo, en la figura anterior, el Equipo del mismo nivel 3 se encuentra tras un NAT. Para garantizar que la aplicación del mismo nivel puede funcionar en cualquier configuración con NAT, se debe modificar para que sea compatible con NAT, lo que aumenta la complejidad de la aplicación.

NAT-T de IPSec

La seguridad del Protocolo Internet (IPSec) de NAT Transversal (NAT-T) permite que los equipos del mismo nivel de IPSec situados tras un NAT detecten la presencia del NAT, negocien las asociaciones de seguridad IPSec y envíen datos protegidos mediante Carga de seguridad encapsuladora (ESP), a pesar de que las direcciones de los paquetes IPv4 protegidos mediante IPSec cambien. Para obtener información detallada sobre el funcionamiento de IPSec NAT-T consulte el artículo de The Cable Guy de agosto de 2002, que es una introducción a IPSec NAT Transversal.

IPSec NAT-T es compatible con Microsoft® Windows Server™ 2003, Windows XP Service Pack 2 (SP2), así como con Windows® XP Service Pack 1 y Windows 2000 con una descarga de Internet gratuita. Sin embargo, como consecuencia del comportamiento de IPSec y los NAT, de manera predeterminada Windows XP SP2 ya no es compatible con el establecimiento de asociaciones de seguridad de IPSec NAT-T con servidores ubicados tras un NAT, para evitar un riesgo de seguridad advertido. La siguiente figura muestra un ejemplo de configuración.

Para garantizar que el Servidor 1 está accesible tras el NAT para el tráfico de IPSec, se debe configurar el NAT con entradas estáticas de traducción que asignen el tráfico de Intercambio de claves de Internet (IKE) (mediante el puerto UDP 500) y de IPSec NAT-T (mediante el puerto UDP 4500) al Servidor 1.

En esta configuración se puede producir la situación siguiente:

1. El Cliente 1, ubicado en Internet, usa IPSec NAT-T para establecer asociaciones de seguridad bidireccionales con el Servidor 1. El NAT reenvía el tráfico de IKE e IPSec NAT-T entre el Servidor 1 y el Cliente 1, como consecuencia de las entradas estáticas de la tabla de traducción.

2. El Cliente 2 usa IPSec NAT-T para establecer asociaciones de seguridad bidireccionales con el Cliente 1. Cuando el Cliente 2 inicia la comunicación con el Cliente 1, el NAT crea un conjunto de entradas dinámicas en la tabla de traducción, lo que permite el intercambio de tráfico de IKE y IPSec NAT-T entre los clientes 2 y 1.

3. Si el NAT elimina las entradas dinámicas de la tabla de traducción creadas por el Cliente 2 y se produce una situación que haga que el Cliente 1 vuelva a establecer asociaciones de seguridad con el Cliente 2, puede ocurrir lo siguiente:

   El Cliente 1 envía tráfico de IKE a la dirección IP pública del NAT y al puerto UDP 500. Puesto que este tráfico coincide con la entrada estática de la tabla de traducción del tráfico de IKE al Servidor 1, el NAT reenvía el tráfico de IKE al Servidor 1 en lugar de enviarlo al Cliente 2. Como el Cliente 1 vuelve a establecer las asociaciones de seguridad, inicia la negociación de Modo principal de IPSec y podría acabar estableciendo asociaciones de seguridad con el Servidor 1 en lugar del Cliente 2. El riesgo de seguridad que se percibe es que el Cliente 1 puede establecer asociaciones de seguridad bidireccionales con un equipo del mismo nivel no deseado.

Si bien esta situación es infrecuente, el comportamiento predeterminado de los equipos en que se ejecuta Windows XP con SP2 es el de no establecer ninguna asociación de seguridad basada en IPSec NAT-T con servidores ubicados tras un NAT, para garantizar que esta situación no se produce nunca.

Para cambiar el comportamiento de IPSec NAT-T de un equipo en que se ejecute Windows XP con SP2, se debe crear el valor del Registro AssumeUDPEncapsulationContextOnSendRule. Con todo, debe ponerse en contacto con el administrador de la red o el personal de seguridad antes de hacerlo.

Para agregar y configurar el valor del Registro AssumeUDPEncapsulationContextOnSendRule, haga lo siguiente:

1. En el escritorio de Windows XP, haga clic en Inicio, en Ejecutar, escriba regedit.exe y, a continuación, haga clic en Aceptar.

2. En el árbol de la consola del Editor del Registro, abra la siguiente clave del Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC

3. En el menú Edición, haga clic en Agregar valor y, a continuación, agregue el valor siguiente:

Value Name: AssumeUDPEncapsulationContextOnSendRule Data Type: REG_DWORD Data Value: 0, 1, or 2

  - 0 = No se pueden establecer asociaciones de seguridad con servidores ubicados tras un NAT (valor predeterminado)

  - 1 = Se pueden establecer asociaciones de seguridad con servidores ubicados tras un NAT, siempre que el cliente tenga una dirección pública

  - 2 = Se pueden establecer asociaciones de seguridad cuando el cliente y los servidores están ubicados tras un NAT (este es el comportamiento en Windows XP con Service Pack 1 y Windows XP sin ningún Service Pack instalado)

Nota: En el nombre AssumeUDPEncapsulationContextOnSendRule se distinguen mayúsculas y minúsculas.

Es necesario reiniciar Windows XP con SP2 para que este cambio surta efecto.

Si se establece AssumeUDPEncapsulationContextOnSendRule en 1 o 2, un equipo en que se ejecute Windows XP con SP2 se puede conectar con un servidor ubicado tras un NAT, incluso si se trata de un servidor de red privada virtual (VPN) en que se ejecuta Windows Server 2003.

Resumen

Los NAT son una medida provisional para alargar la vida del espacio de direcciones públicas IPv4 y no una solución al problema que presenta. Los NAT funcionan mejor para reutilizar el espacio de direcciones privadas en equipos cliente. A pesar de todo, la mayoría de servidores necesitan direcciones públicas que no sean ambiguas. Los equipos del mismo nivel en comunicaciones del mismo nivel se pueden ubicar tras un NAT, pero para el uso general cuando hay varios equipos del mismo nivel tras un único NAT, si los equipos del mismo nivel están separados por más de un NAT, es necesario modificar la aplicación del mismo nivel que sea compatible con NAT. Se puede ubicar un servidor tras un NAT, pero el NAT se debe configurar manualmente con una entrada estática en la tabla de traducción para que traduzca los paquetes de petición de conexión entrantes y la convierta en la dirección privada y el puerto del servidor. En el caso de IPSec NAT-T, esta entrada estática en la tabla de traducción puede ocasionar resultados inesperados en ciertas configuraciones.

Para obtener más información

Para obtener más información acerca de NAT y Windows, puede consultar los siguientes recursos:

• Artículo sobre la configuración del acceso a servicios situados tras un Traductor de direcciones de red (NAT) (The Cable Guy, mayo de 2003).

• Artículo de introducción a IPSec NAT Transversal (The Cable Guy, agosto de 2002).

• Artículo sobre el Traductor de direcciones de red (NAT) de Windows 2000 (The Cable Guy, marzo de 2001).

• IPSec NAT-T no se recomienda para equipos con Windows Server 2003 ubicados tras traductores de direcciones de red.

• El comportamiento predeterminado de IPSec NAT Transversal (NAT-T) ha cambiado en Windows XP Service Pack 2.

Para enviar opiniones relativas al contenido de esta columna, escriba a Microsoft TechNet. Tenga en cuenta que no se trata de un alias de soporte técnico y que no se garantiza la respuesta.

Para obtener una lista e información adicional acerca de todas las columnas de The Cable Guy, haga clic aquí.