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. Evidentemente esto no será posible si alguno de los softphones se encuentra detrás de un NAT más restrictivo que los simples NAT de tipo full cone, habituales en router instalados en domicilios particulares, debiéndose recurrir en esos casos a un servidor TURN que haga de “relay” para el tráfico de voz. Es en esas circunstancias donde el protocolo ICE juega un papel fundamental determinando si la extensión llamada se encuentra en una red alcanzable directamente por la extensión que llama o si se encuentra detrás de algún tipo de NAT. En función del resultado obtenido por ICE, el teléfono IP colocará como dirección IP donde espera recibir las respuestas a la señalización SIP y el tráfico de audio una de las tres siguientes direcciones:

  • Si detecta que la extensión llamada es alcanzable directamente ya que no hay ningún NAT intermedio, colocará su dirección IP local como dirección donde espera recibir las respuestas a la señalización SIP y al tráfico RTP de audio.
  • Si detecta que la extensión llamada no es alcanzable directamente porque ella misma se encuentra tras un NAT de tipo full cone, colocará la IP pública con la que sale al exterior y que le será facilitada por un servidor de STUN.
  • Si detecta que la extensión llamada no es alcanzable directamente porque ella misma se encuentra detrás de un NAT más restrictivo que los NAT de tipo full cone, colocará la IP pública del servidor TURN y así de esta forma consigue recibir el audio desde una dirección IP a la que ya se ha dirigido previamente.

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. 
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.