REGISTER y NAT

En este artículo examinaremos la forma en que se soluciona el "problema del NAT" en las redes de telefonía VoIP.


Primero examinemos los distintos tipos de NAT para explicar luego como se trata la información de los registros de usuarios para cada caso.

  • Full Cone: en este tipo de NAT todas las solicitudes que vienen de una misma dirección IP y puerto internos se traducen en una misma dirección y puerto externos. De este modo, cualquier equipo externo puede enviar un paquete al equipo interno apuntando a la dirección externa y el puerto asignados por el equipo que hace el NAT.
  • Restricted Cone: en este caso también todas las solicitudes que vienen de una misma dirección IP y puerto internos se traducen en una misma dirección y puerto externos. Sin embargo, a diferencia del Full Cone, un equipo externo con una dirección IP X sólo puede enviar un paquete al equipo interno si este le ha enviado previamente un paquete a la dirección IP X.
  • Port Restricted Cone: este tipo de NAT es igual al Restricted Cone NAT con la diferencia que la restricción que aplica incluye números de puertos también. Es decir, un equipo externo con una dirección IP X y puerto Y sólo puede enviar un paquete al equipo interno si este le ha enviado previamente un paquete a la dirección IP X y puerto Y.
  • Symmetric: en este tipo de NAT todas las solicitudes que vienen de una misma dirección IP y puerto internos, y tiene como destino una dirección IP y puerto específicos, se traducen en una misma dirección IP y puerto externos. Si el equipo interno envía un paquete con la misma dirección IP y puerto de origen, pero a un destino diferente, el equipo encargado de hacer el NAT utiliza una traducción diferente. Además, solamente los equipos externos que reciben un paquete pueden enviar un paquete UDP de vuelta al equipo interno.

El Full Cone es el menos restrictivo de los tipos de NAT existentes y puede ser manejado sin problemas por user agents SIP que implementen STUN. Con STUN los user agents que detectan este tipo de NAT pueden modificar los encabezados Via y Contact que envían con su solicitud de registro, utilizando la dirección IP y el número de puerto que obtuvieron del servidor STUN. Dado que esta dirección IP y puerto son accesibles desde cualquier equipo externo sin necesidad de haber recibido un paquete previamente, el servidor que recibe la solicitud de registro puede enviar la respuesta a la dirección del encabezado Via y almacenar la información del encabezado Contact en el servicio de localización para enviar futuras solicitudes al usuario directamente.

Aún cuando el NAT Restricted Cone y el Port Restricted Cone no permiten que un equipo externo envíe un paquete sin haber recibido previamente uno del equipo interno, la modificación de los encabezados Via y Contact funciona en estos casos puesto que el equipo interno es quien envía la solicitud original al equipo externo. El envío de la solicitud inicial abre el NAT para que el equipo externo pueda enviar la respuesta a la dirección IP y puerto especificados en el encabezado Via y las futuras peticiones directamente a la dirección IP y puerto especificados en el encabezado Contact. Sin embargo, puesto que las traducciones de los equipos NAT expiran, deben enviarse solicitudes continuamente para mantener estas traducciones vigentes. El tiempo utilizado para expirar estas traducciones varía de un fabricante a otro, pero se recomienda el envío de paquetes cada 20 segundos para asegurar que el NAT se mantenga abierto.

El NAT Simétrico no puede ser resuelto por los user agent que soportan STUN, y en efecto, los equipos Linksys deshabilitan la función NAT Mapping una vez detectan que están detrás de un NAT simétrico. Al deshabilitar el NAT Mapping no hacen ninguna modificación a los encabezados con la dirección IP y puerto que obtuvieron del servidor STUN. Para estos casos la solución se debe implementar en el servidor que recibe la solicitud. En el caso particular de OpenSIPS, se utiliza la función nat_uac_test(flags) del módulo NATHELPER para identificar si el user agent se encuentra detrás de un NAT y realizar los ajustes necesarios. El parámetro flags de ésta función puede tomar cualquiera de los valores siguientes:

  • 1 – El encabezado Contact se revisa en búsqueda de direcciones IP privadas definidas por el RFC1918.
  • 2 – La dirección del encabezado Via es comparada con la dirección IP desde la que se recibió la solicitud.
  • 4 – El primer encabezado Via es verificado en búsqueda de direcciones IP privadas definidas por el RFC1918.
  • 8 – El SDP es verificado en búsqueda de direcciones IP privadas definidas por el RFC1918.
  • 16 – Se verifica si el puerto de origen de la solicitud es diferente al especificado en el encabezado Via.
  • 32 – La dirección IP en el encabezado Contact es comparado contra la dirección de origen de la señalización.
  • 64 – El número de puerto del encabezado Contact es comparado contra el número de puerto de origen de la señalización.

Cualquier combinación de las opciones anteriores puede lograrse sumando los valores correspondientes y utilizando el resultado como parámetro de la función nat_uac_test(). Por ejemplo, si se desean verificar el encabezado Contact (1) y el SDP (8) en búsqueda de direcciones IP privadas definidas por el RFC1918 se debe llamar la función de la manera siguiente: nat_uac_test(9).

El soporte a NAT de una red SIP está muy ligado al aprovisionamiento de los user agents que se conectan a ella. Buena parte de los equipos SIP que se pueden adquirir hoy día soportan varios métodos para hacer NAT Traversal, y estas funcionalidades deben ser explotadas al máximo para aprovechar el costo de estos dispositivos. Una red SIP para telefonía no puede ser vista como las antiguas redes PSTN. En la PSTN la inteligencia se concentra en las centrales conmutadoras mientras que los teléfonos sólo son dispositivos tontos. Esta concentración de la inteligencia en la central supone también una concentración de los costos en este punto. Sin embargo, en las redes SIP para telefonía los costos de los servidores no son tan altos como los de una central de conmutación, pero este costo ahorrado en el punto central se traslada a los equipos terminales de los clientes, los cuales tienen precios que oscilan entre los $50 y $70.

Una de las características más importantes de soporte a NAT que ofrecen muchos de los equipos SIP hoy día es el envío de mensajes Keep-Alive. La idea de los Keep-Alive es mantener las traducciones NAT vigentes mediante el envío continuo de mensajes SIP o paquetes UDP al servidor de registro. Son preferibles los paquetes SIP porque, dependiendo del equipo que esté implementando el NAT, el envío de mensajes en una sola vía, del user agent al servidor SIP, puede no ser suficiente. Éste es el caso de los paquetes UDP, los cuales no pueden ser respondidos por el servidor SIP. Sin embargo, los paquetes SIP pueden ser respondidos por el servidor SIP lo que asegura paquetes atravesando el NAT en las dos vías para mantener cualquier implementación de NAT abierta.

Autor: Dioris Moreno
Gerente General de Libereco Systems

Somos lo que necesita para su próximo proyecto