Configuración práctica de Asterisk (13): Servidor de Asterisk en la “nube” en servicio real

Como continuación a las anteriores entradas en el blog, en el aula de telefonía del Centro Integrado de Formación Profesional Tartanga se ha instalado un servidor de Asterisk en la “nube” dando servicio real. Para ello ha bastado con situar al servidor en la DMZ del instituto y crear dos reglas en el NAT de entrada para dirigir la señalización SIP y el tráfico RTP hacia dicho servidor, de acuerdo al siguiente esquema:

Esquema de la instalación

El servidor de Asterisk se encuentra en la DMZ del instituto, con una dirección IP privada asignada de forma estática (192.168.1.52). En el router del instituto, en realidad un UTM modelo Fortinet 200 D, se ha programado las dos siguientes reglas en el NAT de entrada:

• Todo lo que venga a la IP pública 194.30.XX.XX y al puerto 5060 UDP trasladarlo a la IP privada 192.168.1.52 y al mismo puerto. 
• Todo lo que venga a la IP pública 194.30.XX.XX y a los puertos 12000 al 12255 UDP trasladarlo a la IP privada 192.168.1.52 y al mismo rango de puertos.

En este caso, las extensiones IP que se encuentran en la LAN del instituto siguen funcionando de la forma habitual, realizando llamadas internas entre ellas y llamadas externas a través de un enlace SIP establecido entre el servidor de Asterisk y el operador de VoIP Sarenet.  Por el contrario, las extensiones IP situadas en el exterior, ya sea como teléfonos SIP instalados como aplicaciones en teléfonos móviles (Zoiper, CSip, Linphone u otros) o teléfonos IP físicos situados en LAN privadas, necesitan acceder a un servidor STUN público para conocer la IP pública con la que salen al exterior (stun.zoiper.com, stun.counterpath.com u otros). Una lista de servidores STUN puede consultarse en el siguiente enlace: Servidores públicos de STUN

Puesto que el servidor de Asterisk si que se encuentra detrás de un NAT, es necesario configurar en el fichero sip.conf los parámetros externip y localnet, a fin de que en las llamadas entre extensiones situadas en el exterior y extensiones locales, la dirección IP de respuesta tanto para la señalización SIP como para el tráfico de voz sea la IP pública del router y no la dirección IP privada del Asterisk. No obstante en este caso, con extensiones situadas en diferentes redes, es preciso tener en cuenta que:

• Asterisk está situado en la DMZ del instituto, con dirección IP 192.168.1.52.
• Las extensiones “internas” están situadas en la LAN del instituto, las cuales reciben una dirección IP por DHCP del rango 10.22.81.XX.
• Las extensiones “externas” están situadas en redes LAN propias pero van a ser vistas por Asterisk como situadas en las respectivas IP públicas de sus router.

Por ello,  cuando se produce una llamada entre extensiones situadas en la red indicada por el parámetro localnet,  es decir, las extensiones situadas en la LAN del instituto, Asterisk no debe sustituir las direcciones IP de los campos contact y connection information por la IP pública del router, ya que ni la señalización SIP ni los paquetes RTP van a pasar en ningún momento por el router. En cambio,  cuando se produce una llamada entre una de estas extensiones y una extensión externa o entre extensiones externas, Asterisk detecta que el origen, el destino o ambos están en redes distintas a la indicada por el parámetro localnet y por lo tanto procederá a sustituir la dirección IP de los campos contact y connection information por el valor señalado por el parámetro externip. Teniendo en cuenta todo lo anterior, se configura el parámetro localnet con el valor 10.22.81.0/255.255.255.0.

Configuración en el servidor de Asterisk de los parámetros externip y localnet

El registro de un softphone instalado como app en el teléfono móvil consiste en el mismo sencillo proceso llevado a cabo habitualmente en el aula de telefonía, pero ahora se debe tener en cuenta la necesidad de activar el servidor STUN, ya que el softphone va a alcanzar al servidor de Asterisk desde una IP pública, ya sea por la propia conexión de datos del móvil o por la conexión a una red wifi distinta a la propia red wifi del aula de telefonía.

Linphone, un softphone para Android  

Linphone registrado en el servidor de Asterisk

Configuración para el registro de Linphone

Configuración del servidor de STUN en Linphone

Registro correcto de Linphone desde la IP pública donde se encuentra conectado

Una vez que se encuentran registrados estos teléfonos IP, con la configuración adecuada en el dialplan es posible permitir tan solo llamadas entre extensiones, llamadas externas a través del operador con el que se encuentra establecido un enlace IP en el servidor de Asterisk o cualquier otra función de la centralita, como los buzones de voz, desvíos de llamadas, transferencias, grabación de llamadas, grupos de llamada temporizada, música en espera, etc. 

En la configuración realizada ha funcionado todo según lo previsto, habiendo llevado a cabo el registro de varios softphones sobre teléfonos móviles tanto de alumnos de 1 STI como de profesores del instituto, estando estos teléfonos móviles únicamente con la conexión de datos de sus respectivos operadores. En todos los casos se ha logrado un establecimiento correcto de las llamadas con tráfico de voz en ambos sentidos. La configuración del servidor STUN en cada caso se ha hecho de acuerdo a los siguientes criterios:

• Las extensiones “locales” que están en la misma red que el servidor de Asterisk no deben tener activado el uso de STUN. 
• Las extensiones IP que se encuentran detrás de routers en redes LAN privadas si deben tener activado el uso de STUN, a fin de que puedan conocer la IP pública con la que salen al exterior. 
• Para las extensiones IP que disponen de una dirección IP pública es indiferente el uso de STUN, ya que funcionarán correctamente en ambos casos, con STUN activado y con STUN desactivado. Este caso se da, por ejemplo, cuando se utiliza un softphone sobre un smartphone conectado a través de la red de datos.

Es preciso tener en cuenta que en este caso todo funciona correctamente porque el tráfico de voz entre las extensiones, ya estén en el interior o en el exterior, se lleva a cabo siempre a través del Asterisk, mediante la configuración del parámetro directmedia=no en el fichero sip.conf. En una situación más compleja, con miles de extensiones IP intercambiando llamadas entre sí, no es posible que todo el tráfico RTP pase a través de un servidor de Asterisk, y es preferible utilizar un SIP Proxy para el establecimiento de la señalización (Kamailio, OpenSIPS u otros) y enviar el tráfico RTP directamente entre los usuarios. Es entonces cuando surgen nuevos problemas para que el flujo RTP se establezca de forma correcta en las llamadas, ya que frecuentemente los terminales IP de los usuarios se encuentran detrás de routers de muy variado tipo, habitualmente con las opciones SIP ALG o UPNP activadas y, opcionalmente, con NAT mas restrictivos que el modo Full Cone NAT. Para estos escenarios, existe el protocolo ICE (Interactive Connectivity Establishment), soportado por los más conocidos teléfonos IP y que con la ayuda de servidores STUN y de servidores TURN, consigue que el tráfico RTP pueda fluir con normalidad en la mayoría de los casos.

Para una mayor información sobre el protocolo ICE se recomienda la lectura de una entrada del blog de Gorka Gorrotxategi, CTO y socio fundador de Irontec, donde lo explica con todo detalle: ICE por Gorka Gorrotxategi

Notas técnicas:

1. En las imágenes y en las propias explicaciones se ha ocultado de forma deliberada parte de la dirección IP pública detrás de la cual se encuentra el servidor de Asterisk. 
2. Una vez que el servidor de Asterisk se encuentra “expuesto” a Internet, se multiplican los ataques desde el exterior mediante intentos de registro de extensiones “desconocidas” y mediante intento de llamadas a través del INVITES desde direcciones IP extrañas. Para evitar fraudes por parte de terceros se deben extremar las precauciones, configurando adecuadamente tanto el fichero sip.conf como el dialplan y utilizando en todo caso contraseñas lo suficientemente seguras, tanto para el registro de las extensiones como para el acceso al servidor de Asterisk.