miércoles, 18 de enero de 2012

Protocolo IP de traducción de direcciones IP (segunda y última parte)

Ligero, aquí esta la segunda parte de IP NAT, (si llegaron ahora, viene de la primera parte). No hay mucho que decirles, solo es la continuación del consabido empeño. En orden sigue IPSec y también llegará en dos partes (el original de esta parte inicia aquí y concluye aquí). Hay mas antes de, así que aquí nos vemos, de momento es todo, saludos y provecho!




Tanto el NAT tradicional como el NAT bidireccional trabajan mediante el intercambio de direcciones de las redes interiores (internas) y exteriores (externas), según sea necesario para permitir a una red privada acceder a una pública. Para cada transacción, hay una asignación uno a uno entre la dirección local de un dispositivo en la red privada, y la dirección global que lo representa en la red pública. Podemos utilizar la asignación dinámica de direcciones para permitir que un gran número de hosts privados compartan un pequeño número de direcciones públicas registradas.

Sin embargo, hay un problema potencial. Tenga en cuenta nuestro ejemplo anterior de NAT, donde 250 huéspedes comparten 20 direcciones globales internas (públicas). Si hay 20 hosts con transacciones en curso, que sucede cuando el host 21 intenta acceder a la Internet? No hay ninguna dirección global interna utilizable, por lo que no será capaz de hacerlo.

Utilizando puertos para multiplexar direcciones privadas.
Afortunadamente, hay un mecanismo ya integrado en TCP / IP que nos puede ayudar a aliviar esta situación. Ambos protocolos TCP/IP de capa de transporte TCP y UDP, hacen uso de componentes de direccionamiento adicionales denominados puertos. El número de puerto en un mensaje TCP o UDP ayuda a identificar las conexiones individuales entre dos direcciones. Se utilizan para permitir que diferentes aplicaciones entre un cliente y un servidor TCP/IP hablen entre ellas, sin interferencia. Por ejemplo, se utiliza esta capacidad al abrir varias ventanas del navegador para acceder a más de una página Web en el mismo sitio al mismo tiempo. Esta forma de compartir direcciones IP, entre muchas conexiones se denomina multiplexación. La sección sobre puertos TCP y UDP describe todo esto con mucho más detalle.

Ahora, vamos a volver a NAT. Ya estamos traduciendo direcciones IP cuando enviamos datagramas entre las partes pública y privada de la red interna. ¿Qué pasaría si también se pudiera traducir los números de puerto? Bueno, se puede! La combinación de una dirección y un puerto identifica una conexión. A medida que un datagrama pasa de la red privada a la pública, podemos cambiar no sólo la dirección IP, sino también el número de puerto en la cabecera TCP o UDP. El datagrama será enviado con una dirección y un número de puerto diferentes. La respuesta vendrá de nuevo a esta misma combinación de dirección y puerto (llamada socket) y puede ser traducida de nuevo.
Este método tiene varios nombres. Ya que es una técnica mediante la cual podemos tener múltiples direcciones locales internas compartiendo una única dirección global interna, se llama sobrecarga de una dirección global o, alternativamente, sólo NAT sobrecargado. Nombres más elegantes que indican mejor cómo funciona la técnica incluyen NAT basado en Puertos, Traducción de puertos de direcciones de red (Network Address Port Translation NAPT) y Traducción de direcciones de puertos (Port Address Translation PAT).

Cualquiera que sea su nombre, el uso de puertos en la traducción tiene enormes ventajas. Puede permitir que las 250 máquinas de nuestra red privada utilicen sólo 20 direcciones IP y, potencialmente, incluso menos que eso. En teoría, usted podría incluso tener las 250 maquinas compartiendo una sola dirección a la vez! Usted no querría compartir tantos hosts locales hasta quedarse sin números de puerto, pero hay miles de números de puerto para elegir.
El NAT basado en puertos, por supuesto, requiere un router que esté programado para manejar las asignaciones adecuadas de direcciones y puertos para los datagramas a medida que son transferidos entre redes. Las desventajas de este método incluyen la mayor complejidad, y también mas problemas potenciales de compatibilidad (por ejemplo, con aplicaciones como FTP), ya que ahora tenemos que ver no solo direcciones IP sino también números de puerto en las capas superiores.

Concepto clave: El NAT basado en puertos o sobrecargado es una mejora del NAT regular que permite a un gran número de dispositivos en una red privada "compartir" a la vez una sola dirección interna global al cambiar los números de puerto que se utilizan en los mensajes TCP y UDP.


Ejemplo de NAT basado en puertos.
La operación de NAPT / PAT es muy similar a la forma en que opera el NAT regular, excepto que los números de puerto también se traducen. Para una transacción de salida tradicional, el número de puerto de origen se cambia en la solicitud, al mismo tiempo que se modifica la dirección de origen, el número de puerto de destino es modificado en la respuesta con la dirección de destino.

Consideremos de nuevo el ejemplo que vimos en el tema de NAT tradicional, pero esta vez en un ambiente de PAT. Dispositivo 10.0.0.207 fue uno de los 250 hosts en la red privada que accedían al servidor WEB en 204.51.16.12. Digamos que, debido a que se está utilizando PAT, para ahorrar dinero los 250 están compartiendo una única dirección interna global, 194.54.21.7, en lugar de un grupo de 20. La transacción procederá como se describe en la Tabla 76 y esquematiza en la figura 114.


Esta figura es muy similar a la figura 112, salvo que se muestran los puertos de origen y destino, ya que son utilizados en este tipo de NAT. Las direcciones y puertos traducidos están en negrita. La tabla 76 contiene una explicación completa de los cuatro pasos del NAT basado en puertos. Refiérase a la Figura 111 para una explicación de los tipos de direcciones.

Concepto clave: En el NAT basado en puertos, el router NAT traduce la dirección y el puerto origen de una solicitud de salida de la forma local interna a la forma global interna. A continuación, transforma la dirección de destino y el puerto de la respuesta de global interna a local interna. Las direcciones locales y globales externas son las mismas tanto en la solicitud como en la respuesta

Existe otro tema relacionado con NAPT / PAT que vale la pena mencionar: NAPT/PAT supone que todo el tráfico utiliza UDP o TCP en la capa de transporte. Si bien este es en general el caso, esto no siempre puede ser cierto. Si no hay ningún número de puerto, la traducción del puerto no se puede hacer y el método no funcionará.

Las tres versiones de NAT discutidas hasta ahora, el NAT tradicional, bidireccional y el NAT basado en el puertos, se utilizan normalmente para conectar una red que utiliza direcciones privadas, no enrutables, a la Internet pública, que utiliza direcciones únicas, registradas, enrutables. Con este tipo de NAT, normalmente no habrá ninguna superposición entre los espacios de direcciones de la red interior y exterior, ya que los primeros son privados y la segunda pública. Esto permite que el router NAT pueda distinguir de forma inmediata las direcciones internas de las externas sólo con mirarlas.

En los ejemplos que hemos visto hasta ahora, las direcciones eran todos de la RFC 1918 bloque 10.0.0.0. Estas no pueden ser direcciones públicas de Internet por lo que el router NAT sabía que cualquier dirección referida en la solicitud de la red interna dentro de este rango era una referencia local dentro de la red interna. Del mismo modo, ninguna de las direcciones fuera de este rango son fáciles de identificar como pertenecientes al "mundo exterior".

Casos de superposición de bloques de direcciones privadas y públicas
Sin embargo, hay circunstancias en donde ciertamente puede haber una superposición entre las direcciones utilizadas para la red en el interior, y las direcciones utilizadas para una parte de la red exterior. Considere los siguientes casos:
  • Conexiones de la red privada para la red privada: Nuestra red de ejemplo, usando direcciones del bloque 10.0.0.0 puede que desee conectarse a otra red utilizando el mismo método. Esta situación puede ocurrir si dos empresas se fusionan y sucede que utilizan el mismo esquema de direccionamiento (y no hay muchos bloques de direcciones IP privadas, por lo que no es poco común).
  • Asignaciones inválidas del espacio de direcciones públicas a la red privada: Algunas redes puede haberse establecido utilizando no un bloque designado de direcciones privadas, sino más bien un bloque que contiene las direcciones válidas de Internet. Por ejemplo, supongamos que un administrador decidió que la red que esta creando "nunca iba a estar conectada a internet" (¡ja!) y utilizó un esquema de direcciones empleando 18.0.0.0, que pertenecen al Instituto de Tecnología de Massachusetts (MIT). Luego, más adelante, esta falta de visión del administrador sería contraproducente cuando la red de hecho se tenga que conectar a la Internet.
  • Asignación de direcciones públicas "Obsoletas": La empresa A podría haber estado utilizando un bloque de direcciones en particular que desde hace años fue asignado o reasignado por cualquier razón a la empresa B. La empresa A puede no querer pasar la molestia de volver a numerar de su red, y seguirá manteniendo sus direcciones, incluso mientras la empresa B comience a usarlas en la Internet.
Lo que estas situaciones tienen en común es que las direcciones internas utilizadas en la red privada se superponen con direcciones en la red pública . Cuando un datagrama se envía desde la red local, el router NAT no puede saber si el destino está dentro de la red interior o exterior. Por ejemplo, si queremos conectar el host 10.0.0.207 en nuestra red privada al host 10.0.0.199 en una red diferente, y ponemos 10.0.0.199 en el destino del datagrama y lo enviamos, ¿cómo saber el router que queremos decir 10.0.0.199 en nuestra propia red local o en la red remota? Por lo demás, es posible que necesitemos enviar una solicitud a 10.0.0.207 en la otra red privada, es decir, nuestra propia dirección! Considere la red que fue numerada con un bloque de direcciones del MIT. ¿De qué manera el router sabe cuando un datagrama es en realidad enviado al MIT en oposición a otro dispositivo en la red privada?

Manejo de bloques superpuestos utilizando dos veces NAT.
La solución a este dilema es utilizar una forma más sofisticada de NAT. Las otras versiones que hemos visto hasta ahora siempre traducen o bien la dirección de origen o bien la dirección de destino de un datagrama que pasa de la red interna a la red exterior o viceversa. Para hacer frente a las direcciones superpuestas, debemos traducir tanto la dirección de origen como la dirección de destino en cada transición del interior al exterior o viceversa. Esta técnica se llama NAT superpuesto en referencia al problema que resuelve, o "dos veces NAT", debido a la forma en que lo resuelve. (Dicho sea de paso, a pesar de este último nombre, el NAT regular no se llama "Una vez NAT".)

Dos veces NAT funciona mediante la creación de un conjunto de asignaciones no sólo para la red privada que el router NAT sirve, sino también para la red (o redes) superpuestas que entran en conflicto con el espacio de direcciones de la red interna. Para que esto funcione, dos veces NAT se basa en el uso del sistema de nombres de dominio TCP / IP (DNS), al igual que el NAT bidireccional. De este modo, la red interior puede enviar solicitudes a la red superpuesta de una manera en que pueden ser identificadas unívocamente. De lo contrario, el router no puede decir con que red superpuesta nuestra red interna está tratando de ponerse en contacto.

Ejemplo de NAT "Superpuesto" / "dos veces NAT".
Vamos a intentar un nuevo ejemplo. Supongamos que nuestra red ha sido numerada erróneamente de manera que no se encuentra en el bloque privado 10.0.0.0, sino en el bloque 18.0.0.0 utilizado por el MIT. Un cliente de nuestra red privada, 18.0.0.18, quiere enviar una solicitud al servidor "www.twicenat.mit.edu", que tiene la dirección 18.1.2.3 en el MIT. Nuestro cliente no puede sólo hacer un datagrama con al dirección de destino 18.1.2.3 y enviarlo, dado que el router creerá que es en la red local y no lo va a enrutar. En vez de eso, 18.0.0.18 utiliza una combinación de DNS y NAT para obtener la dirección del dispositivo externo de la siguiente manera:
  1. El cliente de nuestra red local (18.0.0.18) envía una petición DNS para obtener la dirección de "www.twicenat.mit.edu".
  2. El router (dos veces NAT compatible) NAT que sirve nuestra red local intercepta esta petición DNS. A continuación, consulta las tablas para encontrar una asignación especial para este dispositivo externo. Digamos, que está programado para traducir "www.twicenat.mit.edu" a la dirección 172.16.44.55. Esta es una dirección privada no enrutable RFC 1918.
  3. El router NAT devuelve el valor, 172.16.44.55 para el cliente origen, que lo utilizará para su dirección de destino.
Una vez que nuestro cliente tiene la dirección traducida, se inicia una transacción igual que antes. NAT ahora llevará a cabo tanto la traducción de los dispositivos internos como también la de los dispositivos externos. La dirección del dispositivo externo debe ser traducida ya que el dispositivo interno está usando 172.16.44.55, la cual no es una dirección válida para el servidor que está tratando de alcanzar. La dirección del dispositivo interno aún debe ser traducida como en el NAT regular porque 18.0.0.18 no es una dirección pública válida para nosotros. Puede referirse a una máquina real en el MIT y no se supone que la estemos utilizando en el Internet!

Digamos que seguimos utilizando el pool de 20 direcciones globales internas de 194.54.21.1 y hasta 194.54.21.20 para las direcciones internas, y vamos a suponer además que el router NAT elige 194.54.21.12 para este intercambio en particular. La secuencia de la transacción sería más o menos como se describe en la Tabla 77, y se ilustra en la figura 115.



Esta ilustración es muy similar a la de la figura 112, salvo que el como se puede ver, tanto las direcciones de origen como las direcciones destino son traducidas por el router NAT en cada momento (mostradas en negrita). La tabla 77 contiene una explicación completa de los cuatro pasos del NAT superpuesto. Refiérase a la Figura 111 para una explicación de los tipos de direcciones.

Como se puede ver en este ejemplo, las direcciones locales y globales externas son diferentes, a diferencia de los anteriores ejemplos NAT. Dos veces NAT también puede manejar una operación de entrada, observando los datagramas que vienen de la Internet que se superponen con las direcciones que se utilizan en la red local y hacer sustituciones dobles según sea necesario.

Concepto clave: El NAT "superpuesto" se utiliza en situaciones en las que tanto el origen como el destino de un datagrama son direcciones privadas o de otro modo no puede ser utilizado regularmente en el Internet público. En este caso, a diferencia de los otros tipos de NAT, el router NAT traduce las direcciones origen y destino de los datagramas entrantes y salientes. En los mensajes salientes, las direcciones locales internas se traducen a direcciones globales internas y las direcciones locales externas a globales externas, en los mensajes entrantes, las direcciones globales internas se traducen a direcciones locales internas y las globales externas a locales externas.
En un mundo perfecto, Network Address Translation puede ser transparente para los dispositivos que lo usan. Nos gustaría ser capaces de tener un router NAT que cambie las direcciones IP de los datagramas en las solicitudes al salir de la red y nuevamente la cambiara en las respuestas que vienen de regreso y y que ninguno de los hosts se entere de nada. Por desgracia, el mundo no es perfecto.

No es posible que NAT sea completamente transparente para los dispositivos que lo utilizan. Hay posibles problemas de compatibilidad que surgen cuando NAT no realiza ciertas funciones que van más allá de simplemente intercambiar las direcciones IP y posiblemente números de puertos, en la cabecera IP. El principal problema es que a pesar de que las direcciones IP se supone que son del dominio del Protocolo IP, son realmente utilizadas por otros protocolos, tanto en la capa de red como en las capas superiores. Cuando NAT cambia la direcciónen un datagrama IP, a menudo se debe también cambiar las direcciones en otros lugares para asegurarse de que las direcciones en las cabeceras y las cargas todavía coinciden.
Estos problemas de compatibilidad exigen que a pesar de que NAT teóricamente debería funcionar sólo en el nivel de la capa de red IP, en términos prácticos, los routers NAT debe ser "conscientes" de muchos otros protocolos y debe realizar operaciones especiales cuando sea necesario. Algunos son necesarios para todos los datagramas que se traducen, mientras que otros sólo se aplican a ciertos datagramas y a otros no. Y aún cuando estas técnicas se suman a los routers NAT, algunas cosas todavía no funcionen correctamente en un entorno NAT.

La mayoría de las implementaciones de NAT toman en cuenta estas preocupaciones. Ciertamente, las aplicaciones comunes, como FTP son ampliamente soportadas por los routers NAT, o nadie querría usar NAT. Dicho esto, es posible que algunas aplicaciones no funcionen a través de NAT. El hecho de que realmente NAT no sea transparente y deban hacerse este tipo de "hacks" extra para las cabeceras de protocolo e incluso otras cargas es una gran parte de la razón por la cual muchas personas se refieren a NAT como una "chapuza"; las soluciones elegantes no tienen tantos casos especiales que necesitan un tratamiento especial.

Vamos a echar un vistazo a algunos de los problemas y necesidades específicas.

Recálculo de las sumas de comprobación (checksum) TCP y UDP
Cambiar las direcciones en la cabecera IP significa que la suma de comprobación de cabecera debe ser calculada. Dado que tanto UDP o TCP también tienen sumas de comprobación, y estas sumas se calculan sobre una pseudo cabecera que contiene la IP de origen y destino, así, estas también deben ser recalculadas cada vez que se hace la traducción.

Manipulaciones ICMP
Dado que NAT funciona tan íntimamente con las cabeceras IP, y dado que IP está estrechamente relacionado con su "asistente" el protocolo ICMP, NAT también deben buscar ciertos mensajes ICMP y realizar cambios en las direcciones contenidas en ellos. Muchos mensajes ICMP, como Destino inalcanzable (Destination Unreachable) y Problema de parámetros (Parameter Problem) contienen como datos el encabezado IP original del datagrama que llevó el mensaje ICMP. Dado que NAT está traduciendo las direcciones IP en los encabezados, debe estar atento a estos mensajes y traducir las direcciones incluidas en las cabeceras cuando sea necesario.

Aplicaciones que empotran las direcciones IP
Una serie de aplicaciones TCP / IP empotran las direcciones IP dentro de la carga de datos de la aplicación. El ejemplo más notorio de esto es el File Transfer Protocol (FTP), que en realidad envía las asignaciones de direcciones y puertos como información de texto en los datagramas entre dispositivos durante una conexión. Con el fin de NAT soporte adecuadamente el FTP, debe ser específicamente programado con algoritmos para buscar esta información y hacer los cambios necesarios.

El nivel de complicación puede ir incluso más allá. Considere lo que sucede cuando un mensaje FTP que contiene estas direcciones o números de puerto en texto se encuentra fragmentado, parte de la dirección a traducir puede estar en dos datagramas IP diferentes, y difíciles de reconocer!

Problemas adicionales con la traducción de puertos
Cuando se utiliza NAT basada en puertos NAT (PAT), las cuestiones que se aplican a las direcciones ahora se aplican a los puertos y, lo que significa mucho mas trabajo para los routers.

Impacto en cascada de los cambios en los números de direcciones o puertos.
Tomemos el ejemplo de un datagrama FTP codificando una dirección IP que NAT tiene que cambiar. La dirección sustituida puede requerir más caracteres que la original, en nuestro primer ejemplo, 10.0.0.207 (10 caracteres ASCII) se sustituye por 194.54.21.11 (12 caracteres ASCII). Hacer esta sustitución cambia el tamaño de la carga! Esto significa que los números de secuencia TCP también deben ser modificados.

En estas situaciones, se se supone que NAT se haga cargo de cualquier trabajo adicional que se requiera. Esta es, sin duda una complicación que no se produce sin el uso de NAT, y es un ejemplo frecuentemente citado como la "chapucería" de NAT.

Problemas con IPSec
Cuando se utiliza IPSec en el modo de transporte, tanto los protocolos de cabecera de autenticación (AH Authentication Header) como el de Carga de seguridad encapsulada (ESP Encapsulating Security Payload) emplean un control de integridad que se basa en el valor de toda la carga útil. Cuando NAT trata de actualizar las sumas de comprobación en los datagramas TCP o UDP, modifica el valor de los datos que el dispositivo receptor utiliza en la comprobación de integridad de AH o ESP. La comprobación fallará. Por lo tanto, NAT no se puede utilizar en modo de transporte IPSec. Aún puede funcionar en modo túnel, pero también puede haber complicaciones aquí.