La traducción de direcciones de red ( NAT ) es un método para asignar un espacio de direcciones IP a 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 las direcciones IPv4 . Se puede utilizar una dirección IP enrutable por Internet de una puerta de enlace NAT para toda una red privada . [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 diversos casos de direccionamiento y su efecto en el tráfico de la 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 abordar de forma única unos 4.400 millones de dispositivos. En 1992 se hizo evidente que eso no sería suficiente. El RFC 1631 de 1994 describe NAT como una "solución a corto plazo" a los dos problemas más apremiantes que enfrentaba 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 direcciones IP (RFC 1631). RFC 2663 se refiere a este tipo de NAT como NAT básica ; También se le llama NAT uno a uno . En este tipo de NAT, solo se cambian 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. 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 varios 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, a los paquetes que pasan de la red privada a la red pública se les modificará su dirección de origen, mientras que a los paquetes que pasan de la red pública a la red privada se les modificará su dirección de destino. Para evitar ambigüedades 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 modo que la combinación de dirección IP (dentro del encabezado IP ) y número de puerto (dentro del encabezado de la capa de transporte ) en el paquete devuelto se pueda asignar sin ambigüedades al destino de red privada correspondiente. RFC 2663 utiliza el término traducción de dirección y puerto de red (NAPT) para este tipo de NAT. [4] Otros nombres incluyen traducción de direcciones de puertos (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 router sólo 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. Por lo tanto, 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. [a] Los protocolos no basados en TCP y UDP requieren otras técnicas de traducción.
Un beneficio adicional de la NAT uno a muchos es que mitiga el agotamiento de las direcciones IPv4 al permitir que redes enteras se conecten a Internet mediante una única dirección IP pública. [b]
La traducción de direcciones de red y puertos se puede implementar de varias maneras. Es posible que algunas aplicaciones que utilizan información de dirección IP necesiten 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, los cuales están detrás de puertas de enlace NAT separadas.
Para este propósito, RFC 3489 especificó un protocolo llamado Simple Traversal of UDP over NAT ( 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étrica , y propuso una metodología para probar un dispositivo en consecuencia. Sin embargo, desde entonces estos procedimientos han quedado obsoletos 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: Session Traversal Utilities for NAT .
Muchas implementaciones de NAT combinan estos tipos, por lo que es mejor hacer referencia al comportamiento NAT individual específico en lugar de utilizar la terminología cono/simétrica. RFC 4787 intenta aliviar la confusión introduciendo 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, de cono restringido y de cono restringido de puerto como si tuvieran una asignación independiente del punto final , mientras que caracterizaría una NAT simétrica como si tuviera una asignación de dirección. y Mapeo dependiente del puerto . Para la segunda viñeta de cada fila de la tabla anterior, RFC 4787 también etiquetaría a NAT de cono completo como si tuviera un filtrado independiente del punto final , a NAT de cono restringido como si tuviera un filtrado dependiente de la dirección , y a NAT de cono restringido por puerto como si tuviera una dirección. y filtrado dependiente del puerto , y NAT simétrica que tiene un filtrado dependiente de la dirección o un filtrado dependiente de la dirección y el puerto . Otras clasificaciones del comportamiento NAT mencionadas en el RFC incluyen si preservan los puertos, cuándo y cómo se actualizan las asignaciones, si los hosts internos pueden utilizar las asignaciones externas (es decir, su comportamiento de horquillado ) y el nivel de determinismo que exhiben las NAT al aplicar todas estas normas. [2] Específicamente, la mayoría de las NAT combinan NAT simétrica para conexiones salientes con mapeo de puertos estático , donde los paquetes entrantes dirigidos a la dirección y el puerto externos se redirigen a una dirección y un puerto internos específicos.
RFC 4787 [2] hace una distinción entre mapeo NAT y filtrado NAT.
La sección 4.1 del RFC cubre el mapeo NAT y especifica cómo una dirección IP externa y un número de puerto deben traducirse en 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 se relacionan con la seguridad de la NAT ya que la seguridad está determinada por el comportamiento de filtrado y luego especifica "UNA NAT DEBE tener un comportamiento de "asignación independiente del punto final".
La sección 5 del RFC cubre el filtrado NAT y describe qué criterios utiliza 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. 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 un comportamiento de filtrado más estricto es más importante.
Algunos dispositivos NAT aún no cumplen con RFC 4787, ya que tratan el mapeo y el filtrado de NAT de la misma manera, por lo que su opción de configuración para cambiar el método de filtrado de NAT también cambia el método de mapeo 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 del cruce de NAT surge cuando los pares detrás de diferentes NAT intentan comunicarse. Una forma de solucionar este problema es utilizar el reenvío de puertos . Otra forma es utilizar varias técnicas de recorrido NAT. La técnica más popular para atravesar TCP NAT es la perforación de TCP .
La perforación de TCP requiere que NAT siga el diseño de preservación de puertos para TCP. Para una comunicación TCP saliente determinada, se utilizan los mismos números de puerto en ambos lados de la NAT. La preservación del puerto NAT para las conexiones TCP salientes es crucial para el cruce NAT de TCP porque, bajo TCP, solo se puede usar un puerto 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 imposible la predicción del puerto NAT. para TCP. [2]
Por otro lado, para UDP, las NAT no necesitan conservar el puerto. 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 distintos hosts. Esto simplifica la predicción del puerto, ya que es el mismo puerto de origen para cada paquete.
Además, la preservación del puerto 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 propia aplicación ya conoce el puerto NAT. [2] [5]
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 que necesite renunciar a la preservación del puerto y reasignarlo. [2] : 9
En 2006 [actualizar], aproximadamente el 70% de los clientes en redes P2P empleaban alguna forma 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 está encapsulado en un paquete IP, cuyo encabezado IP contiene una dirección IP de origen y una dirección IP de destino. El triple 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 80 se conecta a través de un socket al software del servidor web y el puerto 25 al demonio SMTP de un servidor de correo . 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. Todos los hosts que deseen comunicarse correctamente deben conocer correctamente tanto la dirección IP como el número de puerto.
Las direcciones IP privadas, como se describe en RFC 1918, solo se pueden utilizar en redes privadas que no estén conectadas directamente a Internet. Los puertos son puntos finales de comunicación únicos para ese host, por lo que una 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 en el interior de 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.
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. [7]
Con NAT, todas las comunicaciones enviadas a hosts externos en realidad contienen la dirección IP externa y la información del puerto del dispositivo NAT en lugar de direcciones IP o números de puerto del host interno. NAT solo traduce direcciones IP y 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 conjunto de puertos disponibles, insertando este número de puerto en el campo del puerto de origen. Luego, 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 posteriores 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 modificado, 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 rechaza porque el dispositivo PAT no sabe dónde enviarlo.
La operación NAT suele ser transparente tanto para los hosts internos como para los externos. El dispositivo NAT puede funcionar como puerta de enlace predeterminada para el host interno, que normalmente 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.
La traducción inversa de direcciones y puertos de IEEE (RAPT o RAT) permite que un host cuya dirección IP real cambie de vez en cuando permanezca accesible como servidor a través de una dirección IP doméstica fija. [14] La implementación RAPT de Cisco es una sobrecarga de PAT o NAT y asigna múltiples 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 es rastreada por 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 se utiliza, 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 el puerto de origen original nuevamente. Este proceso continúa hasta que se agotan los puertos disponibles y las direcciones IP externas.
El mapeo de dirección y puerto es una propuesta de Cisco que combina la traducción de dirección más puerto con la tunelización de los paquetes IPv4 a través de la red IPv6 interna de un proveedor ISP . De hecho, es una alternativa (casi) sin estado a NAT de nivel de operador y DS-Lite que integra la función de traducción de direcciones/puertos IPv4 (y el mantenimiento del estado de NAT) completamente en la implementación de NAT del equipo existente en las instalaciones del cliente . De este modo, se evitan los problemas de NAT444 y de estado de la NAT de nivel de operador y, al mismo tiempo, se proporciona un mecanismo de transición para la implementación de IPv6 nativo con muy poca complejidad añadida.
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 acomodar una instancia de NAT entre hosts participantes ( FTP "modo pasivo" , por ejemplo), a veces con la ayuda de una puerta de enlace a nivel de aplicación (ver § Aplicaciones afectadas por NAT), pero fallan cuando ambos sistemas están separados del Internet por NAT. El uso de NAT también complica los protocolos de túnel como IPsec porque NAT modifica valores en los encabezados que interfieren con las comprobaciones de integridad realizadas por IPsec y otros protocolos de túnel.
La conectividad de extremo a extremo ha sido un principio fundamental de Internet, respaldado, por ejemplo, por la Junta de Arquitectura de Internet . Los documentos actuales sobre la 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. [15] Hay mucha más preocupación con el uso de NAT IPv6, y muchos arquitectos de IPv6 creen que IPv6 estaba destinado a eliminar la necesidad de NAT. [dieciséis]
Una implementación que solo rastrea puertos puede agotarse rápidamente por 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 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 disfrazadas detrás de una dirección de acceso público, es imposible que los hosts externos inicien directamente una conexión con un host interno en particular. Aplicaciones como VOIP , videoconferencias y otras aplicaciones peer-to-peer deben utilizar técnicas transversales NAT para funcionar.
La NAT pura, que opera únicamente en IP, puede o no analizar 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 traducción. Los protocolos básicos como TCP y UDP no pueden funcionar correctamente a menos que NAT actúe 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 una 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 pseudoencabezado que contiene las direcciones IP de origen y destino del paquete que lleva el encabezado TCP o UDP. Para que una 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 de 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 el descubrimiento de MTU de ruta para determinar el tamaño del paquete que se puede transmitir sin fragmentación y luego establecer el bit de no fragmentar (DF) en el campo de encabezado de paquete apropiado. Esta es sólo una solución unidireccional, porque el host que responde puede enviar paquetes de cualquier tamaño, que pueden fragmentarse antes de llegar a la NAT.
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 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 reenvío de puertos , o DMZ cuando se utiliza en un servidor completo , que queda expuesto a la WAN, convirtiéndose en algo análogo a una zona desmilitarizada militar (DMZ) indefensa.
El significado del término SNAT varía según el proveedor: [17] [18] [19]
La traducción segura de direcciones de red (SNAT) es parte del Servidor de aceleración y seguridad 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 estáticas internas a públicas, la NAT dinámica utiliza un grupo de direcciones IP públicas. [23] [24]
La horquilla NAT , también conocida como loopback NAT o reflexión NAT , [25] es una característica de muchos enrutadores de consumo [26] 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 el 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 una red de ejemplo:
Si una computadora envía un paquete a 203.0.113.1 en 192.168.1.100 , el paquete normalmente se enrutará 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 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. Se puede enviar una respuesta ICMP Destino inalcanzable . Si existiera 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 proveniente 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 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 usa comúnmente en IPv6 porque uno de los objetivos de diseño de IPv6 es restaurar la conectividad de red de un extremo a otro. [27] El gran espacio de direcciones de IPv6 elimina 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 se puede superar dependiendo de la longitud real del prefijo proporcionada por el operador. No es raro que se le entregue un prefijo /64 (la subred más pequeña recomendada) para toda una red doméstica, lo que requiere el uso de una variedad de técnicas para subdividir manualmente el rango para que todos los dispositivos sigan siendo accesibles. [28] Incluso la 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). [29]
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 los datos de su aplicación. FTP en modo activo, por ejemplo, utiliza conexiones separadas para controlar el tráfico (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 mediante 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 del número de puerto TCP invalida la información recibida por el servidor. SIP normalmente controla las llamadas de voz sobre IP y sufre el mismo problema. SIP y el protocolo de descripción de sesión que lo acompaña pueden utilizar múltiples puertos para configurar 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 las NAT. Sin técnicas especiales, como STUN , el comportamiento de NAT es impredecible y las comunicaciones pueden fallar. El software o hardware 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 no sea válido 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 independiente. Por ejemplo, en muchos sistemas Linux, existen módulos del kernel llamados rastreadores de conexiones que sirven para implementar ALG. Sin embargo, ALG no puede funcionar si los datos del protocolo están cifrados.
Otra posible solución a este problema es utilizar técnicas transversales de NAT utilizando protocolos como STUN o Interactive Connectivity Establishment (ICE), o enfoques propietarios en un controlador de borde de sesión . El cruce 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 comprendida y más compatible con las NAT heredadas. [ cita necesaria ] En cualquier caso, el protocolo de alto nivel debe diseñarse teniendo en cuenta el cruce de NAT, y no funciona de manera confiable en NAT simétricas u otras NAT heredadas con mal comportamiento.
Otras posibilidades son el Protocolo de control de puerto (PCP), [30] 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 (siendo FTP la principal excepción [e] ) 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 a la hora de diseñar nuevos protocolos de capa superior en la actualidad.
Las NAT también pueden causar problemas cuando se aplica el cifrado IPsec y en los casos en que varios dispositivos, como teléfonos SIP, se encuentran detrás de una 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 a NAT se asigna a un cliente, lo que provoca que falle el servicio a más de un cliente detrás de NAT. Hay un par de soluciones a este problema: una es usar 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 un cruce NAT seguro, o un NAT con soporte "IPsec Passthru" ; otra es utilizar un controlador de borde de sesión para ayudar a atravesar la NAT .
El establecimiento de conectividad interactiva es una técnica transversal de NAT que no depende del soporte de ALG.
La vulnerabilidad del protocolo DNS anunciada por Dan Kaminsky el 8 de julio de 2008 [31] se ve afectada indirectamente por el mapeo de puertos NAT. Para evitar el envenenamiento de la caché de DNS , es muy recomendable no traducir los números de puerto de origen UDP de las solicitudes de DNS salientes de un servidor DNS detrás de un firewall que implemente 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 elimina la aleatorización de los puertos de origen UDP, el servidor DNS se vuelve vulnerable.
