Introducción
Este documento describe la necesidad de Utilidades transversales de sesión para servidores NAT (STUN), los tipos de configuraciones de Traducción de direcciones de red (NAT) con respecto a los servidores STUN, cómo NAT causa un problema en esta configuración y la solución.
Antecedentes
El objetivo principal de los dispositivos NAT es permitir que los dispositivos con direcciones IP privadas en una red de área local (LAN) se comuniquen con los dispositivos en espacios de direcciones públicas, como Internet. Sin embargo, aunque se supone que los dispositivos NAT permiten que los hosts internos se conecten con el espacio público, cuando se trata de aplicaciones punto a punto (P2P) como VoIP, juegos, WebRTC y uso compartido de archivos en las que los usuarios finales deben actuar como cliente y servidor para mantener una comunicación bidireccional de extremo a extremo, NAT ofrece dificultades para establecer esas conexiones UDP. Las técnicas transversales NAT suelen ser necesarias para que estas aplicaciones funcionen.
Necesidad de NAT Traversal
La comunicación de voz y vídeo en tiempo real a través de Internet se ha generalizado hoy en día con varias aplicaciones de mensajería instantánea (IM) populares que admiten llamadas VoIP. Un gran obstáculo en la adopción inicial de VoIP fue el hecho de que la mayoría de los PC u otros dispositivos se sientan detrás de firewalls y utilizan direcciones IP privadas. Un firewall con NAT asigna varias direcciones privadas (dirección IP y puerto) de la red a una única dirección pública. Pero el dispositivo final no conoce su dirección pública y, por lo tanto, no puede recibir tráfico de voz de la parte remota en la dirección privada que anuncia en su comunicación VoIP.
Los procesos de corrección de direcciones autónomas (UNSAF) unilaterales son procesos mediante los cuales algunos terminales de origen intentan determinar o corregir la dirección (y el puerto) por la que otro terminal la conoce, por ejemplo, para poder utilizar datos de direcciones en el intercambio de protocolos o para anunciar una dirección pública desde la que recibe conexiones.
Por lo tanto, las conexiones P2P que se están debatiendo son procesos de la UNSAF. Una manera común en que las aplicaciones P2P establecen sesiones de peering y permanecen amigables con NAT es cuando utilizan un servidor de encuentro direccionable públicamente para fines de registro y detección de peers.
Utilidades transversales de sesión para NAT
Según RFC 5389, STUN proporciona una herramienta que se ocupa de las NAT. Proporciona un medio para que un terminal determine la dirección IP y el puerto asignados por un dispositivo NAT que corresponde a su puerto y dirección IP privada. También proporciona una manera para que un punto final mantenga activo un enlace NAT.
Tipos de Implementaciones de NAT
Se ha observado que el tratamiento NAT de UDP varía entre implementaciones. Los cuatro tratamientos observados en las implementaciones son:
Cono completo: un NAT de cono completo es uno en el que todas las solicitudes de la misma dirección IP interna y puerto se mapean a la misma dirección IP externa y puerto. Además, cualquier host externo puede enviar un paquete al host interno y envía un paquete a la dirección externa asignada.
Cono Restringido: Una NAT de cono restringido es aquella en la que todas las solicitudes de la misma dirección IP interna y puerto se asignan a la misma dirección IP externa y puerto. A diferencia de una NAT de cono completo, un host externo (con dirección IP X) puede enviar un paquete al host interno sólo si el host interno había enviado previamente un paquete a la dirección IP X.
Cono restringido de puerto: una NAT de cono restringido de puerto es como una NAT de cono restringido, pero la restricción incluye números de puerto. Específicamente, un host externo puede enviar un paquete, con la dirección IP de origen X y el puerto de origen P, al host interno sólo si el host interno había enviado previamente un paquete a la dirección IP X y al puerto P.
Simétrico: una NAT simétrica es aquella en la que todas las solicitudes de la misma dirección IP interna y del mismo puerto a una dirección IP de destino específica y a un puerto, se asignan a la misma dirección IP externa y al mismo puerto. Si el mismo host envía un paquete con la misma dirección de origen y puerto, pero a un destino diferente, se utiliza una asignación diferente. Además, sólo el host externo que recibe un paquete puede enviar un paquete UDP de vuelta al host interno.
Considere una topología en la que el origen (A, Pa) (donde A es la dirección IP y Pa es el puerto de origen) se comunica con el destino (B, Pb) y (C, PC) a través de un dispositivo NAT.
| Tipo de implementación de NAT |
Fuente pública cuando se destina a (B, Pb) |
Fuente pública cuando se destina a (C, Pc) |
¿Puede el destino (por ejemplo: (B, Pb) ) enviar tráfico a (A, Pa)? |
| Cono completo |
(X1,Px1) |
(X1,Px1) |
Yes |
| Cono Restringido |
(X1, Px1) |
(X1, Px1) |
Sólo si (A, Pa) había enviado primero el tráfico a B |
| Cono restringido de puerto |
(X1, Px1) |
(X1, Px1) |
Sólo si (A, Pa) había enviado primero el tráfico a (B, Pb) |
| Simétrico |
(X1, Px1) |
(X2,Px2) |
Sólo si (A, Pa) había enviado primero el tráfico a (B, Pb) |
Problemas con NAT transversal y NAT simétrica
Los servidores STUN responden a las solicitudes de enlace STUN enviadas por los clientes STUN y proporcionan la IP/puerto público del cliente. Ahora, esta combinación de dirección/puerto es utilizada por el cliente STUN en su señalización de comunicación peer-to-peer. Sin embargo, ahora que el endhost utiliza la misma dirección/puerto privado (supongamos que está vinculado a la IP/puerto público proporcionada en la respuesta STUN), el dispositivo NAT lo traduce a la misma IP pero a un puerto diferente si se utiliza la implementación NAT simétrica. Esto interrumpe la comunicación UDP porque la señalización había establecido la conexión basada en el puerto anterior.
La implementación NAT de los routers Cisco IOS® cuando realiza PAT es simétrica de forma predeterminada. Por lo tanto, se espera que vea problemas de conexión UDP con estos routers que realizan NAT.
Sin embargo, la implementación NAT de los routers Cisco IOS-XE cuando realizan PAT no es simétrica. Cuando envía dos flujos diferentes con la misma IP de origen y el mismo puerto pero a destinos diferentes, el origen se NATED a la misma IP global interna y al mismo puerto.
La solución al problema
A partir de esta descripción, está claro que el problema se puede resolver si realiza una asignación independiente del terminal.
Según RCFC 4787: con Endpoint-Independent Mapping (EIM), la NAT reutiliza la asignación de puertos para los paquetes subsiguientes enviados desde la misma dirección IP interna y puerto (X:x) a cualquier dirección IP y puerto externos.
Desde un cliente, cuando el endhost ejecuta los comandos nc -p 23456 10.0.0.4 40000 y nc -p 23456 10.0.0.5 5000, en dos ventanas de terminal diferentes, aquí están los resultados de las traducciones NAT si utiliza EIM:
Pro Inside global Inside local Outside local Outside global
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.4:40000 10.0.0.4:40000
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.5:50000 10.0.0.5:50000
Aquí puede ver que diferentes flujos de tráfico que tienen la misma dirección de origen y el mismo puerto se traducen a la misma dirección/puerto independientemente del puerto/dirección de destino.
En los routers Cisco IOS, puede habilitar la Asignación de puertos independiente del terminal con el comando ip nat service enable-sym-port.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-15-mt-book/iadnat-fpg-port-alloc.html
Summary
La implementación NAT de Cisco IOS es simétrica de forma predeterminada cuando se utiliza la Traducción de direcciones de puerto (PAT) y puede causar problemas cuando pasa el tráfico UDP P2P que requiere servidores como STUN para NAT traversal. Debe configurar explícitamente EIM en el dispositivo NAT para que esto funcione.
Comentarios