Configuración práctica de Asterisk (12): Servidor de Asterisk en la nube y extensiones IP en LAN privadas detrás de NAT con utilización de un servidor STUN

Hasta ahora todos los montajes con Asterisk han tenido en común que tanto el servidor de Asterisk como las extensiones IP están situados en la misma LAN. Este tipo de montajes corresponde perfectamente con la situación de aquellas empresas que tienen la PBX en sus propias instalaciones y que se conectan a la red de telefonía pública mediante el servicio ofrecido por proveedores de VoIP. Cuando estas empresas tienen además diferentes sedes o delegaciones, utilizan enlaces IP para permitir llamadas telefónicas entre ellas, tal y como se ha visto en la anterior entrada de este mismo blog. 

PBX Asterisk conectadas a través de Internet mediante enlaces IP

Otro enfoque distinto de la telefonía IP es la posibilidad de colocar el servidor de Asterisk “en la nube” y colocar  en las redes LAN de cada empresa únicamente las extensiones IP. Este nuevo enfoque aporta, entre otras, las siguientes ventajas: 

  • Un único servidor de Asterisk para todas las delegaciones de la empresa, simplificando su gestión y mantenimiento.
  • Posibilidad de conectar fácilmente extensiones IP de pequeñas delegaciones donde no estaría justificado la existencia de una centralita o incluso de extensiones IP de trabajadores que desarrollan su actividad desde su domicilio particular.
  • Posibilidad de externalizar el servicio telefónico con un operador de telefonía IP mediante el alquiler de una centralita “en la nube”, opción muy utilizada hoy en día por todo tipo de empresas.

Asterisk “en la nube”

Como ya se ha visto en la anterior entrada de este blog, cuando se establece un enlace entre Asterisk a través de Internet, los servidores de Asterisk necesitan conocer la IP pública con la que salen al exterior a través del router (parámetro externip en el fichero sip.conf), ya que el protocolo SIP coloca la dirección IP donde se deben reenviar las respuestas a los mensajes en el interior de los propios mensajes SIP.  Cuando el Asterisk está situado “en la nube” y las extensiones IP se encuentran en LAN privadas se produce el mismo problema porque cuando una extensión IP envía un mensaje SIP hacia el servidor de Asterisk en la nube, también tiene que colocar en el interior del mensaje la dirección IP pública con la que sale al exterior, a fin de que Asterisk pueda enviar la respuesta de forma correcta. Lógicamente en estos casos no es posible configurar algo parecido al parámetro externip en cada una de las extensiones IP que se conectan con el servidor de Asterisk en la nube, teniendo en cuenta además que estás direcciones IP públicas con las que salen al exterior muchas pequeñas empresas y la mayoría de los domicilios particulares son de tipo dinámico y pueden cambiar.  La solución que se emplea en estos casos es el uso de un servidor de STUN (Session Traversal Utilities for NAT) cuyo funcionamiento básico fue explicado en esta anterior entrada del blog

Situación del servidor de Asterisk y del servidor de STUN 

Las extensiones IP realizan una petición a intervalos regulares al servidor de STUN y este les envía como respuesta la dirección IP pública y puerto con la que salen al exterior a través del NAT del router, tarea que no supone ninguna dificultad al servidor de STUN, ya que éste ve en el propio paquete UDP que le envía la extensión la IP de origen (la IP pública del router) y el puerto de origen (puerto de origen asignado por el NAT).

Para estudiar el funcionamiento de un sistema de este tipo dentro del módulo de Sistemas de Telefonía Fija y Móvil que cursan los alumnos del primer curso del ciclo formativo de grado superior de “Sistemas de Telecomunicación e Informáticos”, en el aula de telefonía del Centro Integrado de Formación Profesional Tartanga hemos realizado el montaje anterior “simulando” la parte WAN, donde hemos colocado un servidor con Asterisk y otro servidor con COTURN, que es un servidor open source de STUN y TURN

Montaje realizado en el aula de telefonía del CIFP Tartanga

Montaje práctico realizado en el aula

COTURN como servidor de STUN se instala fácilmente en Ubuntu 16.4, la versión de Linux que utilizamos habitualmente en el aula para las prácticas de telefonía IP. Como se ha indicado anteriormente, COTURN funciona como server de STUN, respondiendo a las peticiones de clientes STUN pero también puede funcionar como server de TURN, haciendo de relay para el tráfico RTP entre teléfonos IP. Esta opción será vista en posteriores entradas de este blog, ya que dependiendo del tipo de NAT de los router, puede ser necesario utilizarlo para tener flujo RTP (audio) en los teléfonos. 

COTURN en modo “running “

Configuración de COTURN para el arranque automático

A diferencia de los enlaces entre sistemas Asterisk a través de routers, en este caso no es necesario establecer ningún tipo de port forwarding o virtual servers en los respectivos routers. La explicación reside en las dos siguientes características:

  • En este sistema las extensiones “salen” hacia el servidor de STUN o hacia el servidor de Asterisk y por tanto las respuestas de estos pueden atravesar sin problemas el NAT de entrada de los routers.
  • Aunque se envíe la voz  de forma directa entre extensiones IP, sin pasar por el servidor de Asterisk (parámetro directmedia=yes), ambos router tienen un NAT de tipo Full Cone. Esto implica que cualquier paquete dirigido hacia la IP pública / puerto con la que ha salido una extensión IP hacia el exterior previamente, será enviado de nuevo en entrada hacia dicha extensión, aunque dichos paquetes provengan desde una IP pública / puerto a los que no se ha enviado previamente ningún paquete.

No es necesario configurar port forwarding o virtual servers en los respectivos router

Extensión 101 registrada en el Asterisk y con el servidor de STUN configurado

Extensiones 101 y 201 registradas correctamente en el Asterisk

Peticiones y respuestas entre los clientes (extensiones IP) y el servidor STUN

Petición de un cliente (teléfono IP) hacia el servidor de STUN

Respuesta del servidor STUN a la petición del cliente

Mensaje INVITE desde la extensión 101 al servidor de Asterisk

El router hace NAT de salida cambiando la IP de origen del paquete por su IP pública

La ext 201 espera recibir el audio en la IP pública de su router y en el puerto 5062

Una vez que cada extensión ha comunicado a la otra la dirección IP pública y puerto por donde espera recibir el audio, ambas envían un paquete RTP de audio hacia Asterisk colocando como puerto de origen el puerto donde esperan recibir el audio desde la otra extensión. 

 Paquetes “misteriosos” de audio RTP enviados por las ext 101 y 201 hacia Asterisk

Contenido de los paquetes RTP enviados por las extensiones hacia Asterisk

El envío de estos “misteriosos” paquetes RTP permite que los paquetes RTP de audio que posteriormente envíe la otra extensión a esa dirección IP pública / puerto, sean enviados por el router hacia el teléfono IP que está en el lado LAN, ya que previamente ese teléfono ha salido hacia el exterior por el router con esa IP pública/puerto. Esta forma tan particular de actuar de las extensiones IP se debe a que tienen configurado el servidor de STUN y por lo tanto “saben” que se encuentran detrás de un NAT y que por lo tanto, deben de abrir un “agujero” en el NAT para permitir el paso de los paquetes RTP que les llegarán del otro extremo.

Mecanismo empleado por las extensiones IP para “abrir” un agujero a los paquetes RTP

Otros modelos de teléfonos IP pueden utilizar estrategias distintas para abrir estos “agujeros” en los respectivos NAT. Una solución muy simple es que cada una de las extensiones envía un paquete RTP hacia la otra extensión colocando cada extensión como puerto de origen el puerto donde espera recibir el audio desde la otra extensión. De esta manera, cuando la otra extensión envía paquetes RTP hacia esa IP pública/puerto, el router conoce a que IP privada/puerto interno tiene que enviar esos paquetes.

Otra estrategia para abrir un agujero en el NAT

Tráfico RTP directo entre las ext 101 y 201, sin pasar por Asterisk

El tráfico RTP entre las extensiones circula de forma directa, sin pasar a través del Asterisk. Los paquetes enviados por la ext 101 van dirigidos a la IP “pública” 192.168.1.10 y puerto 5062 y los paquetes enviados por la ext 201 van dirigidos a la IP “pública” 192.168.1.1 y puerto 5060. 

Paquete de audio enviado desde la ext 101 a la 201

Paquete de audio enviado desde la ext 101 a la 201

En este caso ha sido posible el tráfico de audio entre las extensiones porque ambos router tienen un NAT del tipo Full Cone, el cual no tiene en cuenta la dirección IP pública de origen o el puerto de origen para aceptar un paquete y enviarlo hacia el interior. Con otros tipos de NAT como los denominados Restricted Cone, Port Restricted Cone, Symmetric, o alguna variante de estos, el problema se complica y en determinados casos solo es posible el tráfico RTP entre extensiones mediante el uso de un servidor TURN que hace las funciones de servidor STUN y de relay de los paquetes de voz. 

 Full Cone NAT

Esta entrada fue publicada en Telefonía IP. Guarda el enlace permanente.

Deja un comentario

Tu dirección de correo electrónico no será publicada.