Articulo de referencia

Traducción de direcciones de red

Traducción de direcciones de red entre una red privada e Internet La traducción de direcciones de red ( NAT ) es un método para mapear un espacio de direcciones IP a otro modifi...

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

La traducción de direcciones de red ( NAT ) es un método para mapear un espacio de direcciones IP a otro modificando la información de la dirección de red en la cabecera IP de los paquetes mientras transitan por un dispositivo de enrutamiento de tráfico . [ 1 ] La técnica se utilizó inicialmente para evitar la necesidad de asignar una nueva dirección a cada host cuando se trasladaba una red o cuando se reemplazaba el proveedor de servicios de Internet ascendente pero este no podía enrutar el espacio de direcciones de la red. Es una herramienta popular y esencial para conservar el espacio de direcciones global ante el agotamiento de las direcciones IPv4 . Una dirección IP enrutable por Internet de una puerta de enlace NAT puede utilizarse para toda una red privada . [ 2 ]

Dado que 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 diversos casos de direccionamiento y en su efecto sobre el tráfico de red. Los proveedores de equipos que contienen implementaciones de NAT no suelen documentar los detalles del comportamiento de NAT. [ 2 ]

Historia

El Protocolo de Internet versión 4 (IPv4) utiliza direcciones de 32 bits, capaces de direccionar de forma única unos 4300 millones de dispositivos en la red. En 1992, se hizo evidente que esto no sería suficiente. El RFC 1631 de 1994 describe la NAT como una "solución a corto plazo" a los dos problemas más apremiantes que enfrentaba el Protocolo de Internet en ese momento: el agotamiento de las direcciones IP y la escalabilidad del enrutamiento. Para 2004, la NAT se había generalizado. [ 3 ] 

La técnica también se conoció como enmascaramiento de IP , que sugiere una técnica que oculta todo un espacio de direcciones IP, generalmente compuesto por direcciones IP privadas, detrás de una única dirección IP en otro espacio de direcciones, generalmente público. Debido a la popularidad de esta técnica para conservar el espacio de direcciones IPv4, el término NAT se convirtió prácticamente en sinónimo de enmascaramiento de IP. [ 4 ]

En 1996 se introdujo la traducción de direcciones de puerto (PAT), [ 5 ] que amplió la traducción de direcciones para incluir números de puerto.

NAT básico

El tipo más simple de NAT proporciona una traducción uno a uno de direcciones IP (RFC 1631). El RFC 2663 se refiere a este tipo de NAT como NAT básico , también llamado NAT uno a uno . En este tipo de NAT, solo se modifican las direcciones IP, la suma de verificación del encabezado IP y cualquier suma de verificación de nivel superior que incluya la dirección IP. El NAT básico se puede utilizar para interconectar dos redes IP con direcciones incompatibles. [ 2 ] 

NAT de uno a muchos

Mapeo de direcciones de red

La mayoría de los traductores de direcciones de red asignan varios hosts privados a una única dirección IP pública.

En una configuración típica, una red local utiliza una de las subredes de direcciones IP privadas designadas (RFC 1918 [ 6 ] ). La red cuenta con un enrutador con interfaces de red tanto en la red privada como en la pública. La dirección pública suele ser asignada por un proveedor de servicios de Internet . A medida que el tráfico pasa de la red privada a Internet, NAT traduce la dirección de origen de cada paquete de una dirección privada a la dirección pública del enrutador. El sistema NAT realiza un seguimiento de cada conexión activa. Cuando el enrutador recibe tráfico entrante de Internet, utiliza los datos de seguimiento de conexión obtenidos durante la fase de salida para determinar a qué dirección privada debe reenviar la respuesta. [ 2 ]

Los paquetes que pasan de la red privada a la red pública tendrán su dirección de origen modificada, mientras que los paquetes que pasan de la red pública de vuelta a la red privada tendrán su dirección de destino modificada. Para evitar ambigüedad en cómo se traducen las respuestas, se requieren modificaciones adicionales en los paquetes. La gran mayoría del tráfico de Internet utiliza el Protocolo de Control de Transmisión (TCP) o el Protocolo de Datagramas de Usuario (UDP). Para estos protocolos, los números de puerto se cambian de manera que la combinación de la dirección IP (dentro del encabezado IP ) y el número de puerto (dentro del encabezado de la capa de transporte ) en el paquete devuelto se pueda asignar sin ambigüedad al destino de red privada correspondiente. RFC 2663 utiliza el término traducción de direcciones de red y puertos ( NAPT ) para este tipo de NAT. [ 6 ] Otros nombres incluyen traducción de direcciones de puerto ( PAT ), enmascaramiento de IP , sobrecarga de NAT y NAT de muchos a uno . Este es el tipo de NAT más común 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 inicial establece la información necesaria en las tablas de traducción. De este modo, un navegador web dentro de la red privada puede navegar por sitios web que están fuera de la red, mientras que los navegadores web fuera de la red no pueden navegar por un sitio web alojado dentro de ella. [ a ] ​​Los protocolos que no se basan en TCP y UDP requieren otras técnicas de traducción.

La principal ventaja de la traducción de direcciones de red (NAT) de uno a muchos es la mitigación del agotamiento de direcciones IPv4, al permitir que redes enteras se conecten a Internet utilizando una única dirección IP pública.

Métodos de traducción

La traducción de direcciones y puertos de red puede implementarse de diversas maneras. Algunas aplicaciones que utilizan información de direcciones IP pueden necesitar determinar la dirección externa de un traductor de direcciones de red (NAT). Esta es la dirección que detectan sus pares 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 ubicados detrás de puertas de enlace NAT separadas.

Para este propósito, el RFC 3489 especificó el protocolo Simple Traversal of UDP over NATs ( STUN ) en 2003. Clasificó las implementaciones de NAT como NAT de cono completo , NAT de cono restringido (de direcciones) , NAT de cono restringido por puerto o NAT simétrico , y propuso una metodología para probar un dispositivo en consecuencia. Sin embargo, estos procedimientos han sido posteriormente descontinuados como estándares, ya que los métodos son inadecuados para evaluar correctamente muchos dispositivos. El RFC 5389 estandarizó nuevos métodos en 2008 y el acrónimo STUN representa desde entonces el nuevo título de la especificación: Session Traversal Utilities for NAT .

Dado que muchas implementaciones de NAT combinan varios tipos, es mejor referirse al comportamiento específico de cada NAT en lugar de usar la terminología Cono/Simétrico. El RFC 4787 intenta aliviar la confusión introduciendo una terminología estandarizada para los comportamientos observados. Para el primer punto de cada fila de la tabla anterior, el RFC caracterizaría las NAT de cono completo, cono restringido y cono restringido por puerto como de asignación independiente del punto final , mientras que caracterizaría una NAT simétrica como de asignación dependiente de la dirección y el puerto . Para el segundo punto de cada fila de la tabla anterior, RFC 4787 también etiquetaría NAT de cono completo como con un filtrado independiente del punto final , NAT de cono restringido como con un filtrado dependiente de la dirección , NAT de cono restringido por puerto como con un filtrado dependiente de la dirección y del puerto , y NAT simétrico como con un filtrado dependiente de la dirección o un filtrado dependiente de la dirección y del puerto . Otras clasificaciones del comportamiento de NAT mencionadas en el RFC incluyen si conservan los puertos, cuándo y cómo se actualizan las asignaciones, si las asignaciones externas pueden ser utilizadas por hosts internos (es decir, su comportamiento hairpinning ) y el nivel de determinismo que exhiben los NAT al aplicar todas estas reglas. [ 2 ] Específicamente, la mayoría de los NAT combinan NAT simétrico para conexiones salientes con asignación de puerto estática , donde los paquetes entrantes dirigidos a la dirección y puerto externos se redirigen a una dirección y puerto internos específicos.

Mapeo NAT frente a filtrado NAT

RFC 4787 distingue entre mapeo NAT y filtrado NAT. [ 2 ]

La sección 4.1 del RFC trata sobre la asignación NAT y especifica la traducción de una dirección IP y un número de puerto externos a una dirección IP y un número de puerto internos. Define la asignación independiente del punto final, la asignación dependiente de la dirección y la asignación dependiente de la dirección y el puerto, explica que estas tres opciones posibles no están relacionadas con la seguridad de la NAT, ya que la seguridad está determinada por el comportamiento de filtrado, y luego especifica que "UNA NAT DEBE tener un comportamiento de 'asignación independiente del punto final'".

La sección 5 del RFC trata sobre el filtrado NAT y describe los criterios que utiliza NAT para filtrar los paquetes que se originan en puntos finales externos específicos. Las opciones son filtrado independiente del punto final, filtrado dependiente de la dirección y filtrado dependiente de la dirección y el puerto. Se recomienda el filtrado independiente del punto final cuando se requiere la máxima transparencia de la aplicación, mientras que el filtrado dependiente de la dirección se recomienda cuando es fundamental un comportamiento de filtrado más estricto.

Algunos dispositivos NAT no cumplen con la RFC 4787, ya que tratan el mapeo y el filtrado NAT de la misma manera, por lo que su opción de configuración para cambiar el método de filtrado NAT también cambia el método de mapeo NAT (por ejemplo, Netgate TNSR Archivado el 30/01/2024 en Wayback Machine ).

Tipo de NAT y recorrido de NAT, función de la preservación de puertos para TCP

Los problemas de NAT traversal surgen cuando pares detrás de diferentes NAT intentan comunicarse. Una forma de resolver este problema es usar el reenvío de puertos . Otra forma es usar varias técnicas de NAT traversal. La técnica más popular para TCP NAT traversal es TCP hole punching .

La perforación de agujeros TCP requiere que la NAT siga el diseño de preservación de puertos para TCP. Para una comunicación TCP saliente dada, se utilizan los mismos números de puerto en ambos lados de la NAT. La preservación de puertos NAT para conexiones TCP salientes es crucial para el recorrido de NAT de TCP porque, bajo TCP, un puerto solo puede usarse para una comunicación a la vez. Los programas que vinculan distintos sockets TCP a puertos efímeros para cada comunicación TCP hacen imposible la predicción de puertos NAT para TCP. [ 2 ]

Por otro lado, para UDP, las NAT no requieren la preservación del puerto. De hecho, pueden producirse múltiples comunicaciones UDP (cada una con un punto final distinto ) en el mismo puerto de origen, y las aplicaciones suelen reutilizar el mismo socket UDP para enviar paquetes a distintos hosts. Esto simplifica la predicción del puerto, ya que se trata del mismo puerto de origen para cada paquete.

Además, la preservación de puertos en NAT para TCP permite que los protocolos P2P ofrezcan menor complejidad y menor 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. [ 2 ] [ 7 ]

Sin embargo, si dos hosts internos intentan comunicarse con el mismo host externo utilizando 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 conservación del puerto y reasignarlo. [ 2 ] : 9 A partir de 2006Aproximadamente el 70% de los clientes en redes peer-to-peer (P2P) empleaban alguna forma de NAT. [ 8 ]

Implementación

Establecer una comunicación bidireccional

En NAT bidireccional, la sesión se puede establecer tanto desde dominios internos como externos.

Cada paquete TCP y UDP contiene un número de puerto de origen y un número de puerto de destino. Cada uno de estos paquetes se encapsula en un paquete IP, cuyo encabezado IP contiene una dirección IP de origen y una dirección IP de destino. La tripleta dirección IP/protocolo/número de puerto define una asociación con un socket 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 443 se conecta mediante un socket al software del servidor web y el puerto 465 al demonio SMTP de un servidor de correo . [ 9 ] La dirección IP de un servidor público también es importante, con una unicidad global similar a la de una dirección postal o un número de teléfono. Tanto la dirección IP como el número de puerto deben ser conocidos correctamente por todos los hosts que deseen comunicarse con éxito.

Las direcciones IP privadas, tal como se describen en la RFC 1918, solo se pueden usar en redes privadas no conectadas directamente a Internet. Los puertos son puntos finales de comunicación exclusivos de cada host, por lo que la conexión a través del dispositivo NAT se mantiene mediante la asignación combinada de puerto y dirección IP. Una dirección privada dentro 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 simultáneamente.

Proceso de traducción

Con NAT, todas las comunicaciones enviadas a hosts externos contienen la dirección IP externa y la información del puerto del dispositivo NAT, en lugar de las direcciones IP o los números de puerto de los hosts internos. NAT solo traduce las direcciones IP y los puertos de sus hosts internos, ocultando así la verdadera ubicación de un host interno en una red privada.

Cuando un ordenador de 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 la cabecera del paquete con la dirección IP externa del dispositivo NAT. A continuación, PAT puede asignar a la conexión un número de puerto de un conjunto de puertos disponibles, [ b ] insertando este número de puerto en el campo de puerto de origen. El paquete se reenvía a la red externa. El dispositivo NAT crea entonces 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 con la misma dirección IP de origen interna y número de puerto se traducen a la misma dirección IP de origen externa y número de puerto. El ordenador que recibe un paquete que ha pasado por NAT establece una conexión con el puerto y la dirección IP especificados en el paquete modificado, sin saber 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 el puerto de destino en la cabecera del paquete. Si encuentra una coincidencia, la dirección IP y el puerto de destino se reemplazan con los valores de la tabla y el paquete se reenvía a la red interna. De lo contrario, si el puerto de destino del paquete entrante no se encuentra en la tabla de traducción, el paquete se descarta o rechaza porque el dispositivo PAT desconoce a dónde enviarlo.

Aplicaciones

Enrutamiento
La traducción de direcciones de red se puede utilizar para mitigar la superposición de direcciones IP. [ 10 ] [ 11 ] La superposición de direcciones ocurre cuando hosts en diferentes redes con el mismo espacio de direcciones IP intentan llegar al mismo host de destino. Esto suele ser una configuración incorrecta y puede resultar de la fusión de dos redes o subredes, especialmente cuando se utiliza el direccionamiento de red privada RFC 1918. El host de destino experimenta tráfico que aparentemente proviene de 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 renumerar para eliminar la superposición o realizar una traducción de direcciones de red.
Balanceo de carga
En las aplicaciones cliente-servidor , los balanceadores de carga reenvían las solicitudes de los clientes a un conjunto de servidores para gestionar la carga de trabajo de cada uno. La traducción de direcciones de red (NAT) puede utilizarse para asignar una dirección IP representativa del clúster de servidores a hosts específicos que atienden la solicitud. [ 12 ] [ 13 ] [ 14 ] [ 15 ]

La traducción inversa de direcciones y puertos (RAPT o RAT) de IEEE permite que un host cuya dirección IP real cambia periódicamente permanezca accesible como servidor a través de una dirección IP fija. [ 16 ] La implementación de RAPT de Cisco es una sobrecarga de PAT o NAT que asigna múltiples direcciones IP privadas a una única dirección IP pública. Se pueden asignar múltiples 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. [ c ] PAT intenta preservar el puerto de origen original. Si este puerto de origen ya está en uso, PAT asigna el primer número de puerto disponible a partir del inicio 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 y las direcciones IP externas disponibles.

El mapeo de direcciones y puertos es una propuesta de Cisco que combina la traducción de direcciones y puertos con la tunelización de paquetes IPv4 a través de la red IPv6 interna del proveedor de servicios de Internet (ISP) . En efecto, se trata de una alternativa (casi) sin estado a la NAT de nivel de operador y a DS-Lite , que traslada la función de traducción de direcciones y puertos IPv4 (y el mantenimiento del estado de la NAT) por completo a la implementación de NAT existente en el equipo del cliente . De esta forma, se evitan los problemas de NAT444 y de estado de la NAT de nivel de operador, y además se proporciona un mecanismo de transición para el despliegue de IPv6 nativo simultáneamente, con muy poca complejidad adicional.

Problemas y limitaciones

Los hosts detrás de enrutadores con NAT habilitado no tienen conectividad de extremo a extremo y no pueden participar en algunos protocolos de Internet. Los servicios que requieren el inicio de conexiones TCP desde la red externa, o que utilizan protocolos sin estado como los que usan UDP , pueden verse interrumpidos. 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 admitir una instancia de NAT entre hosts participantes ( FTP en "modo pasivo" , por ejemplo), a veces con la ayuda de una puerta de enlace a nivel de aplicación (véase §  Aplicaciones afectadas por NAT ), pero fallan cuando ambos sistemas están separados de Internet por NAT. El uso de NAT también complica los protocolos de tunelización como IPsec porque NAT modifica valores en las cabeceras, lo que interfiere con las comprobaciones de integridad realizadas por IPsec y otros protocolos de tunelización.

La conectividad de extremo a extremo ha sido un principio fundamental de Internet, respaldado, por ejemplo, por el Consejo de Arquitectura de Internet . Los documentos arquitectónicos actuales de Internet señalan que NAT es una violación del principio de extremo a extremo , pero que NAT tiene un papel válido en un diseño cuidadoso. [ 17 ] Existe una preocupación considerablemente mayor con el uso de NAT en IPv6, y muchos arquitectos de IPv6 creen que IPv6 fue diseñado para eliminar la necesidad de NAT. [ 18 ]

Una implementación que solo rastrea los puertos puede agotarse rápidamente debido a aplicaciones internas que utilizan múltiples conexiones simultáneas, como una solicitud HTTP para 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 único puerto local con varios hosts remotos. Este rastreo adicional aumenta la complejidad de la implementación y los recursos computacionales en el dispositivo de traducción.

Debido a que las direcciones internas están ocultas tras una única dirección pública, resulta imposible que los hosts externos inicien directamente una conexión con un host interno específico. Aplicaciones como VoIP , videoconferencias y otras aplicaciones peer-to-peer deben utilizar técnicas de traducción de direcciones de red (NAT) para funcionar.

Fragmentación y sumas de verificación

La traducción de direcciones de red (NAT) pura, que opera únicamente sobre IP, puede o no interpretar correctamente protocolos con cargas útiles que contienen información sobre IP, como ICMP . Esto depende de si la carga útil es interpretada por un host dentro o fuera de la capa de traducción. Los protocolos básicos como TCP y UDP no pueden funcionar correctamente a menos que la NAT actúe más allá de la capa de red.

Los paquetes IP incluyen una suma de verificación en la cabecera, que detecta errores únicamente en dicha cabecera. Los datagramas IP pueden fragmentarse, por lo que es necesario que un NAT los vuelva a ensamblar para permitir el recálculo correcto de las sumas de verificación de nivel superior y el seguimiento preciso de qué paquetes pertenecen a qué conexión.

TCP y UDP tienen una suma de verificación que abarca todos los datos que transportan, así como la cabecera TCP o UDP, además de una pseudocabecera que contiene las direcciones IP de origen y destino del paquete que lleva la cabecera TCP o UDP. Para que una NAT de origen transmita TCP o UDP correctamente, debe recalcular la suma de verificación de la cabecera TCP o UDP basándose en las direcciones IP traducidas, no en las originales, e insertar esa suma de verificación en la cabecera TCP o UDP del primer paquete del conjunto fragmentado de paquetes.

Como alternativa, el host de origen puede realizar un descubrimiento de MTU de ruta para determinar el tamaño del paquete que se puede transmitir sin fragmentación y, a continuación, activar el bit de no fragmentación (DF) en el campo de encabezado del paquete correspondiente. Esta es solo una solución unidireccional, ya que el host receptor puede enviar paquetes de cualquier tamaño, los cuales pueden fragmentarse antes de llegar al NAT.

Términos variantes

ADNT

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

DNAT se utiliza 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 reenvío de puertos o DMZ cuando se aplica a un servidor completo, que queda expuesto a la WAN, convirtiéndose en algo similar a una zona desmilitarizada (DMZ) militar sin protección .

SNAT

El significado del término SNAT varía según el proveedor: [ 19 ] [ 20 ] [ 21 ]

  • NAT de origen es una expansión común y es la contraparte de NAT de destino ( DNAT ). Se utiliza para describir NAT de uno a muchos; NAT para conexiones salientes a servicios públicos.
  • Cisco Systems utiliza NAT con estado [ 22 ].
  • WatchGuard utiliza NAT estático [ 23 ].
  • F5 [ 24 ] y Microsoft utilizan NAT seguro (en relación con el servidor ISA ).

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

Traducción dinámica de direcciones de red

Cómo funciona la NAT dinámica

La NAT dinámica, al igual que la NAT estática, no es común en redes pequeñas, pero sí en grandes corporaciones con redes complejas. Mientras que la NAT estática proporciona una asignación uno a uno de direcciones IP internas a direcciones IP públicas estáticas, la NAT dinámica utiliza un grupo de direcciones IP públicas. [ 25 ] [ 26 ]

NAT en horquilla

El NAT hairpinning , también conocido como NAT loopback o NAT reflection , [ 27 ] es una función presente en muchos routers de consumo [ 28 ] que permite que una máquina de la LAN acceda a otra máquina de la LAN mediante la dirección IP externa de la LAN/router (con el reenvío de puertos configurado en el router para dirigir las solicitudes a la máquina correspondiente de la LAN). Este concepto se describe oficialmente en el RFC 5128 de 2008 . 

A continuación se describe un ejemplo de red:

  • Dirección pública: 203.0.113.1 . Esta es la dirección de la interfaz WAN del enrutador.
  • Dirección interna del enrutador: 192.168.1.1
  • Dirección del servidor: 192.168.1.2
  • Dirección de un ordenador local: 192.168.1.100

Si un paquete es enviado a 203.0.113.1 por una computadora en 192.168.1.100 , el paquete normalmente se enrutaría a la puerta de enlace predeterminada (el enrutador) [ d ] . 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 proviniera de esa interfaz. Determina el destino para ese paquete, basándose en 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 entonces el host en esa dirección recibe el paquete. Si no hay ninguna regla DNAT aplicable disponible, el enrutador descarta el paquete. Se puede enviar una respuesta ICMP Destino inalcanzable . Si alguna regla DNAT está presente, la traducción de direcciones sigue en efecto; el enrutador sigue reescribiendo la dirección IP de origen en el paquete.

En el ejemplo anterior de una conexión TCP al servidor, el ordenador local inicia la conexión enviando un paquete desde 192.168.1.100 a 203.0.113.1 a través del enrutador, y el servidor recibe el paquete con esta dirección de origen y la dirección de destino reescrita por el enrutador ( 192.168.1.2 ). Dado que la dirección de origen forma parte del mismo dominio de difusión que el servidor, responderá con un paquete destinado directamente al ordenador local en la capa 2 , sin la intervención del enrutador. Como el ordenador local no esperaba tráfico de 192.168.1.2 (la dirección local del servidor), sino de 203.0.113.1 , la dirección a la que realmente pretendía conectarse, descartará la respuesta silenciosamente.

Para habilitar la comunicación bidireccional entre estos hosts mediante la dirección externa, es necesario configurar una regla SNAT. Esta regla especifica que el tráfico recibido de la red local y destinado al servidor (a su dirección local, tras la reescritura) debe modificar su dirección de origen a una dirección del enrutador. De esta forma, la respuesta del servidor se envía al enrutador, que aplica las transformaciones SNAT y DNAT inversas y envía la respuesta esperada al equipo local. Así, la comunicación bidireccional es posible entre hosts dentro de la red LAN a través de la dirección IP pública, siempre que se configuren las reglas NAT adecuadas.

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. [ 29 ] El amplio espacio de direcciones de IPv6 elimina la necesidad de conservar direcciones y cada dispositivo puede recibir una dirección única globalmente enrutable. El uso de direcciones locales únicas en combinación con la traducción de prefijos de red puede lograr resultados similares a NAT.

El amplio espacio de direcciones de IPv6 aún puede verse comprometido, dependiendo de la longitud real del prefijo proporcionado por el operador. No es raro que se le asigne un prefijo /64 —la subred más pequeña recomendada— para toda una red doméstica, lo que requiere el uso de diversas técnicas para subdividir manualmente el rango y que todos los dispositivos permanezcan accesibles. [ 30 ] En tales casos, puede ser necesario utilizar la traducción completa de direcciones de red y puertos (NAPT) en IPv6, generalmente denominada NAT66, donde un prefijo ULA de IPv6 se enmascara a una única dirección única global (GUA) de IPv6. [ 31 ] [ 32 ] [ 33 ] El blog de APNIC describe un caso en el que al autor solo se le proporcionó una única dirección (/128). [ 32 ]

Aplicaciones afectadas por NAT

Algunos protocolos de capa de aplicación , como el Protocolo de Transferencia de Archivos (FTP) y el Protocolo de Inicio de Sesión (SIP), envían direcciones de red explícitas dentro de sus datos de aplicación. El FTP en modo activo, por ejemplo, utiliza conexiones separadas para el tráfico de control (comandos) y para el tráfico de datos (contenido de los archivos). Al solicitar una transferencia de archivos, el host que realiza la solicitud identifica la conexión de datos correspondiente mediante sus direcciones de capa de red y de capa de transporte . Si el host que realiza la solicitud se encuentra detrás de un firewall 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 controla comúnmente las llamadas de voz sobre IP y sufre el mismo problema. SIP y su protocolo de descripción de sesión (SDP) pueden utilizar varios puertos para establecer una conexión y transmitir un flujo de voz a través del Protocolo de Transporte en Tiempo Real (RTP) . Las direcciones IP y los números de puerto están codificados en los datos de carga útil y deben conocerse antes de atravesar las NAT. Sin técnicas especiales, como STUN , el comportamiento de NAT es impredecible y las comunicaciones pueden fallar. El software o hardware de puerta de enlace de capa de aplicación (ALG) puede corregir estos problemas. Un módulo de software ALG que se ejecuta en un firewall NAT actualiza los datos de carga útil que se invalidan debido a la traducción de direcciones. Los ALG necesitan comprender el protocolo de capa superior que deben corregir, por lo que cada protocolo con este problema requiere un ALG independiente. Por ejemplo, en muchos sistemas Linux, existen módulos del kernel llamados rastreadores de conexión que sirven para implementar los ALG. Sin embargo, los ALG no pueden funcionar si los datos del protocolo están cifrados.

Otra posible solución a este problema es utilizar técnicas de evasión de NAT mediante protocolos como STUN o Interactive Connectivity Establishment (ICE), o bien, enfoques propietarios en un controlador de borde de sesión . La evasión de NAT es posible tanto en aplicaciones basadas en TCP como en UDP, pero la técnica basada en UDP es más sencilla, más conocida y más compatible con las NAT heredadas. En cualquier caso, el protocolo de alto nivel debe diseñarse teniendo en cuenta la evasión de NAT, y no funciona de forma fiable en NAT simétricas ni en otras NAT heredadas con un comportamiento deficiente.

Otras posibilidades son el Protocolo de Control de Puertos (PCP), [ 34 ] el Protocolo de Asignación de Puertos NAT (NAT-PMP) o el Protocolo de Dispositivo de Puerta de Enlace a Internet , pero estos requieren que el dispositivo NAT implemente ese protocolo.

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

Los NAT también pueden causar problemas cuando se aplica el cifrado IPsec y en casos donde varios dispositivos, como teléfonos SIP, se encuentran detrás de un NAT. Los teléfonos que cifran su señalización con IPsec encapsulan la información del puerto dentro de un paquete cifrado, lo que significa que los dispositivos NAT no pueden acceder ni traducir el puerto. En estos casos, los dispositivos NAT vuelven a operaciones NAT simples. Esto significa que todo el tráfico que regresa al NAT se asigna a un solo cliente, lo que provoca que el servicio a más de un cliente detrás del NAT falle. Hay un par de soluciones para este problema: una es usar TLS , que opera en la capa 4 y no enmascara el número de puerto; otra es encapsular IPsec dentro de UDP , siendo esta última la solución elegida por TISPAN para lograr un recorrido NAT seguro, o un NAT con soporte para "IPsec Passthru" ; otra es usar un controlador de borde de sesión para ayudar a recorrer el NAT .

El Establecimiento de Conectividad Interactiva (ICE) es una técnica de travesía NAT que no depende del soporte ALG.

La vulnerabilidad del protocolo DNS anunciada por Dan Kaminsky el 8 de julio de 2008 [ 35 ] se ve afectada indirectamente por la asignación de puertos NAT. Para evitar el envenenamiento de la caché DNS , es muy recomendable no traducir los números de puerto de origen UDP de las solicitudes DNS salientes de un servidor DNS detrás de un cortafuegos que implementa NAT. La solución recomendada para la vulnerabilidad DNS es hacer que todos los servidores DNS de caché utilicen puertos de origen UDP aleatorios. Si la función NAT elimina la aleatorización de los puertos de origen UDP, el servidor DNS se vuelve vulnerable.

Ejemplos de software NAT

Véase también

Notas

  1. La mayoría de los dispositivos NAT actuales permiten al administrador de red configurar entradas estáticas en la tabla de traducción para las conexiones desde la red externa a la red interna enmascarada. Esta función se conoce comúnmente como NAT estática . Puede implementarse de dos maneras: reenvío de puertos , que reenvía el tráfico desde un puerto externo específico a un host interno en un puerto determinado, y designación de un host DMZ , que reenvía todo el tráfico recibido en la interfaz externa (en cualquier número de puerto) a una dirección IP interna, conservando el puerto de destino. Ambos tipos pueden estar disponibles en el mismo dispositivo NAT.
  2. Dado que el enrutador NAT asigna un puerto individual a cada conexión saliente, un gran número de conexiones salientes puede saturar el rango de puertos disponibles. Como los puertos suelen liberarse cuando la conexión no genera más tráfico durante un tiempo determinado, el número máximo de conexiones activas se limita a aproximadamente 64 000.
  3. Los números de puerto son enteros de 16 bits. Teóricamente, el número total de direcciones internas que se pueden traducir a una dirección externa podría llegar a ser de hasta 65 536 por dirección IP. En la práctica, el número de puertos que se pueden asignar a una sola dirección IP ronda los 4000.
  4. A menos que se haya establecido una ruta explícita en las tablas de enrutamiento del ordenador .
  5. Este problema se puede evitar utilizando SFTP en lugar de FTP.

Referencias

  1. Manual de protocolos de red (2.ª ed.). Javvin Technologies Inc. 2005. pág. 27. ISBN   9780974094526. Consultado el 16 de septiembre de 2014 .
  2. 1 2 3 4 5 6 7 8 9 François Audet; Cullen Jennings (enero de 2007). Requisitos de comportamiento de la traducción de direcciones de red (NAT) para UDP unicast . IETF . doi : 10.17487/RFC4787 . RFC 4787 .
  3. Geoff Huston (septiembre de 2004). "Anatomía: una mirada al interior de los traductores de direcciones de red" (PDF) . The Internet Protocol Journal .
  4. "¿Qué es la traducción de direcciones de red (NAT)?" . Cisco . Consultado el 13 de julio de 2026 .
  5. Heon Y. Yeom; Jungsoo Ha; Ilhwan Kim (1996). "Multiplexación IP mediante traductor transparente de direcciones de puerto" . USENIX LISA.
  6. 1 2 Wing, Dan (2010-07-01). "Traducción de direcciones de red: Ampliando el espacio de direcciones de Internet". IEEE Internet Computing . 14 (4): 66– 70. doi : 10.1109/MIC.2010.96 . ISSN 1089-7801 . S2CID 31082389 .  
  7. "Caracterización y medición del tráfico TCP a través de NAT y cortafuegos" . Diciembre de 2006.
  8. "Iluminando las sombras: Medición oportunista de redes y web" . Diciembre de 2006. Archivado del original el 24 de julio de 2010.
  9. RFC 8314 
  10. "Uso de NAT en redes superpuestas" . Agosto de 2005.
  11. "Escenario problemático de VPN con subredes superpuestas" . Septiembre de 2017. Archivado del original el 15 de junio de 2020. Consultado el 15 de junio de 2020 .
  12. Srisuresh, Pyda; Gan, Der-Hwa (agosto de 1998). Distribución de carga mediante traducción de direcciones de red IP . IETF . RFC 2391 . 
  13. "¿Qué es el balanceo de carga de capa 4?" Junio ​​de 2020.
  14. "¿Qué es el balanceo de carga?" Noviembre de 2018.
  15. "Configurar el balanceo de carga del servidor mediante NAT dinámico" . Junio ​​de 2018.
  16. Singh, R.; Tay, YC; Teo, WT; Yeow, SW (1999). "RAT: Un impulso rápido (¿y sucio?) para el soporte de movilidad". Actas de WMCSA'99. Segundo Taller IEEE sobre Sistemas y Aplicaciones de Computación Móvil . págs. 32–40 . CiteSeerX 10.1.1.40.461 . doi : 10.1109/MCSA.1999.749275 . ISBN   978-0-7695-0025-6. S2CID 7657883 . 
  17. Bush, R.; Meyer, D. (2002). Algunas directrices y filosofía de arquitectura de Internet . IETF . doi : 10.17487/RFC3439 . RFC 3439 .
  18. Velde, G. Van de; Hain, T.; Droms, R.; Carpenter, B.; Klein, E. (2007). Protección de red local para IPv6 . IETF . doi : 10.17487/RFC4864 . RFC 4864 .
  19. "Resiliencia IP mejorada mediante NAT con estado de Cisco" . Cisco .
  20. "Usar NAT para acceso público a servidores con direcciones IP privadas en la red privada (ejemplo de configuración de WatchGuard)" (PDF) . www.watchguard.com . Archivado del original (PDF) el 17 de enero de 2013.
  21. "K7820: Descripción general de las características de SNAT" . AskF5 . 28 de agosto de 2007. Consultado el 24 de febrero de 2019 .
  22. "Resiliencia IP mejorada mediante NAT con estado de Cisco" . Cisco .
  23. "Usar NAT para acceso público a servidores con direcciones IP privadas en la red privada (ejemplo de configuración de WatchGuard)" (PDF) . www.watchguard.com . Archivado del original (PDF) el 17 de enero de 2013.
  24. "K7820: Descripción general de las características de SNAT" . AskF5 . 28 de agosto de 2007. Consultado el 24 de febrero de 2019 .
  25. Upravnik (26 de enero de 2016). "NAT dinámico" . Estudio CCNA . Recuperado el 19 de abril de 2022 .
  26. "NAT dinámico" . Consultado el 19 de abril de 2022 .
  27. "¿Qué es NAT Reflection/NAT Loopback/NAT Hairpinning?" . NYC Networkers. 09-11-2014 . Consultado el 27-04-2017 .
  28. "Enrutadores de bucle NAT – OpenSim" ( MediaWiki ) . OpenSimulator . 2013-10-21 . Consultado el 2014-02-21 .
  29. van Beijnum, Iljitsch (23 de julio de 2008). "Tras una fuerte resistencia, NAT podría llegar a IPv6 después de todo" . Ars Technica . Consultado el 24 de abril de 2014 .
  30. Dupont, Kasper (18 de agosto de 2015). "Subred: subredes IPv6 en una /64: ¿qué fallará y cómo solucionarlo?" . Server Fault . Consultado el 20 de abril de 2023 .
  31. Hogg, Scott (28-12-2021). "Pensabas que no existía NAT para IPv6, pero NAT todavía existe" . Blog de Infoblox . Consultado el 12-09-2025 .
  32. 1 2 Cilloni, Marco (2018-02-01). "NAT66: Lo bueno, lo malo, lo feo" . Blog de APNIC . Recuperado el 2023-04-20 .
  33. "Ejemplos de NAT (NAT IPv6) - Wiki de OpenWrt" . Consultado el 11 de junio de 2026 .
  34. D. Wing, Ed; Cheshire, S.; Boucadair, M.; Penno, R.; Selkirk, P. (2013). Protocolo de control de puertos (PCP) . IETF . doi : 10.17487/RFC6887 . RFC 6887 .
  35. Messmer, Ellen (8 de julio de 2008). "Una grave falla en el DNS podría interrumpir Internet" . Network World . Archivado del original el 13 de febrero de 2009. Consultado el 14 de junio de 2021 .
  • Caracterización de diferentes NAT TCP en Wayback Machine (archivado el 11/01/2006) documento que analiza los diferentes tipos de NAT. 
  • Anatomía: Un vistazo al interior de los traductores de direcciones de red – Volumen 7, Número 3, septiembre de 2004
  • Jeff Tyson, HowStuffWorks: Cómo funciona la traducción de direcciones de red
  • Preguntas frecuentes sobre la traducción de direcciones de red (NAT) – Cisco Systems