NAT traversal

De Wikipedia, la enciclopedia libre
(Redirigido desde «NAT transversal»)
Saltar a: navegación, búsqueda

La principal razón del nacimiento de NAT (Network Address Translation - Traducción de Dirección de Red) es la solución a corto plazo de la falta de espacio de direcciones IPv4, permitiendo que múltiples hosts compartan una dirección pública de Internet, es decir, el servicio NAT se encarga de traducir la dirección IP privada, que solo tiene validez dentro de la red privada, en una dirección IP publica que si tiene validez en Internet (fuera de la red privada).

Por lo tanto, cada vez que un host de la red privada manda un paquete al exterior NAT se encarga de cambiar la dirección IP interna del host a una dirección IP de origen pública y el número de puerto TCP o UDP a un valor asignado por NAT. Para los paquetes entrantes, el NAT cambia la dirección IP de destino pública a la dirección IP original pública y el número de puerto de destino TCP o UDP a su valor original. Por otra parte NAT permite sin ningún problema que un host externo envíe paquetes IP si previamente ha habido una conexión hacia ese host, ya que NAT se encarga de asociar la dirección IP/puerto privada con la dirección IP/puerto público.

Pero no solo para solventar el problema de la falta de direccionamiento IPv4, también es preferible instalar NAT en los dispositivos, ya que provee cierta seguridad a los host de la red interna contra las amenazas de Internet, porque impide iniciar cualquier comunicación desde Internet (el exterior) hacia el lado de la red privada puesto que el NAT elimina todo el tráfico entrante que no coincida con una de las entradas de la tabla de traducción.

El problema de NAT traversal[editar]

Mientras NAT funcionaria bien en una comunicación típica entre cliente servidor (tales como web y correo), puesto que siempre es el cliente quien inicia la conversación y normalmente el cliente no necesita mantener la conexión durante mucho tiempo,[1] NAT rompe el principio de diseño “extremo a extremo” (‘end-to-end principle’), este principio recomienda que los protocolos de comunicación operen en los puntos finales de la red y funcionen como elemento intermedio. Además de esto, la técnica NAT causa problemas con todos los protocolos que transportan direcciones IP en algún campo del mensaje. Estos protocolos funcionan pero no lo hacen correctamente porque no tienen en cuenta que las direcciones IP que albergan en su campo pueden ser direcciones IP imposibles de acceder por encontrarse detrás de NAT y por lo tanto pertenecería al espacio de direcciones IP privadas de una red. Otros problemas que se presentan:

  • NAT no está estandarizado.
  • Diferentes implementaciones.
  • Comportamiento no determinístico. Hay implementaciones de NAT que cambian el comportamiento según las circunstancias, por tanto si NAT cambia su método de mapeo o de filtrado sin cambios de configuración se llama no determinista.
  • Problemas en las aplicaciones para detectar el tipo de NAT que tienen detrás.

Metodos y técnicas de aplicaciones p2p atravesar NAT[editar]

Hay varios métodos propuestos para resolver el problema de NAT y conseguir establecer conexiones peer-to-peer entre host situados a través de NAT Gateway directa o indirectamente.

  • Relaying Esta técnica se basa en que dos peers se puedan comunicar directamente utilizando un servidor público. El reenvio de la información usando relaying funciona solo cuando los hosts pueden establecer conexión con el servidor público.

Esta es una de las técnicas más cómodas para establecer sesiones p2p a través de NAT es el más fácil de implementar pero es el camino menos eficiente para hacer NAT Traversal. La desventaja que presenta relaying es que consume potencia de procesamiento en el servidor y ancho de banda de la red y por lo general aumenta la latencia en la comunicación.

  • Connection reversal Esta técnica se utiliza cuando uno de los peer se encuentra detrás de NAT y el otro se encuentra en la red pública. Cuando el peer que se encuentra en la red pública quiere comunicarse directamente con el peer que se encuentra en el entorno de NAT es necesario que el peer de la red privada se conecte al host de la red pública a través de un servidor, que debe guardar la dirección IP publica, realizando así una conexión al revés(connection reversal). Pero tiene la limitación de que uno de los clientes debe tener la dirección IP pública.

Otras Soluciones[editar]

Otras tecnicas disponibles:

  • Old STUN: El original STUN STUN(Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) definido en RFC 3489. Con la experiencia se ha demostrado que no funciona lo suficientemente bien por lo que se desarrolló más adelante otra solución.
  • STUN/STUNbis : es la evolución del Old Stun. STUN es un protocolo tipo cliente/servidor que proporciona a un cliente, que se encuentra detrás de NAT, obtener una dirección de transporte (una dirección IP publica y un puerto UDP) para poder recibir paquetes de un peer. Sin embargo, hay que destacar que quizás las direcciones obtenidas mediante STUN no sean utilizables por todos los peers. Las direcciones funcionan o no dependiendo de la topología de la red, por lo que STUN por sí sólo no ofrece una solución completa para atravesar NAT. Esta técnica requiere actualizar la aplicación cliente y un servidor STUN adicional que resida en Internet.
  • TURN (Traversal Using Relays around NAT): es la última evolución del protocolo STUNbis. TURN es un protocolo que le permite a un dispositivo que está detrás de NAT poder recibir datos sobre conexiones UDP o TCP. Este protocolo se usa cuando el tipo de NAT que está presente es NAT simétrico o cuando el protocolo de transporte para la señalización por ejemplo en SIP no es UDP sino TCP o TLS.

TURN funciona estableciendo los flujos de media contra un servidor central que funciona como relay de media y solo permite que un cliente interno use el mismo servidor TURN, adicionalmente el equipo interno que va ejecutar el cliente de TURN no puede correr ningún servicio en puertos bien conocidos. Sólo funciona para un único usuario privado en la misma red detrás del NAT.

  • ALG (Application Level Gateway) : es un componente que se les añade a los equipos que realizan NAT o a los firewall para que inspeccionen el tráfico IP a nivel de la capa de aplicación y tomen medidas sobre dicho tráfico.

Esta técnica se usa para que aplicaciones como intercambio de archivos o aplicaciones p2p (como Bittorrent) aplicaciones multimedia o aplicaciones para conexiones VPN como clientes IPSec puedan trabajar de forma apropiada en entornos detrás de NAT.

  • UPnP (Universal Plug and Play) es un conjunto de especificaciones de protocolo para controlar dispositivos de red y por tanto a un dispositivo NAT. Con este protocolo un cliente puede dar instrucciones al dispositivo NAT para que abra un puerto en la parte pública de NAT y usar ese puerto para su comunicación.

UPnP le permite a los dispositivos y aplicaciones de software la configuración de sus opciones de red automáticamente con un router, evitándole al usuario la molestia de la configuración manual y asegurar una configuración adecuada en el NAT. En contraposición, UPnP tiene un problema fundamental en la falta de seguridad que supone el permitir a un periférico de red modificar los mapeos de puertos y direcciones IP, eliminando en cierta manera la seguridad ante ataques externos que aporta un NAT configurado correctamente. Un software malicioso puede utilizar esta característica para abrir la red privada a un ataque desde el exterior. Por ello, este tipo se soluciones se emplean únicamente en entornos residenciales pero nunca en las comunicaciones de empresa,donde se exige mayor nivel de seguridad.

  • ICE (Interactive Connectivity Establishment):Este protocolo realiza una serie de pruebas en los dos extremos que intervienen en la comunicación y determina el tipo de NAT existente y la solución más adecuada en cada caso para saltar la barrera del NAT, decidiendo si tiene que utilizar STUN, TURN u otra opción. Además ICE funciona en entornos de NAT simétrico y en ciertas circunstancias no necesita un dispositivo externo para transmiti(como un servidor o también llamado media relay).La limitación de ICE es que su estandarización es muy reciente y de momento su implementación esta poco extendida entre los fabricantes de Router.
  • TEREDO Este método ha sido propuesto por Microsoft y está basado en la tecnología tunneling. Teredo define una manera de encapsular paquetes IPv6 en datagramas UDP IPv4 que pueden ser dirigidos a través de dispositivos NAT y en internet IPv4. Aunque tampoco funciona bien con NATs Simétricos.
  • UDP/TCP hole punching Esta técnica permite establecer sesiones UDP/TCP entre dos peers que se encuentran detrás de NAT .Ambos peers establecen conexión con un servidor publico sin restricciones, este asume que previamente los peers hayan tenido una conexión UDP/TCP con el mismo. Cuando el peer conecta con el servidor, este graba la dirección que usa el peer para comunicarse con el servidor y la direccion que observa el servidor desde la red.

La técnica hole punching TCP requiere un único puerto TCP local para escuchar a una conexión TCP entrante y para iniciar conexiones TCP salientes al mismo tiempo. A continuación se muestra un ejemplo de los porcentajes de funcionamiento de las técnicas UDP y TCP Hole Punching, según un estudio elaborado por Bryan Ford [2]

UDP Hole punching 82% de los NAT TCP Hole punching 64% de los NAT
Linksys 98.00% Linksys 87.00%
Windows 94.00% Linux 94.00%
Linux 81.00% Netgear 64.00%
Netgear 84.00% Windows 52.00%

También cabe destacar PJNATH (PJSIP NAT Helper) es una biblioteca de código abierto que contiene la implementación de soluciones de NAT Traversal basado en el estándar. PJNATH puede ser usado como una biblioteca independiente en el software o puede utilizar la biblioteca PJSUA-LIB, una biblioteca con un alto nivel de integración de PJSIP, PJMEDIA y PJNATH.

NAT traversal e IPsec[editar]

IPSec proporciona confidencialidad además de autenticación e integridad. El problema está cuando el dispositivo NAT hace la correspondiente traducción de direcciones, la dirección origen del host insertada en el paquete de IP no sería la misma dirección origen del paquete IKE puesto que ha sido reemplazada por la dirección asignada por NAT. Esto significa la pérdida de autenticidad por lo que el paquete del peer de la red pública será rechazado. Teniendo en cuenta que cuando el dispositivo NAT altera el paquete, la integridad y autenticación se ven comprometidos. Aunque en algunos casos dependiendo del nivel de cifrado en el dispositivo NAT no podrá cambiar las cabeceras cifradas a sus propias direcciones. Está claro que NAT e IPSec son incompatibles una con otra, para resolver esto se creó NAT Traversal. NAT Traversal añade una cabecera UDP en la cual encapsula la cabecera de IPSec ESP. De esta manera no será cifrada y será tratada como un paquete UDP normal. Durante la primera fase, si uno o ambos peer identifican que están utilizando NAT Traversal, cambian las negociaciones IKE para usar el puerto UDP 4500. Después de esto se enviará y procesará el tráfico usando IPSec sobre UDP, lo cual no rechazara NAT. El peer receptor primero deshace el paquete IPSec y despues procesa la información como un paquete IPSec normal. Hay que tener en cuenta que para que funcione correctamente hay cuatro puertos que deber permanecer abiertos, estos son:

*El puerto UDP 4500(usado por NAT TRAVERSAL)
*El puerto UDP 500(usado por IKE, Internet Key Exchange)
*El puerto del protocolo IP 50(ESP Encapsulating Security Payload) 
*El puerto del protocolo IP 51 (AH, cabecera de autenticación)

Debido a un controvertido y raro fallo de seguridad,[3] el comportamiento por defecto de Windows XP SP2 es el de no soportar NAT-T. Esto previene a la mayoría de los usuarios domésticos de usar IPsec sin tener que hacer ajustes a la configuración de su sistema operativo. Para permitir el tráfico NAT-T para que dos sistemas se puedan comunicar estando detrás de NATs, se ha de añadir la siguiente clave al registro de windows con un valor de 2: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec\AssumeUDPEncapsulationContextOnSendRule[1]

Parches para IPsec NAT-T también están disponibles para Windows 2000, Windows NT y Windows 98.

NAT traversal y SIP[editar]

El protocolo SIP (Session Initiation Protocol) es un protocolo de señalización es la comunicación entre dispositivos multimedia. Esta comunicación se lleva a cabo mediante dos protocolos que son RTP/RTPCP y SDP. RTP/RTCP se encarga de transportar los datos multimedia (audio o video)en tiempo real e intenta llevar a cabo la comunicación de extremo a extremo (‘end-to-end principle’) .El protocolo SDP se encarga de transportar información asociada a las características de las sesiones y parámetros de capacidades de negociación entre los que desean comunicarse. SIP presenta dos problemas importantes:

  1. Problema de señalización SIP: No es posible que dos teléfonos IP se envíen paquetes de voz entre sí través de la red pública utilizando las IP privadas de dichos teléfonos. Los paquetes RTP deben de ir dirigidos hacia las IP públicas del lado de la red pública de los respectivos routers.
  2. Problema de trafico RTP: Aunque se modifique la dirección IP privada por la correspondiente IP pública, cuando un paquete RTP se dirija correctamente hacia la IP pública, no pasará a través de NAT y no llegará al teléfono SIP de destino si no existe en el NAT una asociación IP privada-puerto/IP pública-puerto. Es decir, si previamente no ha habido una conexión saliente a través de dicho NAT.

Para solucionar los problemas referentes a la señalización SIP se emplean dos mecanismos: Symmetric Response RFC 3581 y Connection reuse RFC 5923. Basados en la emisión y recepción de mensajes a través de un mismo puerto, introduciendo añadiendo campos en la cabecera SIP. Y con respecto a la problemática del flujo RTP, las soluciones principales presentadas por IETF son: Symmetric RTP, STUN ,TURN, ICE , SIP-ALG( SIP Application Layer Gateway )

Otra solución es emplear el protocolo IAX en vez de SIP y asi existen problemas de NAT.IAX es un protocolo que trata conexiones VoIP entre servidores Asterisk y y entre servidores y clientes que también utilizan protocolo IAX, que es nativo de Asterisk. Diferencias entre SIP y IAX. -En SIP la señalizacion y los datos se transportan independientemente, por lo que se producen problemas de atravesar NAT al querer enviar flujo de audio. -En IAX la señalizacion y los datos viajan juntos por lo que se consiguen evitar los problemas de NAT.

NAT e IPv6[editar]

Con IPv6, se generarán 2128 direcciones IPs, por lo que el agotamiento de éstas ya no será un problema. Si tenemos una cantidad “ilimitada” de direcciones IPs, no es necesario que los hosts dentro de una misma red privada compartan IP, por lo que NAT se vuelve innecesario.

El hecho de que hasta el 2011 no se tomó la decisión sobre NAT para IPv6 actualmente hay pocas implementaciones disponibles. Aun así está integrado tanto en OpenBSD y FreeBSD como en sistemas operativos basados en el kernel de Unix con la aplicación pf packet filter. Podemos destacar: NFNAT66[4] , MAP66[5] , RAWNAT ,Netfilter[6] ,Juniper Junos OS[7] . Cisco, hoy en dia solo soporta NAT-PT(mecanismo de traducción de IPv6 a IPv4)[8] .Esto permite comunicación entre dispositivos IPv6 a IPv4 o viceversa, pero no ofrece ninguna solución a una comunicación entre dispositivos que sean únicamente IPv6.

Anexo[editar]

Referencias IETF[editar]

  • RFC 2663 - IP Network Address Translator (NAT) Terminology and Considerations
  • RFC 2709 - Security Model with Tunnel-mode IPsec for NAT Domains
  • RFC 2993 - Architectural Implications of NAT
  • RFC 3022 - Traditional IP Network Address Translator (Traditional NAT)
  • RFC 3027 - Protocol Complications with the IP Network Address Translator (NAT)
  • RFC 3235 - Network Address Translator (NAT)-Friendly Application Design Guidelines
  • RFC 3715 - IPsec-Network Address Translation (NAT) Compatibility
  • RFC 3947 - Negotiation of NAT-Traversal in the IKE
  • RFC 5128 - State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
  • RFC 3489 - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
  • RFC 5766 - Traversal Using Relays around NAT (TURN)
  • RFC 5245 - Interactive Connectivity Establishment (ICE)

Referencias[editar]

  1. Clay Shirky (Noviembre 2000). «What is P2P and What isn’t? OpenP2P».
  2. Ford, Bryan; P.Srisuresh D. Kegel (Abril). 
  3. «IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators». Microsoft knowledge base #885348.
  4. «NFNAT66».
  5. «MAP66».
  6. «Netfilter».
  7. Juniper Junos OS. «IPv6 NAT in Junos OS».
  8. Cisco. «IPv6 Implementation Guide, Cisco IOS Release 15.2S».