Traducción de direcciones de red

Traducción de direcciones de red entre una red privada e Internet

Traducción de direcciones de red (NAT) es un método para mapear una IP espacio de dirección en otro modificando dirección de red información en el Encabezado IP de paquetes mientras están en tránsito a través de un tráfico dispositivo de enrutamiento. La técnica se usó originalmente para eludir la necesidad de asignar una nueva dirección a cada host cuando se movía una red o cuando el upstream Los proveedores de servicios de Internet fue reemplazado, pero no pudo enrutar el espacio de direcciones de la red. Se ha convertido en una herramienta popular y esencial para conservar el espacio de direcciones global frente a Agotamiento de direcciones IPv4. Un enrutador de Internet Dirección IP de una puerta de enlace NAT se puede utilizar para todo un red privada.

Como la traducción de direcciones de red modifica la información de la dirección IP en los paquetes, las implementaciones de NAT pueden variar en su comportamiento específico en varios casos de direccionamiento y su efecto en el tráfico de la red. Los detalles del comportamiento de NAT no suelen estar documentados por los proveedores de equipos que contienen implementaciones de NAT.

NAT básico

El tipo más simple de NAT proporciona una traducción uno a uno de las direcciones IP. RFC 2663 se refiere a este tipo de NAT como NAT básico; también se le llama un NAT uno a uno. En este tipo de NAT, solo las direcciones IP, cabecera IP suma de comprobacióny se modifican las sumas de comprobación de nivel superior que incluyen la dirección IP. La NAT básica se puede utilizar para interconectar dos redes IP que tienen direccionamiento incompatible.

NAT de uno a muchos

Mapeo de direcciones de red

La mayoría de los traductores de direcciones de red asignan múltiples hosts privados a una dirección IP expuesta públicamente.

Aquí hay una configuración típica:

1. Una red local utiliza uno de los designados privada Subredes de direcciones IP (RFC 1918).
2. La red tiene un enrutador que tiene una dirección privada y otra pública. El enrutador utiliza la dirección privada para comunicarse con otros dispositivos en la red local privada. La dirección pública (típicamente asignada por un Los proveedores de servicios de Internet) es utilizado por el enrutador para comunicarse con el resto de Internet.
3. A medida que el tráfico pasa de la red a Internet, el enrutador traduce la dirección de origen en cada paquete de una dirección privada a la propia dirección pública del enrutador. El enrutador rastrea datos básicos sobre cada conexión activa (particularmente la dirección de destino y Puerto). Cuando el enrutador recibe tráfico entrante de Internet, utiliza los datos de seguimiento de la conexión que almacenó durante la fase de salida para determinar a qué dirección privada (si corresponde) debe reenviar la respuesta.

Todos los paquetes IP tienen una dirección IP de origen y una dirección IP de destino. Por lo general, los paquetes que pasan de la red privada a la red pública verán modificada su dirección de origen, mientras que los paquetes que pasan de la red pública a la red privada verán modificada su dirección de destino. Para evitar ambigüedades en cómo se traducen las respuestas, se requieren modificaciones adicionales a los paquetes. La gran mayoría de los usos del tráfico de Internet Transmission Control Protocol (TCP) o User Datagram Protocol (UDP). Para estos protocolos, el números de puerto se cambian para que la combinación de dirección IP (dentro de la Encabezado IP) y el número de puerto (dentro del Encabezado de la capa de transporte) en el paquete devuelto se puede asignar sin ambigüedades al destino de la red privada correspondiente. RFC 2663 utiliza el término dirección de red y traducción de puertos (NAPT) para este tipo de NAT. Otros nombres incluyen traducción de la dirección del puerto (PALMADITA), Enmascaramiento de IP, sobrecarga de NAT y NAT de muchos a uno. Este es el tipo más común de NAT y se ha convertido en sinónimo del término "NAT" en el uso común.

Este método permite la comunicación a través del enrutador solo cuando la conversación se origina en la red privada, ya que la transmisión de origen inicial es la que establece la información requerida en las tablas de traducción. Así un navegador web dentro de la red privada podría navegar por sitios web que están fuera de la red, mientras que los navegadores web fuera de la red no podrían navegar por un sitio web alojado en ella. Los protocolos que no se basan en TCP y UDP requieren otras técnicas de traducción.

Un beneficio adicional de uno a muchos NAT es que mitiga Agotamiento de direcciones IPv4 al permitir que redes enteras se conecten a Internet usando una sola dirección IP pública.

Métodos de traducción

La traducción de direcciones de red y puertos se puede implementar de varias maneras. Algunas aplicaciones que usan información de direcciones IP pueden necesitar determinar la dirección externa de un traductor de direcciones de red. Esta es la dirección que detectan sus compañeros de comunicación en la red externa. Además, puede ser necesario examinar y categorizar el tipo de mapeo en uso, por ejemplo, cuando se desea establecer una ruta de comunicación directa entre dos clientes, ambos detrás de puertas de enlace NAT separadas.

Para este propósito, RFC 3489 especificó un protocolo llamado Travesía simple de UDP sobre NAT (ATURDIR) en 2003. Clasificó las implementaciones de NAT como NAT de cono completo, (dirección) NAT de cono restringido, NAT de cono con puerto restringido or NAT simétricoy propuso una metodología para probar un dispositivo en consecuencia. Sin embargo, desde entonces estos procedimientos han quedado obsoletos del estado de los estándares, ya que los métodos son inadecuados para evaluar correctamente muchos dispositivos. RFC 5389 estandarizó nuevos métodos en 2008 y el acrónimo ATURDIR ahora representa el nuevo título de la especificación: Utilidades transversales de sesión para NAT.

Clasificaciones de implementación de NAT

NAT de cono completo, también conocido como NAT uno a uno Una vez que una dirección interna (iAddr:iPort) se asigna a una dirección externa (eAddr:ePort), todos los paquetes de iAddr:iPort se envían a través de eAddr:ePort. Cualquier host externo puede enviar paquetes a iAddr:iPort enviando paquetes a eAddr:ePort.
(Dirección)-cono-restringido NAT Una vez que una dirección interna (iAddr:iPort) se asigna a una dirección externa (eAddr:ePort), todos los paquetes de iAddr:iPort se envían a través de eAddr:ePort. Un host externo (hAddr:cualquiera) puede enviar paquetes a iAddr:iPort enviando paquetes a eAddr:ePort solo si iAddr:iPort ha enviado previamente un paquete a hAddr:cualquier. "Cualquiera" significa que el número de puerto no importa.
NAT de cono con puerto restringido Como un NAT de cono de dirección restringida, pero la restricción incluye números de puerto. Una vez que una dirección interna (iAddr:iPort) se asigna a una dirección externa (eAddr:ePort), todos los paquetes de iAddr:iPort se envían a través de eAddr:ePort. Un host externo (dirección h: puerto h) puede enviar paquetes a iAddr:iPort enviando paquetes a eAddr:ePort solo si iAddr:iPort ha enviado previamente un paquete a hAddr:hPort.
NAT simétrico La combinación de una dirección IP interna más una dirección IP y puerto de destino se asigna a una única dirección IP y puerto de origen externo; si el mismo host interno envía un paquete incluso con la misma dirección y puerto de origen pero a un destino diferente, se utiliza una asignación diferente. Solo un host externo que recibe un paquete de un host interno puede devolver un paquete.

Muchas implementaciones de NAT combinan estos tipos, por lo que es mejor referirse al comportamiento de NAT individual específico en lugar de usar la terminología Cone/Symmetric. RFC 4787 intenta aliviar la confusión mediante la introducción de terminología estandarizada para los comportamientos observados. Para la primera viñeta de cada fila de la tabla anterior, el RFC caracterizaría las NAT de cono completo, cono restringido y cono restringido por puerto como si tuvieran un Mapeo independiente de puntos finales, mientras que caracterizaría un NAT simétrico como si tuviera un Mapeo dependiente de la dirección y del puerto. Para la segunda viñeta en cada fila de la tabla anterior, RFC 4787 también etiquetaría NAT de cono completo como si tuviera un Filtrado independiente de puntos finales, NAT de cono restringido como si tuviera un Filtrado dependiente de la dirección, NAT de cono restringido por puerto como si tuviera un Filtrado dependiente de direcciones y puertos, y NAT simétrico como si tuviera un Filtrado dependiente de la dirección or Filtrado dependiente de direcciones y puertos. Otras clasificaciones del comportamiento de NAT mencionadas en el RFC incluyen si preservan los puertos, cuándo y cómo se actualizan las asignaciones, si los hosts internos pueden usar las asignaciones externas (es decir, su peinado comportamiento) y el nivel de determinismo que exhiben las NAT al aplicar todas estas reglas. Específicamente, la mayoría de los NAT combinan NAT simétrico para conexiones salientes con estático la asignación de puertos, donde los paquetes entrantes dirigidos a la dirección y el puerto externos se redireccionan a una dirección y un puerto internos específicos.

Tipo de NAT y NAT transversal, papel de la preservación del puerto para TCP

La Transversal NAT El problema surge cuando los pares detrás de diferentes NAT intentan comunicarse. Una forma de resolver este problema es utilizar el reenvío de puertos. Otra forma es utilizar varias técnicas transversales de NAT. La técnica más popular para TCP NAT transversal es Perforación de agujeros TCP.

La perforación de agujeros TCP requiere que el NAT siga el preservación del puerto diseño para TCP. Para una comunicación TCP saliente determinada, se utilizan los mismos números de puerto en ambos lados del NAT. La preservación del puerto NAT para las conexiones TCP salientes es crucial para el cruce TCP NAT porque, bajo TCP, un puerto solo se puede usar para una comunicación a la vez, por lo que los programas vinculan distintos sockets TCP a puertos efímeros para cada comunicación TCP, lo que hace que la predicción del puerto NAT sea imposible para TCP.

Por otro lado, para UDP, los NAT no necesitan conservación de puertos. De hecho, múltiples comunicaciones UDP (cada una con un punto final) puede ocurrir en el mismo puerto de origen, y las aplicaciones generalmente reutilizan el mismo socket UDP para enviar paquetes a distintos hosts. Esto hace que la predicción de puertos sea sencilla, ya que es el mismo puerto de origen para cada paquete.

Además, la preservación de puertos en NAT para TCP permite que los protocolos P2P ofrezcan menos complejidad y menos latencia porque no es necesario utilizar un tercero (como STUN) para descubrir el puerto NAT, ya que la propia aplicación ya conoce el puerto NAT.

Sin embargo, si dos hosts internos intentan comunicarse con el mismo host externo usando el mismo número de puerto, el NAT puede intentar usar una dirección IP externa diferente para la segunda conexión o puede necesitar renunciar a la preservación del puerto y reasignar el puerto.^{: 9}

A partir de 2006, aproximadamente el 70% de los clientes en P2P las redes empleaban alguna forma de NAT.

Implementación

Establecimiento de una comunicación bidireccional

En NAT bidireccional, la sesión se puede establecer tanto desde el interior como desde el exterior.

Cada paquete TCP y UDP contiene un número de puerto de origen y un número de puerto de destino. Cada uno de esos paquetes está encapsulado en un paquete IP, cuyo Encabezado IP contiene una dirección IP de origen y una dirección IP de destino. La triple dirección IP/protocolo/número de puerto define una asociación con un toma de red.

Para servicios de acceso público, como servidores web y de correo, el número de puerto es importante. Por ejemplo, el puerto 80 se conecta a través de un socket al servidor web software y el puerto 25 a un servidor de correo SMTP demonio. La dirección IP de un servidor público también es importante, similar en singularidad global a una dirección postal o un número de teléfono. Tanto la dirección IP como el número de puerto deben ser correctamente conocidos por todos los hosts que deseen comunicarse con éxito.

Las direcciones IP privadas, como se describe en RFC 1918, solo se pueden usar en redes privadas que no están conectadas directamente a Internet. Los puertos son puntos finales de comunicación exclusivos de ese host, por lo que se mantiene una conexión a través del dispositivo NAT mediante la asignación combinada de puerto y dirección IP. Una dirección privada en el interior del NAT se asigna a una dirección pública externa. La traducción de direcciones de puerto (PAT) resuelve los conflictos que surgen cuando varios hosts utilizan el mismo número de puerto de origen para establecer diferentes conexiones externas al mismo tiempo.

Analogía de la extensión del número de teléfono

Un dispositivo NAT es similar a un sistema telefónico en una oficina que tiene un número de teléfono público y varias extensiones. Todas las llamadas telefónicas salientes realizadas desde la oficina parecen provenir del mismo número de teléfono. Sin embargo, una llamada entrante que no especifica una extensión no se puede transferir automáticamente a una persona dentro de la oficina. En este escenario, la oficina es una LAN privada, el número de teléfono principal es la dirección IP pública y las extensiones individuales son números de puerto únicos.

Proceso de traducción

Con NAT, todas las comunicaciones enviadas a hosts externos en realidad contienen el externo Dirección IP e información de puerto del dispositivo NAT en lugar de direcciones IP de host interno o números de puerto. NAT solo traduce las direcciones IP y los puertos de sus hosts internos, ocultando el verdadero punto final de un host interno en una red privada.

Cuando una computadora en la red privada (interna) envía un paquete IP a la red externa, el dispositivo NAT reemplaza la dirección IP de origen interna en el encabezado del paquete con la dirección IP externa del dispositivo NAT. Luego, PAT puede asignar a la conexión un número de puerto de un grupo de puertos disponibles, insertando este número de puerto en el campo de puerto de origen. A continuación, el paquete se reenvía a la red externa. Luego, el dispositivo NAT realiza una entrada en una tabla de traducción que contiene la dirección IP interna, el puerto de origen original y el puerto de origen traducido. Los paquetes subsiguientes de la misma dirección IP de origen interno y número de puerto se traducen a la misma dirección IP de origen externo y número de puerto. La computadora que recibe un paquete que se ha sometido a NAT establece una conexión con el puerto y la dirección IP especificados en el paquete alterado, sin darse cuenta de que la dirección proporcionada se está traduciendo.

Al recibir un paquete de la red externa, el dispositivo NAT busca en la tabla de traducción según el puerto de destino en el encabezado del paquete. Si se encuentra una coincidencia, la dirección IP de destino y el número de puerto se reemplazan con los valores que se encuentran en la tabla y el paquete se reenvía a la red interna. De lo contrario, si el número de puerto de destino del paquete entrante no se encuentra en la tabla de traducción, el paquete se descarta o se rechaza porque el dispositivo PAT no sabe a dónde enviarlo.

Visibilidad de funcionamiento

El funcionamiento de NAT suele ser transparente tanto para los hosts internos como para los externos. El dispositivo NAT puede funcionar como la puerta de enlace predeterminada para el host interno que, por lo general, conoce la verdadera dirección IP y el puerto TCP o UDP del host externo. Sin embargo, el host externo solo conoce la dirección IP pública del dispositivo NAT y el puerto particular que se utiliza para comunicarse en nombre de un host interno específico.

Aplicaciones

enrutamiento

La traducción de direcciones de red se puede utilizar para mitigar la superposición de direcciones IP. La superposición de direcciones ocurre cuando los hosts en diferentes redes con el mismo espacio de direcciones IP intentan llegar al mismo host de destino. Esto suele ser una mala configuración y puede resultar de la fusión de dos redes o subredes, especialmente cuando se usa RFC 1918 red privada direccionamiento. El host de destino experimenta el tráfico que aparentemente llega desde la misma red, y los enrutadores intermedios no tienen forma de determinar a dónde se debe enviar el tráfico de respuesta. La solución es volver a numerar para eliminar la superposición o la traducción de direcciones de red.

Balanceo de carga

In Servidor de cliente aplicaciones, equilibradores de carga reenviar las solicitudes de los clientes a un conjunto de servidores para administrar la carga de trabajo de cada servidor. La traducción de direcciones de red se puede utilizar para asignar una dirección IP representativa del clúster de servidores a hosts específicos que atienden la solicitud.

Técnicas relacionadas

IEEE La traducción inversa de direcciones y puertos (RAPT o RAT) permite que un host cuya Dirección IP cambia de vez en cuando para permanecer accesible como un servidor a través de una dirección IP doméstica fija. CiscoLa implementación de RAPT es una sobrecarga de PAT o NAT y asigna varias direcciones IP privadas a una única dirección IP pública. Se pueden asignar varias direcciones a una sola dirección porque cada dirección privada se rastrea mediante un número de puerto. PAT utiliza números de puerto de origen únicos en la dirección IP global interna para distinguir entre traducciones. PAT intenta conservar el puerto de origen original. Si este puerto de origen ya está en uso, PAT asigna el primer número de puerto disponible comenzando desde el principio del grupo de puertos apropiado 0–511, 512–1023 o 1024–65535. Cuando no hay más puertos disponibles y hay más de una dirección IP externa configurada, PAT pasa a la siguiente dirección IP para intentar asignar nuevamente el puerto de origen original. Este proceso continúa hasta que se agotan los puertos disponibles y las direcciones IP externas.

Mapeo de Dirección y Puerto es una propuesta de Cisco que combina Dirección más puerto traducción con tunelización de los paquetes IPv4 a través de la red interna de un proveedor ISP IPv6 red. En efecto, es un (casi) apátrida alternativa a NAT de nivel de operador y DS Lite que empuja el Dirección IPv4/ función de traducción de puerto (y el mantenimiento del estado NAT) completamente en el existente equipo de las instalaciones del cliente implementación NAT. Evitando así la NAT444 y problemas de estado de NAT de nivel de operador, y también proporciona un mecanismo de transición para el despliegue de IPv6 nativo al mismo tiempo con muy poca complejidad añadida.

Problemas y limitaciones

Los hosts detrás de enrutadores habilitados para NAT no tienen conectividad de extremo a extremo y no puede participar en algunos protocolos de Internet. Servicios que requieren la iniciación de TCP conexiones desde la red externa, o que usan protocolos sin estado como los que usan UDP, puede ser interrumpido. A menos que el enrutador NAT haga un esfuerzo específico para admitir dichos protocolos, los paquetes entrantes no pueden llegar a su destino. Algunos protocolos pueden acomodar una instancia de NAT entre hosts participantes ("modo pasivo" FTP, por ejemplo), a veces con la ayuda de un puerta de enlace a nivel de aplicación (consulta: § Aplicaciones afectadas por NAT), pero fallan cuando ambos sistemas están separados de Internet por NAT. El uso de NAT también complica protocolos de tunelización como IPsec porque NAT modifica los valores en los encabezados que interfieren con las comprobaciones de integridad realizadas por IPsec y otros protocolos de tunelización.

La conectividad de extremo a extremo ha sido un principio básico de Internet, apoyado, por ejemplo, por la Junta de Arquitectura de Internet. Los documentos arquitectónicos actuales de Internet observan que NAT es una violación de la principio de extremo a extremo, pero que NAT tiene un papel válido en el diseño cuidadoso. Existe una preocupación considerablemente mayor con el uso de IPv6 NAT, y muchos arquitectos de IPv6 creen que IPv6 tenía la intención de eliminar la necesidad de NAT.

Una implementación que solo realiza un seguimiento de los puertos puede agotarse rápidamente por las aplicaciones internas que utilizan varias conexiones simultáneas, como un HTTP solicitud de una página web con muchos objetos incrustados. Este problema se puede mitigar rastreando la dirección IP de destino además del puerto, compartiendo así un solo puerto local con muchos hosts remotos. Este seguimiento adicional aumenta la complejidad de la implementación y los recursos informáticos en el dispositivo de traducción.

Debido a que todas las direcciones internas están ocultas detrás de una dirección de acceso público, es imposible que los hosts externos inicien directamente una conexión a un host interno en particular. Aplicaciones como VOIP, videoconferencia, y otras aplicaciones punto a punto deben usar Transversal NAT técnicas para funcionar.

Fragmentación y sumas de comprobación

Pure NAT, que opera solo en IP, puede o no analizar correctamente los protocolos con cargas útiles que contienen información sobre IP, como ICMP. Esto depende de si la carga útil es interpretada por un host en el dentro or afuera de la traducción Protocolos básicos como TCP y UDP no puede funcionar correctamente a menos que NAT tome medidas más allá de la capa de red.

Los paquetes IP tienen una suma de verificación en cada encabezado de paquete, lo que proporciona detección de errores solo para el encabezado. Los datagramas IP pueden fragmentarse y es necesario que un NAT vuelva a ensamblar estos fragmentos para permitir el recálculo correcto de las sumas de verificación de nivel superior y el seguimiento correcto de qué paquetes pertenecen a qué conexión.

TCP y UDP, tienen una suma de verificación que cubre todos los datos que transportan, así como el encabezado TCP o UDP, más un pseudo-encabezado que contiene las direcciones IP de origen y destino del paquete que lleva el encabezado TCP o UDP. Para que un NAT de origen pase TCP o UDP con éxito, debe volver a calcular la suma de verificación del encabezado TCP o UDP en función de las direcciones IP traducidas, no las originales, y colocar esa suma de verificación en el encabezado TCP o UDP del primer paquete del conjunto fragmentado. de paquetes

Alternativamente, el host de origen puede realizar Ruta MTU Descubrimiento para determinar el tamaño del paquete que se puede transmitir sin fragmentación y luego establecer el no fragmentes (DF) bit en el campo de encabezado de paquete apropiado. Esta es solo una solución unidireccional, porque el host que responde puede enviar paquetes de cualquier tamaño, que pueden fragmentarse antes de llegar al NAT.

términos variantes

DTA

La traducción de direcciones de red de destino (DNAT) es una técnica para cambiar de forma transparente el destino Dirección IP de un paquete enrutado y realizando la función inversa para cualquier respuesta. Cualquier enrutador situado entre dos puntos finales puede realizar esta transformación del paquete.

DNAT se usa comúnmente para publicar un servicio ubicado en una red privada en una dirección IP de acceso público. Este uso de DNAT también se denomina el reenvío de puertoso DMZ cuando se usa en su totalidad servidor, que queda expuesto a la WAN, convirtiéndose en análogo a un ejército indefenso zona desmilitarizada (ZDM).

SNAT

El significado del término SNAT varía según el proveedor:

• fuente NAT es una expansión común y es la contraparte de destino NAT (DTA). Esto se usa para describir NAT de uno a muchos; NAT para conexiones salientes a servicios públicos.
• NAT con estado es utilizado por Cisco Systems
• NAT estática es utilizado por WatchGuard
• NAT segura es utilizado por F5 Redes y por Microsoft (en lo que respecta a la Servidor ISA)

La traducción segura de direcciones de red (SNAT) es parte de Microsoft Servidor de seguridad y aceleración de Internet y es una extensión del controlador NAT integrado en Servidor Microsoft Windows. Proporciona seguimiento y filtrado de conexiones para las conexiones de red adicionales necesarias para el FTP, ICMP, H.323 y PPTP protocolos, así como la capacidad de configurar un HTTP transparente servidor proxy.

Traducción dinámica de direcciones de red

Cómo funciona NAT dinámico.

La NAT dinámica, al igual que la NAT estática, no es común en redes más pequeñas, pero se encuentra en corporaciones más grandes con redes complejas. Donde la NAT estática proporciona un mapeo de dirección IP estática interna a pública uno a uno, la NAT dinámica usa una Grupo de direcciones IP públicas.

horquilla NAT

horquilla NAT, también conocido como Bucle invertido de NAT or Reflexión NAT, es una característica en muchos enrutadores de consumo donde una máquina en el LAN puede acceder a otra máquina en la LAN a través de la dirección IP externa de la LAN/enrutador (con el reenvío de puertos configurado en el enrutador para dirigir las solicitudes a la máquina adecuada en la LAN). Esta noción se describe oficialmente en 2008, RFC 5128.

A continuación se describe una red de ejemplo:

• Direccion publica: 203.0.113.1. Esta es la dirección del WAN interfaz en el enrutador.
• Dirección interna del enrutador: 192.168.1.1
• Dirección del servidor: 192.168.1.2
• Dirección de una computadora local: 192.168.1.100

Si se envía un paquete a 203.0.113.1 por una computadora en 192.168.1.100, el paquete normalmente se enrutaría al puerta de enlace predeterminada (el enrutador) Un enrutador con la función de bucle invertido NAT detecta que 203.0.113.1 es la dirección de su interfaz WAN y trata el paquete como si viniera de esa interfaz. Determina el destino de ese paquete, según las reglas DNAT (reenvío de puertos) para el destino. Si los datos se enviaron al puerto 80 y existe una regla DNAT para el puerto 80 dirigida a 192.168.1.2, luego el host en esa dirección recibe el paquete.

Si no hay disponible una regla DNAT aplicable, el enrutador descarta el paquete. Un Destino ICMP inalcanzable se puede enviar respuesta. Si hubiera alguna regla DNAT, la traducción de direcciones aún está vigente; el enrutador aún reescribe la dirección IP de origen en el paquete. La computadora local (192.168.1.100) envía el paquete como procedente de 192.168.1.100, pero el servidor (192.168.1.2) lo recibe como proveniente de 203.0.113.1. Cuando el servidor responde, el proceso es idéntico al de un remitente externo. Por lo tanto, es posible la comunicación bidireccional entre hosts dentro de la red LAN a través de la dirección IP pública.

NAT en IPv6

La traducción de direcciones de red no se usa comúnmente en IPv6 porque uno de los objetivos de diseño de IPv6 es restaurar la conectividad de red de extremo a extremo. El gran espacio de direccionamiento de IPv6 evita la necesidad de conservar direcciones y cada dispositivo puede recibir una dirección enrutable global única. Uso de direcciones locales únicas en combinación con traducción de prefijo de red puede lograr resultados similares a NAT.

El gran espacio de direccionamiento de IPv6 aún se puede derrotar según la longitud real del prefijo proporcionada por el operador. No es raro recibir un prefijo /64, la subred recomendada más pequeña, para una red doméstica completa, lo que requiere el uso de una variedad de técnicas para subdividir manualmente el rango para que todos los dispositivos permanezcan accesibles. Incluso la NAT de IPv6 a IPv6 real, NAT66, puede resultar útil a veces: el blog de APNIC describe un caso en el que al autor solo se le proporcionó una única dirección (/128).

Aplicaciones afectadas por NAT

Cosas capa de aplicación protocolos, como Protocolo de Transferencia de Archivos (FTP) y protocolo de Iniciacion de Sesion (SIP), enviar direcciones de red explícitas dentro de sus datos de aplicación. FTP en modo activo, por ejemplo, utiliza conexiones separadas para el tráfico de control (comandos) y para el tráfico de datos (contenido del archivo). Al solicitar una transferencia de archivos, el host que realiza la solicitud identifica la conexión de datos correspondiente por su capa de red y capa de transporte direcciones. Si el host que realiza la solicitud se encuentra detrás de un cortafuegos NAT simple, la traducción de la dirección IP o el número de puerto TCP invalida la información recibida por el servidor. SIP comúnmente controla voz sobre IP llamadas, y sufren el mismo problema. SIP y su acompañamiento Protocolo de descripción de sesión puede usar varios puertos para configurar una conexión y transmitir un flujo de voz a través de Protocolo de transporte en tiempo real. Las direcciones IP y los números de puerto están codificados en los datos de carga útil y deben conocerse antes de atravesar los NAT. Sin técnicas especiales, como ATURDIR, el comportamiento de NAT es impredecible y las comunicaciones pueden fallar. Puerta de enlace de capa de aplicación (ALG) software o hardware pueden corregir estos problemas. Un módulo de software ALG que se ejecuta en un dispositivo de cortafuegos NAT actualiza los datos de la carga útil que no son válidos debido a la traducción de direcciones. Los ALG deben comprender el protocolo de capa superior que deben corregir, por lo que cada protocolo con este problema requiere un ALG por separado. Por ejemplo, en muchos sistemas Linux, hay módulos de kernel llamados rastreadores de conexión que sirven para implementar los ALG. Sin embargo, ALG no puede funcionar si los datos del protocolo están encriptados.

Otra posible solución a este problema es utilizar Transversal NAT técnicas utilizando protocolos tales como ATURDIR or Establecimiento de conectividad interactiva (ICE), o enfoques patentados en un controlador de borde de sesión. NAT transversal es posible en aplicaciones basadas en TCP y UDP, pero la técnica basada en UDP es más simple, más comprensible y más compatible con las NAT heredadas.^{[citación necesaria]} En cualquier caso, el protocolo de alto nivel debe diseñarse teniendo en cuenta el NAT transversal, y no funciona de manera confiable en NAT simétricos u otros NAT heredados que se comportan de manera deficiente.

Otras posibilidades son Protocolo de dispositivo de puerta de enlace de Internet, Protocolo de mapeo de puertos NAT (NAT-PMP), o Protocolo de control de puertos (PCP), pero estos requieren que el dispositivo NAT implemente ese protocolo.

La mayoría de los protocolos cliente-servidor (siendo FTP la principal excepción).), sin embargo, no envían información de contacto de capa 3 y no requieren ningún tratamiento especial por parte de los NAT. De hecho, evitar las complicaciones de NAT es prácticamente un requisito a la hora de diseñar nuevos protocolos de capa superior en la actualidad.

Los NAT también pueden causar problemas donde IPsec se aplica el cifrado y en los casos en que varios dispositivos, como Teléfonos SIP están ubicados detrás de un NAT. Los teléfonos que encriptan su señalización con IPsec encapsulan la información del puerto dentro de un paquete encriptado, lo que significa que los dispositivos NAT no pueden acceder ni traducir el puerto. En estos casos, los dispositivos NAT vuelven a las operaciones NAT simples. Esto significa que todo el tráfico que regresa a la NAT se asigna a un cliente, lo que hace que falle el servicio a más de un cliente detrás de la NAT. Hay un par de soluciones a este problema: una es usar TLS, que opera en capa 4 y no enmascara el número de puerto; otra es encapsular el IPsec dentro UDP – esta última es la solución elegida por TISPÁN para lograr un NAT transversal seguro, o un NAT con "Paso a través de IPsec" apoyo; otra es usar un controlador de borde de sesión para ayudar a atravesar el NAT.

Establecimiento de conectividad interactiva es una técnica transversal de NAT que no depende de la compatibilidad con ALG.

La vulnerabilidad del protocolo DNS anunciada por dan kaminsky el 8 de julio de 2008, se ve afectado indirectamente por la asignación de puertos NAT. Para evitar envenenamiento de caché DNS, es muy recomendable no traducir los números de puerto de origen UDP de las solicitudes DNS salientes desde un servidor DNS detrás de un firewall que implementa NAT. La solución alternativa recomendada para la vulnerabilidad de DNS es hacer que todos los servidores DNS de almacenamiento en caché utilicen puertos de origen UDP aleatorios. Si la función NAT elimina la aleatoriedad de los puertos de origen UDP, el servidor DNS se vuelve vulnerable.

Ejemplos de software NAT

• Conexión a Internet compartida (ICS): Implementación de NAT y DHCP incluida con Windows sistemas operativos de escritorio
• Filtro IP: incluido con (Abierta)Solaris, FreeBSD y NetBSD, disponible para muchos otros Unix-like sistemas operativos
• cortafuegos IP (ipfw): filtro de paquetes nativo de FreeBSD
• Netfilter a iptables/mesas de juego: el Linux filtro de paquetes
• NPF: filtro de paquetes nativo de NetBSD
• PF: filtro de paquetes nativo de OpenBSD
• Servicio de enrutamiento y acceso remoto: enrutamiento implementación incluida con windows Server sistemas operativos
• WinGate: implementación de enrutamiento de terceros para Windows

Vea también

Wikimedia Commons tiene medios relacionados con Traducción de Direcciones de Red.

Notas

Referencias

Enlaces externos

• Caracterización de diferentes TCP NAT en el Wayback Machine (archivado el 2006 de enero de 01): documento que analiza los diferentes tipos de NAT
• Anatomía: una mirada al interior de los traductores de direcciones de red: volumen 7, número 3, septiembre de 2004
• jeff tyson, Como funcionan las cosas: Cómo funciona la traducción de direcciones de red
• Enrutamiento con NAT at archive.today (archivado el 2013 de enero de 01) (parte de la documentación de IBM iSeries)
• Preguntas frecuentes sobre traducción de direcciones de red (NAT) - Cisco Systems