Traducción de Direcciones de Red
La traducción de direcciones de red (NAT) es un método para asignar un espacio de direcciones IP a otro mediante la modificación de 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. La técnica se usó originalmente para eludir la necesidad de asignar una nueva dirección a cada host cuando se movía una red o cuando se reemplazaba el proveedor de servicios de Internet ascendente, pero no se 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 ante el agotamiento de las direcciones IPv4. Una dirección IP enrutable de Internet de una puerta de enlace NAT se puede usar para una red privada completa.
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 detalles del comportamiento de NAT no suelen estar documentados por los proveedores de equipos que contienen implementaciones de NAT.
NAT básica
El tipo más simple de NAT proporciona una traducción uno a uno de las direcciones IP. RFC 2663 se refiere a este tipo de NAT como NAT básico; también se denomina 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 direccionamiento incompatible.
NAT de uno a muchos
.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.
Esta es una configuración típica:
- Una red local utiliza uno de los designados privado Subnetes de dirección IP (RFC 1918).
- La red tiene un router que tiene una dirección privada y pública. La dirección privada es utilizada por el router para comunicarse con otros dispositivos en la red local privada. La dirección pública (normalmente asignada por un proveedor de servicios de Internet) es utilizada por el router para comunicarse con el resto de Internet.
- A medida que el tráfico pasa de la red a Internet, el router traduce la dirección fuente en cada paquete de una dirección privada a la dirección pública del router. El router rastrea datos básicos sobre cada conexión activa (en particular la dirección de destino y el puerto). Cuando el router recibe tráfico de entrada desde Internet, utiliza los datos de seguimiento de conexiones almacenados durante la fase de salida para determinar a qué dirección privada (si hay) debe enviar la respuesta.
Todos los paquetes IP tienen una dirección IP de origen y una dirección IP de destino. Por lo general, los paquetes que pasan de la red privada a la red pública verán modificada su dirección de origen, mientras que los paquetes que pasan de la red pública a la red privada verán modificada su dirección de destino. Para evitar ambigüedades en cómo se traducen las respuestas, se requieren modificaciones adicionales a los paquetes. La gran mayoría 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 para 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üedades al destino de la red privada correspondiente. RFC 2663 utiliza el término dirección de red y traducción de puertos (NAPT) para este tipo de NAT. Otros nombres incluyen traducción de dirección 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 uso común.
Este método permite la comunicación a través del enrutador solo cuando la conversación se origina en la red privada, ya que la transmisión de origen inicial es la que establece la información requerida en las tablas de traducción. 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. Los protocolos que no se basan en TCP y UDP requieren otras técnicas de traducción.
Un beneficio adicional de NAT de uno a muchos es que mitiga el agotamiento de direcciones IPv4 al permitir que redes enteras se conecten a Internet usando una sola dirección IP pública.
Métodos de traducción
La traducción de puertos y direcciones de red se puede implementar de varias formas. Algunas aplicaciones que usan información de direcciones IP pueden necesitar determinar la dirección externa de un traductor de direcciones de red. Esta es la dirección que detectan sus compañeros de comunicación en la red externa. Además, puede ser necesario examinar y categorizar el tipo de mapeo en uso, por ejemplo, cuando se desea establecer una ruta de comunicación directa entre dos clientes, ambos detrás de puertas de enlace NAT separadas.
Para este propósito, RFC 3489 especificó un protocolo llamado Simple Traversal of UDP over NATs (STUN) en 2003. Clasificó las implementaciones de NAT como NAT de cono completo, (dirección) NAT de cono restringido, NAT de cono restringido de 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 del estado de los estándares, ya que los métodos son inadecuados para evaluar correctamente muchos dispositivos. RFC 5389 estandarizó nuevos métodos en 2008 y el acrónimo STUN ahora representa el nuevo título de la especificación: Session Traversal Utilities for NAT.
Full-cone NAT, también conocido como UN-to-one NAT
|  |
(Adiciones)-cono restringido NAT
|  |
Port-restricted cone NAT Como una dirección restringida cone NAT, pero la restricción incluye números de puerto.
|  |
NAT simétrico
|  |
Muchas implementaciones de NAT combinan estos tipos, por lo que es mejor referirse al comportamiento de NAT individual específico en lugar de usar la terminología Cone/Symmetric. RFC 4787 intenta aliviar la confusión mediante la introducción de terminología estandarizada para los comportamientos observados. Para la primera viñeta de cada fila de la tabla anterior, el RFC caracterizaría las NAT de cono completo, cono restringido y cono restringido por puerto como si tuvieran una asignación independiente del punto final, mientras que caracterizaría un NAT simétrica como si tuviera una asignación dependiente de la dirección y del puerto. Para la segunda viñeta en cada fila de la tabla anterior, RFC 4787 también etiquetaría NAT de cono completo como si tuviera un Filtrado independiente del punto final, NAT de cono restringido como si tuviera un Filtrado dependiente de la dirección , NAT de cono restringido por puerto que tiene un Filtrado dependiente de la dirección y del puerto, y NAT simétrico que tiene un Filtrado dependiente de la dirección o Dirección y filtrado dependiente del puerto. Otras clasificaciones del comportamiento de NAT mencionadas en el RFC incluyen si preservan los puertos, cuándo y cómo se actualizan las asignaciones, si los hosts internos pueden usar las asignaciones externas (es decir, su comportamiento de horquillado) y el nivel de determinismo que exhiben las NAT al aplicar todas estas normas. Específicamente, la mayoría de las NAT combinan NAT simétrica para conexiones salientes con mapeo de puertos estáticos, donde los paquetes entrantes dirigidos a la dirección y el puerto externos se redireccionan a una dirección y un puerto internos específicos.
Tipo de NAT y NAT transversal, papel de la preservación del puerto para TCP
El problema transversal 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 transversales de NAT. La técnica más popular para el paso NAT de TCP es la perforación de agujeros TCP.
La perforación de agujeros 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 del NAT. La preservación del puerto NAT para las conexiones TCP salientes es crucial para el cruce TCP NAT porque, bajo TCP, un puerto solo se puede usar para una comunicación a la vez, por lo que los programas vinculan distintos sockets TCP a puertos efímeros para cada comunicación TCP, lo que hace imposible la predicción del puerto NAT. para TCP.
Por otro lado, para UDP, los NAT no necesitan conservación de puertos. De hecho, múltiples comunicaciones UDP (cada una con un punto final distinto) pueden ocurrir en el mismo puerto de origen, y las aplicaciones generalmente reutilizan el mismo socket UDP para enviar paquetes a distintos hosts. Esto hace que la predicción de puertos sea sencilla, ya que es el mismo puerto de origen para cada paquete.
Además, la preservación de puertos en NAT para TCP permite que los protocolos P2P ofrezcan menos complejidad y menos latencia porque no es necesario utilizar un tercero (como STUN) para descubrir el puerto NAT, ya que la propia aplicación ya conoce el puerto NAT.
Sin embargo, si dos hosts internos intentan comunicarse con el mismo host externo usando el mismo número de puerto, el NAT puede intentar usar una dirección IP externa diferente para la segunda conexión o puede necesitar renunciar a la preservación del puerto y reasignar el puerto.
A partir de 2006, aproximadamente el 70 % de los clientes en redes P2P empleaban alguna forma de NAT.
Implementación
Establecer una comunicación bidireccional
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. La 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. Tanto la dirección IP como el número de puerto deben ser correctamente conocidos por todos los hosts que deseen comunicarse con éxito.
Las direcciones IP privadas, tal como se describen en RFC 1918, solo se pueden usar en redes privadas que no estén conectadas directamente a Internet. Los puertos son puntos finales de comunicación exclusivos de ese host, por lo que se mantiene una conexión a través del dispositivo NAT mediante la asignación combinada de puerto y dirección IP. Una dirección privada en el interior del NAT se asigna a una dirección pública externa. La traducción de direcciones de puerto (PAT) resuelve los conflictos que surgen cuando varios hosts utilizan el mismo número de puerto de origen para establecer diferentes conexiones externas al mismo tiempo.
Analogía de la extensión del número de teléfono
Un dispositivo NAT es similar a un sistema telefónico en una oficina que tiene un número de teléfono público y varias extensiones. Todas las llamadas telefónicas salientes realizadas desde la oficina parecen provenir del mismo número de teléfono. Sin embargo, una llamada entrante que no especifica una extensión no se puede transferir automáticamente a una persona dentro de la oficina. En este escenario, la oficina es una LAN privada, el número de teléfono principal es la dirección IP pública y las extensiones individuales son números de puerto únicos.
Proceso de traducción
Con NAT, todas las comunicaciones enviadas a hosts externos en realidad contienen 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 las direcciones IP y los puertos de sus hosts internos, ocultando el verdadero punto final de un host interno en una red privada.
Cuando una computadora en la red privada (interna) envía un paquete IP a la red externa, el dispositivo NAT reemplaza la dirección IP de origen interna en el encabezado del paquete con la dirección IP externa del dispositivo NAT. Luego, PAT puede asignar a la conexión un número de puerto de un grupo de puertos disponibles, insertando este número de puerto en el campo de puerto de origen. A continuación, el paquete se reenvía a la red externa. Luego, el dispositivo NAT realiza una entrada en una tabla de traducción que contiene la dirección IP interna, el puerto de origen original y el puerto de origen traducido. Los paquetes subsiguientes de la misma dirección IP de origen interno y número de puerto se traducen a la misma dirección IP de origen externo y número de puerto. La computadora que recibe un paquete que se ha sometido a NAT establece una conexión con el puerto y la dirección IP especificados en el paquete alterado, sin darse cuenta de que la dirección proporcionada se está traduciendo.
Al recibir un paquete de la red externa, el dispositivo NAT busca en la tabla de traducción según el puerto de destino en el encabezado del paquete. Si se encuentra una coincidencia, la dirección IP de destino y el número de puerto se reemplazan con los valores que se encuentran en la tabla y el paquete se reenvía a la red interna. De lo contrario, si el número de puerto de destino del paquete entrante no se encuentra en la tabla de traducción, el paquete se descarta o se rechaza porque el dispositivo PAT no sabe a dónde enviarlo.
Visibilidad de la operación
La operación de NAT suele ser transparente tanto para los hosts internos como para los externos. El dispositivo NAT puede funcionar como la puerta de enlace predeterminada para el host interno que, por lo general, conoce la verdadera dirección IP y el puerto TCP o UDP del host externo. Sin embargo, el host externo solo conoce la dirección IP pública del dispositivo NAT y el puerto particular que se utiliza para comunicarse en nombre de un host interno específico.
Aplicaciones
- Routing
- La traducción de direcciones de red se puede utilizar para mitigar la superposición de direcciones IP. La superposición de direcciones ocurre cuando los hosts en diferentes redes con el mismo espacio de direcciones IP intentan llegar al mismo host de destino. Esto es a menudo una desconfiguración errónea y puede resultar de la fusión de dos redes o subredes, especialmente cuando se utiliza la red privada RFC 1918. El destino host experimenta tráfico aparentemente llegando de la misma red, y los routers intermedios no tienen manera de determinar a dónde debe enviarse el tráfico de respuesta. La solución está renumerando para eliminar superposición o traducción de direcciones de red.
- Equilibrio de carga
- En aplicaciones cliente-servidor, los balanceadores de carga envían solicitudes al cliente a un conjunto de ordenadores servidor para gestionar la carga de trabajo de cada servidor. La traducción de direcciones de red se puede utilizar para mapear una dirección IP representativa del clúster del servidor a hosts específicos que atienden la solicitud.
Técnicas relacionadas
La traducción inversa de direcciones y puertos 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. La implementación de RAPT de Cisco es una sobrecarga de PAT o NAT y asigna varias direcciones IP privadas a una sola dirección IP pública. Se pueden asignar varias direcciones a una sola dirección porque cada dirección privada se rastrea mediante un número de puerto. PAT utiliza números de puerto de origen únicos en la dirección IP global interna para distinguir entre traducciones. PAT intenta conservar el puerto de origen original. Si este puerto de origen ya está en uso, PAT asigna el primer número de puerto disponible comenzando desde el principio del grupo de puertos apropiado 0–511, 512–1023 o 1024–65535. Cuando no hay más puertos disponibles y hay más de una dirección IP externa configurada, PAT pasa a la siguiente dirección IP para intentar asignar nuevamente el puerto de origen original. Este proceso continúa hasta que se agotan los puertos disponibles y las direcciones IP externas.
La asignación de direcciones y puertos 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 ISP. En efecto, es una alternativa (casi) sin estado a NAT de nivel de operador y DS-Lite que empuja la función de traducción de puerto/dirección IPv4 (y el mantenimiento del estado de NAT) por completo a 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 también se proporciona un mecanismo de transición para el despliegue de IPv6 nativo al mismo tiempo con muy poca complejidad añadida.
Problemas y limitaciones
Los hosts detrás de enrutadores habilitados para NAT no tienen conectividad de extremo a extremo y no pueden participar en algunos protocolos de Internet. Los servicios que requieren el inicio de conexiones TCP desde la red externa o que usan 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 acomodar una instancia de NAT entre hosts participantes (por ejemplo, FTP en "modo pasivo"), a veces con la ayuda de una puerta de enlace a nivel de aplicación (consulte § Aplicaciones afectadas por NAT), pero fallan cuando ambos Los 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 los valores en los encabezados que interfieren con las comprobaciones de integridad realizadas por IPsec y otros protocolos de tunelización.
La conectividad de extremo a extremo ha sido un principio fundamental de Internet, apoyado, por ejemplo, por la Junta de Arquitectura de Internet. Los documentos de arquitectura de Internet actuales observan que NAT es una violación del principio de extremo a extremo, pero que NAT tiene un papel válido en el diseño cuidadoso. Existe una preocupación considerablemente mayor con el uso de IPv6 NAT, y muchos arquitectos de IPv6 creen que IPv6 tenía la intención de eliminar la necesidad de NAT.
Las aplicaciones internas que usan varias conexiones simultáneas, como una solicitud HTTP para una página web con muchos objetos incrustados, pueden agotar rápidamente una implementación que solo realiza un seguimiento de los puertos. Este problema se puede mitigar rastreando la dirección IP de destino además del puerto, compartiendo así un solo puerto local con muchos hosts remotos. Este seguimiento adicional aumenta la complejidad de la implementación y los recursos informáticos en el dispositivo de traducción.
Debido a que todas las direcciones internas están ocultas detrás de una dirección de acceso público, es imposible que los hosts externos inicien directamente una conexión a un host interno en particular. Las aplicaciones como VOIP, videoconferencias y otras aplicaciones de igual a igual deben utilizar técnicas transversales de NAT para funcionar.
Fragmentación y sumas de control
La NAT pura, que funciona solo con IP, puede o no analizar correctamente los protocolos con cargas útiles que contienen información sobre IP, como ICMP. Esto depende de si la carga útil es interpretada por un host en el dentro 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 un NAT vuelva a ensamblar estos fragmentos para permitir el recálculo correcto de las sumas de verificación de nivel superior y el seguimiento correcto de qué paquetes pertenecen a qué conexión.
TCP y UDP, tienen una suma de verificación que cubre todos los datos que transportan, así como el encabezado TCP o UDP, más un pseudo-encabezado que contiene las direcciones IP de origen y destino del paquete llevando el encabezado TCP o UDP. Para que un NAT de origen pase TCP o UDP con éxito, debe volver a calcular la suma de verificación del encabezado TCP o UDP en función de las direcciones IP traducidas, no las originales, y colocar esa suma de verificación en el encabezado TCP o UDP del primer paquete del conjunto fragmentado. de paquetes
Alternativamente, el host de origen puede realizar el descubrimiento de MTU de la ruta para determinar el tamaño del paquete que se puede transmitir sin fragmentación y luego configurar el bit no fragmentar (DF) en el encabezado del paquete apropiado. campo. 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.
ADN
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 usa en un servidor completo, que queda expuesto a la WAN y se vuelve análogo a una zona militar desmilitarizada (DMZ) no defendida.
SNAT
El significado del término SNAT varía según el proveedor:
- fuente NAT es una expansión común y es la contraparte de destino NAT ()DNAT). Esto se utiliza para describir NAT de una sola mano; NAT para las conexiones salientes a los servicios públicos.
- NAT estatal es utilizado por Cisco Systems
- NAT estático es utilizado por WatchGuard
- seguro NAT es utilizado por F5 Networks y por Microsoft (en relación con el servidor ISA)
La traducción segura de direcciones de red (SNAT) es parte de Internet Security and Acceleration Server 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
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 dirección IP estática interna a pública uno a uno, la NAT dinámica utiliza un grupo de direcciones IP públicas.
Fijación de NAT
NAT hairpinning, también conocido como bucle invertido de NAT o reflejo de NAT, es una característica de muchos enrutadores de consumo donde una máquina en la LAN está capaz de 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:
- Dirección pública: 203.0.113.1. Esta es la dirección de la interfaz WAN en el router.
- Dirección interna del router: 192.168.1.1
- Dirección del servidor: 192.168.1.2
- Dirección de una computadora local: 192.168.1.100
Si un paquete se envía a 203.0.113.1 por un computadora en 192.168.1.100, el paquete normalmente se enrutaría al puerta de enlace predeterminada (el enrutador) Un enrutador con la función de bucle invertido NAT detecta que 203.0.113.1 es la dirección de su interfaz WAN y trata el paquete como si viniera de esa interfaz. Determina el destino de ese paquete, según las reglas DNAT (reenvío de puertos) para el destino. Si los datos se enviaron al puerto 80 y existe una regla DNAT para el puerto 80 dirigida a 192.168.1.2, luego el host en esa dirección recibe el paquete.
Si no hay ninguna regla DNAT aplicable disponible, el enrutador descarta el paquete. Se puede enviar una respuesta ICMP Destination Unreachable. Si hubiera alguna regla DNAT, la traducción de direcciones aún está vigente; el enrutador aún reescribe la dirección IP de origen en el paquete. La computadora local (192.168.1.100) envía el paquete como si viniera de 192.168.1.100, pero el servidor (192.168.1.2) lo recibe como proveniente de 203.0.113.1. Cuando el servidor responde, el proceso es idéntico al de un remitente externo. Por lo tanto, es posible la comunicación bidireccional entre hosts dentro de la red LAN a través de la dirección IP pública.
NAT en IPv6
La traducción de direcciones de red no se usa comúnmente en IPv6 porque uno de los objetivos de diseño de IPv6 es restaurar la conectividad de red de extremo a extremo. El gran espacio de direccionamiento de IPv6 evita la necesidad de conservar direcciones y cada dispositivo puede recibir una dirección enrutable global única. El uso de direcciones locales únicas en combinación con la traducción de prefijos de red puede lograr resultados similares a NAT.
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. FTP en modo activo, por ejemplo, utiliza conexiones separadas para el tráfico de control (comandos) y para el tráfico de datos (contenido del archivo). Al solicitar una transferencia de archivos, el host que realiza la solicitud identifica la conexión de datos correspondiente por 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 invalida la información recibida por el servidor. SIP comúnmente 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 usar varios puertos para establecer una conexión y transmitir un 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 Application Layer Gateway (ALG) puede corregir estos problemas. Un módulo de software ALG que se ejecuta en un dispositivo de cortafuegos NAT actualiza los datos de la carga útil que no son válidos debido a la traducción de direcciones. Los ALG deben comprender el protocolo de capa superior que deben corregir, por lo que cada protocolo con este problema requiere un ALG independiente. Por ejemplo, en muchos sistemas Linux, existen módulos de kernel llamados rastreadores de conexión que sirven para implementar ALG. Sin embargo, ALG no puede funcionar si los datos del protocolo están encriptados.
Otra posible solución a este problema es usar técnicas transversales de NAT mediante protocolos como STUN o Establecimiento de conectividad interactiva (ICE), o enfoques patentados en un controlador de borde de sesión. El NAT transversal es posible tanto en aplicaciones basadas en TCP como en UDP, pero la técnica basada en UDP es más simple, más comprensible y más compatible con las NAT heredadas. En cualquier caso, el protocolo de alto nivel debe diseñarse teniendo en cuenta el NAT transversal, y no funciona de manera confiable en NAT simétricos u otros NAT heredados que se comportan de manera deficiente.
Otras posibilidades son el protocolo de dispositivo de puerta de enlace de Internet, el protocolo de asignación de puertos NAT (NAT-PMP) o el protocolo de control de puertos (PCP), pero estos requieren que el dispositivo NAT implemente ese protocolo.
La mayoría de los protocolos cliente-servidor (siendo FTP la principal excepción), sin embargo, no envían información de contacto de capa 3 y no requieren ningún tratamiento especial por parte de los NAT. De hecho, evitar las complicaciones de NAT es prácticamente un requisito a la hora de diseñar nuevos protocolos de capa superior en la actualidad.
Los NAT también pueden causar problemas cuando se aplica el cifrado IPsec y en los casos en los que varios dispositivos, como teléfonos SIP, están ubicados detrás de un NAT. Los teléfonos que encriptan su señalización con IPsec encapsulan la información del puerto dentro de un paquete encriptado, lo que significa que los dispositivos NAT no pueden acceder ni traducir el puerto. En estos casos, los dispositivos NAT vuelven a las operaciones NAT simples. Esto significa que todo el tráfico que regresa a la NAT se asigna a un cliente, lo que hace que falle el servicio a más de un cliente detrás de la NAT. Hay un par de soluciones a este problema: una es usar TLS, que opera en la capa 4 y no enmascara el número de puerto; otra es encapsular IPsec dentro de UDP; esta última es la solución elegida por TISPAN para lograr un NAT transversal seguro, o un NAT con "IPsec Passthru" apoyo; otra es usar un controlador de borde de sesión para ayudar a atravesar el NAT.
El establecimiento de conectividad interactiva es una técnica transversal de NAT que no depende de la compatibilidad con ALG.
La vulnerabilidad del protocolo DNS anunciada por Dan Kaminsky el 8 de julio de 2008 se ve afectada indirectamente por la asignación 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 desde un servidor DNS detrás de un firewall que implementa NAT. La solución alternativa recomendada para la vulnerabilidad de DNS es hacer que todos los servidores DNS de almacenamiento en caché utilicen puertos de origen UDP aleatorios. Si la función NAT elimina la aleatoriedad de los puertos de origen UDP, el servidor DNS se vuelve vulnerable.
Ejemplos de software NAT
- Compartir conexión a Internet (ICS): Aplicación NAT & DHCP incluida con sistemas operativos Windows
- IPFilter: incluido con (Open)Solaris, FreeBSD y NetBSD, disponible para muchos otros sistemas operativos similares a Unix
- ipfirewall (ipfw): filtro de paquete nativo de FreeBSD
- Netfilter con iptables/nftables: el filtro de paquete Linux
- NPF: Filtro de paquete nativo de NetBSD
- PF: OpenBSD-native Filtro de paquete
- Servicio de Routing y Acceso Remoto: implementación de enrutamiento incluido con sistemas operativos Windows Server
- WinGate: aplicación de la ruta de terceros para Windows
Contenido relacionado
Autoedición
Arquitectura multinivel
Máscara de gas