La traducción de direcciones de red ( NAT ) es un método para mapear un espacio de direcciones IP en otro modificando la información de la dirección de red en el encabezado IP de los paquetes mientras están en tránsito a través de un dispositivo de enrutamiento de tráfico . [1] La técnica se utilizó originalmente para evitar la necesidad de asignar una nueva dirección a cada host cuando se movía una red o cuando se reemplazaba el proveedor de servicios de Internet ascendente , pero no podía 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 al agotamiento de direcciones IPv4 . Una dirección IP enrutable por Internet de una puerta de enlace NAT se puede utilizar para una red privada completa . [2]
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 red. Los proveedores de equipos que contienen implementaciones de NAT no suelen documentar los detalles específicos del comportamiento de NAT. [2]
IPv4 utiliza direcciones de 32 bits, capaces de direccionar de forma única a unos 4.300 millones de dispositivos. En 1992 se hizo evidente que eso no sería suficiente. La RFC 1631 de 1994 describe a NAT como una "solución a corto plazo" para los dos problemas más acuciantes que enfrentaba la Internet IP en ese momento: el agotamiento de las direcciones IP y el escalamiento del enrutamiento. En 2004, NAT se había generalizado. [3]
El tipo más simple de NAT proporciona una traducción uno a uno de las direcciones IP (RFC 1631). El RFC 2663 se refiere a este tipo de NAT como NAT básica ; también se denomina NAT uno a uno . En este tipo de NAT, solo se modifican las direcciones IP, la suma de comprobación del encabezado IP y cualquier suma de comprobación de nivel superior que incluya la dirección IP. La NAT básica se puede utilizar para interconectar dos redes IP que tienen direcciones incompatibles. [2]
.jpg/1280px-Network_Address_Translation_(file2).jpg){kind=spacer}
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:
Todos los paquetes IP tienen una dirección IP de origen y una dirección IP de destino. Normalmente, 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üedades en cómo se traducen las respuestas, se requieren modificaciones adicionales a 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 modo que la combinación de dirección IP (dentro del encabezado IP ) y número de puerto (dentro del encabezado de capa de transporte ) en el paquete devuelto se pueda asignar de forma inequívoca 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. [4] 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 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 únicamente cuando la conversación se origina en la red privada, ya que la transmisión inicial de origen es la que establece la información requerida en las tablas de traducción. De esta manera, un navegador web dentro de la red privada podría navegar por sitios web que se encuentran fuera de la red, mientras que los navegadores web fuera de la red no podrían 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.
Un beneficio adicional del NAT de uno a muchos es que mitiga el agotamiento de direcciones IPv4 al permitir que redes enteras se conecten a Internet utilizando una única dirección IP pública. [b]
La traducción de direcciones de red y puertos se puede implementar de varias maneras. Algunas aplicaciones que utilizan 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 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 configurar una ruta de comunicación directa entre dos clientes que se encuentran detrás de puertas de enlace NAT separadas.
Para este propósito, RFC 3489 especificó un protocolo llamado Simple Traversal of UDP over NATs ( STUN ) en 2003. Clasificó las implementaciones de NAT como NAT de cono completo , NAT de cono restringido (dirección) , 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 quedado obsoletos desde entonces como 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 STUN ahora representa el nuevo título de la especificación: Utilidades de Traversal de Sesión para NAT .
Muchas implementaciones de NAT combinan estos tipos, por lo que es mejor hacer referencia a un comportamiento NAT individual específico en lugar de utilizar la terminología de cono/simétrico. El RFC 4787 intenta aliviar la confusión al introducir una terminología estandarizada para los comportamientos observados. Para el primer punto de cada fila de la tabla anterior, el RFC caracterizaría a los NAT de cono completo, cono restringido y cono restringido por puerto como si tuvieran un mapeo independiente del punto final , mientras que caracterizaría a un NAT simétrico como si tuviera un mapeo dependiente de la dirección y el puerto . Para la segunda viñeta en cada fila de la tabla anterior, RFC 4787 también etiquetaría a Full-Cone NAT como que tiene un filtrado independiente del punto final , Restricted-Cone NAT como que tiene un filtrado dependiente de la dirección , Port-Restricted Cone NAT como que tiene un filtrado dependiente de la dirección y el puerto , y Symmetric NAT como que tiene un filtrado dependiente de la dirección o un filtrado dependiente de la dirección y el 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 de horquilla ) y el nivel de determinismo que exhiben las NAT al aplicar todas estas reglas. [2] Específicamente, la mayoría de las NAT combinan NAT simétrica para conexiones salientes con mapeo de puerto estático , donde los paquetes entrantes dirigidos a la dirección y puerto externos se redirigen a una dirección y puerto internos específicos.
RFC 4787 [2] hace una distinción entre el mapeo NAT y el filtrado NAT.
La sección 4.1 de la RFC cubre el mapeo de NAT y especifica cómo una dirección IP externa y un número de puerto deben traducirse a una dirección IP interna y un número de puerto. Define el mapeo independiente del punto final, el mapeo dependiente de la dirección y el mapeo dependiente de la dirección y el puerto, explica que estas tres opciones posibles no se relacionan con la seguridad del NAT ya que la seguridad está determinada por el comportamiento de filtrado y luego especifica "UNA NAT DEBE tener un comportamiento de 'mapeo independiente del punto final'".
La Sección 5 de la RFC cubre el filtrado NAT y describe qué criterios utiliza el NAT para filtrar 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. El filtrado independiente del punto final se recomienda cuando se requiere la máxima transparencia de la aplicación, mientras que el filtrado dependiente de la dirección se recomienda cuando es más importante un comportamiento de filtrado más estricto.
Algunos dispositivos NAT aún no cumplen con la norma RFC 4787, ya que tratan la asignación y el filtrado de NAT de la misma manera, de modo que su opción de configuración para cambiar el método de filtrado de NAT también cambia el método de asignación de NAT (por ejemplo, Netgate TNSR). El firewall PF tiene un parche disponible para habilitar la compatibilidad con RFC 4787, pero aún no se ha fusionado.
El problema de cruce de NAT 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 de cruce de NAT. La técnica más popular para el cruce de NAT TCP es la perforación de agujeros TCP .
La perforación de agujeros TCP requiere que el 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 del NAT. La preservación de puertos NAT para conexiones TCP salientes es crucial para la travesía NAT TCP porque, bajo TCP, un puerto solo se puede utilizar para una comunicación a la vez. Los programas que vinculan distintos sockets TCP a puertos efímeros para cada comunicación TCP, hacen que la predicción de puertos NAT sea imposible para TCP. [2]
Por otro lado, para UDP, los NAT no necesitan la preservación de puertos. De hecho, pueden ocurrir múltiples comunicaciones UDP (cada una con un punto final distinto ) en el mismo puerto de origen, y las aplicaciones generalmente reutilizan el mismo socket UDP para enviar paquetes a hosts distintos. 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 hay necesidad de utilizar un tercero (como STUN) para descubrir el puerto NAT ya que la aplicación misma ya conoce el puerto NAT. [2] [5]
Sin embargo, si dos hosts internos intentan comunicarse con el mismo host externo utilizando el mismo número de puerto, el NAT puede intentar utilizar 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. [2] : 9
En 2006 [actualizar], aproximadamente el 70% de los clientes en redes P2P empleaban algún tipo de NAT. [6]
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 se encapsula en un paquete IP, cuyo encabezado IP contiene una dirección IP de origen y una dirección IP de destino. El triplete dirección IP/protocolo/número de puerto define una asociación con un socket de red .
En el caso de los servicios de acceso público, como los servidores web y de correo, el número de puerto es importante. Por ejemplo, el puerto 443 se conecta a través de un socket al software del servidor web y el puerto 465 al demonio SMTP de un servidor de correo . [7] La dirección IP de un servidor público también es importante, similar en su unicidad 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 conocidos correctamente 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 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 usan el mismo número de puerto de origen para establecer diferentes conexiones externas al mismo tiempo.
Un dispositivo NAT es similar a un sistema telefónico en una oficina que tiene un número de teléfono público y múltiples extensiones. Las llamadas salientes realizadas desde la oficina parecen provenir todas del mismo número de teléfono. Sin embargo, una llamada entrante que no especifica una extensión no puede transferirse 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. [8]
Con NAT, todas las comunicaciones enviadas a hosts externos contienen en realidad 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 del host interno. 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 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 el encabezado 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, [c] 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. A continuación, 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 posteriores de la misma dirección IP de origen interna y el mismo número de puerto se traducen a la misma dirección IP de origen externa y el mismo número de puerto. El ordenador 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 modificado, sin tener en cuenta el hecho de que se está traduciendo la dirección suministrada.
Al recibir un paquete de la red externa, el dispositivo NAT busca en la tabla de traducción el puerto de destino que aparece en el encabezado del paquete. Si 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.
IEEE Reverse Address and Port Translation (RAPT o RAT) permite que un host cuya dirección IP real cambia de vez en cuando siga siendo accesible como servidor a través de una dirección IP doméstica fija. [15] La implementación RAPT de Cisco es una sobrecarga PAT o NAT y asigna múltiples direcciones IP privadas a una única dirección IP pública. Se pueden asignar múltiples direcciones a una única 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. [d] 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 comenzando desde el comienzo 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 el puerto de origen original nuevamente. Este proceso continúa hasta que se queda sin puertos disponibles y direcciones IP externas.
Mapping of Address and Port es una propuesta de Cisco que combina la traducción de direcciones y puertos con la tunelización de los paquetes IPv4 a través de la red IPv6 interna de un proveedor de servicios de Internet . En efecto, es una alternativa (casi) sin estado a NAT de nivel de operador y DS-Lite que lleva la función de traducción de direcciones y puertos IPv4 (y el mantenimiento del estado de NAT) completamente a la implementación de NAT de equipos de las instalaciones del cliente existentes . De esta manera, se evitan los problemas de NAT444 y de estado de NAT de nivel de operador y también se proporciona un mecanismo de transición para la implementación de IPv6 nativo al mismo tiempo con muy poca complejidad adicional.
Los hosts detrás de enrutadores habilitados para NAT 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 utilizan 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 los hosts participantes (por ejemplo, FTP en modo pasivo ), a veces con la asistencia de una puerta de enlace a nivel de aplicación (consulte § 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 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 fundamental de Internet, apoyado, por ejemplo, por el Internet Architecture Board . Los documentos actuales sobre arquitectura de Internet observan 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. [16] Existe una preocupación considerablemente mayor con el uso de NAT de IPv6, y muchos arquitectos de IPv6 creen que IPv6 fue pensado para eliminar la necesidad de NAT. [17]
Una implementación que solo rastrea puertos puede verse rápidamente agotada por aplicaciones internas que utilizan múltiples conexiones simultáneas, como una solicitud HTTP para una página web con muchos objetos integrados. Este problema se puede mitigar rastreando la dirección IP de destino además del puerto, compartiendo así un único 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 camufladas detrás de una dirección de acceso público, es imposible que los hosts externos inicien una conexión directa con un host interno en particular. Las aplicaciones como VOIP , videoconferencias y otras aplicaciones peer-to-peer deben utilizar técnicas de cruce de NAT para funcionar.
La NAT pura, que opera solo sobre 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 dentro o fuera de la traducción. Los protocolos básicos como TCP y UDP no pueden funcionar correctamente a menos que la NAT tome medidas más allá de la capa de red.
Los paquetes IP tienen una suma de comprobación en cada encabezado de paquete, que permite detectar errores solo en 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 comprobación de nivel superior y el seguimiento correcto de qué paquetes pertenecen a qué conexión.
TCP y UDP tienen una suma de comprobación que cubre todos los datos que transportan, así como el encabezado TCP o UDP, más un pseudoencabezado 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 comprobación del encabezado TCP o UDP en función de las direcciones IP traducidas, no de las originales, y colocar esa suma de comprobación en el encabezado TCP o UDP del primer paquete del conjunto fragmentado de paquetes.
Como alternativa, el host de origen puede realizar el descubrimiento de la MTU de ruta para determinar el tamaño del paquete que se puede transmitir sin fragmentación y luego configurar el bit de no fragmentación (DF) en el campo de encabezado del paquete correspondiente. 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.
La traducción de direcciones de red de destino (DNAT) es una técnica que permite cambiar de forma transparente la dirección IP de destino de un paquete enrutado y realizar la función inversa para cualquier respuesta. Cualquier enrutador situado entre dos puntos finales puede realizar esta transformación del paquete.
DNAT se utiliza habitualmente 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 utiliza en un servidor completo , que queda expuesto a la WAN, lo que lo convierte en una especie de zona desmilitarizada militar (DMZ) sin defensas.
El significado del término SNAT varía según el proveedor: [18] [19] [20]
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 .
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. Mientras que la NAT estática proporciona una asignación de direcciones IP internas a direcciones IP públicas estáticas de uno a uno, la NAT dinámica utiliza un grupo de direcciones IP públicas. [24] [25]
El hairpinning de NAT , también conocido como bucle invertido de NAT o reflexión de NAT , [26] es una característica de muchos enrutadores de consumo [27] donde una máquina en la LAN puede acceder a otra máquina en la LAN a través de la dirección IP externa de la LAN/enrutador (con reenvío de puertos configurado en el enrutador para dirigir las solicitudes a la máquina apropiada en la LAN). Esta noción se describe oficialmente en 2008, RFC 5128.
A continuación se describe un ejemplo de red:
Si un equipo envía un paquete a 203.0.113.1 desde una computadora en 192.168.1.100 , normalmente el paquete se enrutaría a la puerta de enlace predeterminada (el enrutador) [e] 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, 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. Es posible que se envíe una respuesta ICMP de destino inalcanzable . Si hubiera alguna regla DNAT presente, la traducción de direcciones sigue vigente; el enrutador sigue reescribiendo la dirección IP de origen en el paquete. La computadora local ( 192.168.1.100 ) envía el paquete como si viniera de 192.168.1.100 , pero el servidor ( 192.168.1.2 ) lo recibe como si viniera 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.
La traducción de direcciones de red no se utiliza habitualmente en IPv6 porque uno de los objetivos de diseño de IPv6 es restablecer la conectividad de red de extremo a extremo. [28] El gran espacio de direcciones de IPv6 evita la necesidad de conservar direcciones y a cada dispositivo se le puede asignar una dirección única enrutable globalmente. El uso de direcciones locales únicas en combinación con la traducción de prefijos de red puede lograr resultados similares a NAT.
El gran espacio de direcciones de IPv6 aún puede ser superado 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 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. [29] Incluso el NAT de IPv6 a IPv6 real, NAT66, puede resultar útil en ocasiones: el blog de APNIC describe un caso en el que al autor solo se le proporcionó una única dirección (/128). [30]
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 Protocolo de transferencia de archivos en modo activo, por ejemplo, utiliza conexiones separadas para el tráfico de control (comandos) y para el tráfico de datos (contenido de archivos). Al solicitar una transferencia de archivos, el host que realiza la solicitud identifica la conexión de datos correspondiente por sus direcciones de capa de red y 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 hace que la información recibida por el servidor sea inválida. 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 acompañante pueden usar múltiples puertos para establecer una conexión y transmitir flujo de voz a través del 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 STUN , el comportamiento de NAT es impredecible y las comunicaciones pueden fallar. El software o hardware de Application Layer Gateway (ALG) puede corregir estos problemas. Un módulo de software ALG que se ejecuta en un dispositivo de firewall NAT actualiza cualquier dato de carga útil que se haya vuelto inválido debido a la traducción de direcciones. Los ALG deben comprender el protocolo de capa superior que deben solucionar, por lo que cada protocolo con este problema requiere un ALG independiente. Por ejemplo, en muchos sistemas Linux, existen módulos de kernel denominados 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 travesía de NAT utilizando protocolos como STUN o Interactive Connectivity Establishment (ICE), o enfoques propietarios en un controlador de borde de sesión . La travesía de NAT es posible tanto en aplicaciones basadas en TCP como en UDP, pero la técnica basada en UDP es más simple, más ampliamente entendida y más compatible con las NAT heredadas. [ cita requerida ] En cualquier caso, el protocolo de alto nivel debe diseñarse teniendo en cuenta la travesía de NAT, y no funciona de manera confiable en NAT simétricos u otras NAT heredadas de mal comportamiento.
Otras posibilidades son el Protocolo de control de puerto (PCP), [31] el Protocolo de mapeo de puerto NAT (NAT-PMP) o el Protocolo de dispositivo de puerta de enlace de Internet , pero estos requieren que el dispositivo NAT implemente ese protocolo.
Sin embargo, la mayoría de los protocolos cliente-servidor (la principal excepción es FTP [f] ) 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 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 en los que 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 al puerto ni traducirlo. En estos casos, los dispositivos NAT vuelven a realizar operaciones NAT simples. Esto significa que todo el tráfico que regresa al NAT se asigna a un cliente, lo que hace que falle el servicio a más de un cliente detrás del NAT. Hay un par de soluciones a este problema: una es utilizar TLS , que opera en la capa 4 y no enmascara el número de puerto; otra es encapsular el IPsec dentro de UDP , siendo esta última la solución elegida por TISPAN para lograr una travesía NAT segura, o una NAT con soporte "IPsec Passthru" ; otra es utilizar un controlador de borde de sesión para ayudar a atravesar el NAT .
El establecimiento de conectividad interactiva es una técnica de cruce de NAT que no depende del soporte de ALG.
La vulnerabilidad del protocolo DNS anunciada por Dan Kaminsky el 8 de julio de 2008 [32] se ve afectada indirectamente por el mapeo 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 almacenamiento en caché utilicen puertos de origen UDP aleatorios. Si la función NAT desaleatoriza los puertos de origen UDP, el servidor DNS se vuelve vulnerable.
