Configuración práctica de Asterisk (10ª parte): SIP Trunk entre sistemas Asterisk pasando a través de routers

En una reciente entrada de este blog dedicada en exclusiva a  la construcción de un trunk entre sistemas Asterisk se han visto entre otras cosas, lo siguiente:

• Definición en el fichero sip.conf del enlace SIP. 
• Configuración en el fichero extension.conf para la realización de llamadas salientes  y para la recepción de llamadas entrantes por el enlace SIP.
• Parámetro allowguest = yes y allowguest = no para permitir llamadas entrantes desde PBX IP “desconocidas”.
• Función del parámetro register y otros parámetros necesarios para la conexión de una PBX IP Asterisk con un operador de VoIP (en nuestro caso, con el operador Sarenet).

En el primero de los casos, cuando se establece un enlace SIP entre dos sistemas Asterisk situados en la misma red, no hay ningún problema especial, porque no hay routers intermedios donde sea necesario hacer NAT y tampoco hay firewall que cierran el paso a los paquetes de señalización SIP o a los paquetes de audio RTP. En el segundo de los casos, cuando se establece un enlace SIP entre nuestro sistema Asterisk y un operador de VoIP, comienzan a aparecer los problemas que tiene la voz IP cuando hay que atravesar routers y firewall, pero gracias a la función register y a la existencia de un SBC (sesion border controller) en el lado del operador, los problemas se pueden resolver sin mucha dificultad:

• Con la función register nuestro Asterisk establece una comunicación a intervalos regulares con el operador de VoIP, lo cual le permite al operador conocer en todo momento la dirección IP pública donde estamos situados en cada momento. Con esta información, cada vez que el operador de VoIP recibe una llamada desde la red de telefonía pública con destino hacia nuestro Asterisk, ya sabe a que dirección IP pública debe enviar el correspondiente mensaje INVITE.
• Al mismo tiempo, los mensajes de register enviados por nuestro Asterisk hacia el operador de VoIP mantienen abierto un agujero en el NAT de nuestro router, lo cual permite a cualquier paquete enviado desde el operador hacia nuestro Asterisk atravesar el NAT y ser dirigido hacia nuestro Asterisk, sin que haya sido necesario configurar ningún tipo de NAT de entrada en el router. 
• Los SBC que utilizan los operadores de VoIP envían hacia nuestro Asterisk tanto los paquetes de señalización como los paquetes de voz, por lo que independientemente del tipo de NAT que tengamos (Full Cone, Restricted Cone, Port Restricted Cone,  Symmetric o alguna variante de estos) , los paquetes de voz entrantes desde el operador de VoIP llegarán sin problemas hasta nuestro Asterisk si tenemos la precaución de abrir los correspondientes puertos UDP en el firewall (5060 para la señalización y puertos UDP utilizados por el operador para los paquetes RTP).

Pero cuando se desea establecer un enlace SIP entre dos sistemas Asterisk a través de una red pública como es Internet, surgen nuevos problemas, ya que ahora hay que atravesar routers y firewall y además, no hay mensajes de register que establezcan agujeros en los respectivos NAT y tampoco hay un SBC en el otro lado que facilite las cosas para el paso de los paquetes RTP de voz. Para analizar este problema, en el aula de telefonía del Instituto de Formación Profesional Tartanga  hemos llevado a cabo un montaje que reproduce con fidelidad esta situación:

Esquema del montaje realizado

Los router que hemos utilizado corresponden al modelo Archer C5 de TP-Link. En ambos router se han configurado las direcciones IP del lado LAN y del lado WAN indicadas en la figura anterior y, además, se ha llevado a cabo la siguiente configuración:

• Para los dos servidores de Asterisk la dirección de gateway o puerta de enlace corresponde a la dirección LAN del router, es decir, la 10.22.81.2
• Para el router A se ha fijado la dirección de gateway a la 192.168.1.10 y para el router B la dirección de gateway es la 192.168.1.1. De esta forma nos aseguramos de que cualquier paquete que llegue a los router desde el lado WAN se enviará inevitablemente hacia el otro router (Nota: más adelante se llevará a cabo una configuración de estas direcciones de gateway que simula aun mejor el funcionamiento del lado WAN al estilo de como lo hace la red Internet).

Una vez configuradas las direcciones de gateway se pasa a configurar el NAT en cada uno de los router. Para ello, se accede a la opción denominada Forwarding > Virtual Servers.

Configuración del NAT en el router Archer C5 de TP-Link

Para el caso del router A es necesario redirigir el tráfico SIP entrante al puerto 5060 hacia el server de Asterisk.

Configuración del NAT para los paquetes de señalización SIP

Y para el router A también es necesario redirigir el tráfico RTP entrante con origen en el Asterisk B. Para ello en ambos Asterisk se ha configurado el fichero rtp.conf para utilizar únicamente los puertos del 10000 al 10010, por lo que solo es necesario abrir estos puertos hacia el servidor de Asterisk correspondiente. 

Configuración del NAT para el tráfico RTP (paquetes de voz)

En el router B hay que llevar a cabo una configuración similar del NAT, solo que en este caso la dirección IP local donde se debe redirigir la señalización SIP (puerto 5060) y el tráfico RTP (puertos del 10000 al 10010) debe ser la del servidor de Asterisk B, es decir, la 10.22.81.6.

En este sistema de pruebas, la configuración del enlace SIP en ambos ficheros sip.conf es la mostrada a continuación:

Configuración de los enlaces SIP en los ficheros sip.conf

Y en los respectivos dialplan (fichero extensions.conf) se ha realizado una configuración básica para permitir llamadas internas, salientes y entrantes. En la definición de las extensiones de ambos Asterisk dentro del fichero sip.conf se ha utilizado context=erandio.

Configuración de un dialplan básico en ambos Asterisk

Con esta configuración llega el momento de realizar la primera llamada de pruebas, desde la extensión 102 del Asterisk A hacia la extensión 201 del Asterisk B y, como era de esperar, comienzan los problemas: la extensión 201 suena pero al descolgar el teléfono no se establece la llamada ni hay voz. Examinando el tráfico con el analizador de protocolos Wireshark, observamos lo siguiente:

• La extensión 102 envía correctamente el mensaje de INVITE a su servidor de Asterisk, el Asterisk A.
• El Asterisk A envía correctamente el mensaje de INVITE por el enlace SIP hacia la IP pública del router B, la 192.168.1.10
• El router B efectúa correctamente la función de NAT y envía el mensaje de INVITE hacia el Asterisk B.
• El Asterisk B responde al mensaje INVITE del Asterisk A utilizando la dirección IP del campo Via. Si el mensaje atraviesa algún Proxy SIP, este añade su propia dirección IP en la parte superior de este campo Via y esta información es utilizada para que la respuesta vuelva exactamente por el mismo camino, atravesando dichos Proxy SIP. Por otro lado, el campo Contact contiene la dirección directa para acceder al Asterisk A, que será utilizada cuando el Asterisk B tenga que enviar mensajes tipo Request (peticiones) hacia el Asterisk A.  
• La fase de señalización se establece correctamente, pero el problema viene cuando ambos Asterisk envían los paquetes de voz RTP hacia el otro extremo, ya que para eso utilizan el contenido del protocolo SDP (Session Description Protocol) y ahí cada Asterisk ha colocado su dirección IP privada. Por lo tanto, no circulan paquetes de voz entre los Asterisk y la llamada se finaliza automáticamente.

Mensaje INVITE desde el Asterisk A hacia el Asterisk B

Es necesario por tanto que el Asterisk A coloque dentro del paquete INVITE que envía hacia el Asterisk B, en el campo Via, la dirección pública de su router, que es la 192.168.1.1. Esto se consigue añadiendo en la sección [general ] del fichero sip.conf la siguiente línea:

[general]                                                                                                                                          externip=192.168.1.1

Esta línea le permite al servidor de Asterisk conocer cual es la IP pública con la que “sale” hacia el lado WAN y además coloca está dirección en el campo “Via” de los paquetes SIP que envía hacia el lado WAN, para que posteriormente el Asterisk B conozca la dirección IP donde debe enviar las respuestas. Lógicamente en el fichero sip.conf del Asterisk B hay que escribir una línea similar pero ahora con la dirección IP pública del router B, es decir, la 192.168.1.10

Aunque parece que todo es correcto, cuando se prueba de nuevo con una llamada desde el Asterisk A hacia el Asterisk B, la señalización sigue sin funcionar. Al examinar otra vez con Wireshark el paquete INVITE que envía el Asterisk A hacia el Asterisk B, se comprueba que, aparentemente, el parámetro externip=192.168.1.1 no está cumpliendo su función, ya que las direcciones IP que aparecen en el interior del paquete SIP siguen siendo direcciones IP del lado LAN. 

Examinando con cuidado las diferentes opciones de configuración del fichero sip.conf se encuentra que para que funcione correctamente el parámetro externip es necesario configurar también el parámetro localnet=dir IP/máscara de subred. Este parámetro le indica a Asterisk las direcciones IP locales a las que afectará la sustitución por la IP pública del router gracias al parámetro externip. La configuración de la sección general del fichero sip.conf para el Asterisk A queda entonces de la siguiente forma:

[general]                                                                                                                                          externip=192.168.1.1                                                                                                                    localnet=10.22.81.0/255.255.255.0

Y ahora si, cuando repetimos la llamada entre la extensión 102 del Asterisk A y la extensión 201 del Asterisk B todo funciona correctamente, la extensión 201 suena y al descolgar se establece la llamada. Al examinar con Wireshark el mensaje INVITE que recibe el Asterisk B desde el Asterisk A se comprueba que el parámetro externip está cumpliendo con su función ya que la dirección IP de respuesta en el interior del paquete SIP que aparece en el campo Contact es la dirección IP pública del router A. Además, en el protocolo SDP aparece también esta dirección IP pública como la dirección donde se debe enviar el tráfico RTP desde el otro extremo del enlace. 

 

Nuevo mensaje INVITE desde el Asterisk A hacia el Asterisk B

Pero los problemas no han terminado ………. al descolgar los teléfonos no hay voz en ninguno de ellos. Examinando otra vez el tráfico UDP hacia cada Asterisk mediante el analizador de protocolos Wireshark comprobamos que los paquetes RTP si que están saliendo desde cada Asterisk hacia el otro Asterisk,  pero éstos no lo derivan hacia el teléfono IP correspondiente. El problema en este caso es claro, no está configurado en los ficheros sip.conf el parámetro directmedia=no, y por ello Asterisk se encarga de la señalización pero no gestiona el tráfico de paquetes RTP entre los extremos de la comunicación. Añadiendo la  mencionada línea directmedia=no en la sección [general] de ambos ficheros sip.conf el problema queda resuelto y el tráfico de voz funciona con normalidad. 

[general]                                                                                                                                          externip=192.168.1.1                                                                                                                    localnet=10.22.81.1/255.255.255.0                                                                                         directmedia=no

Y con esto, después de hacer el correspondiente sip reload, el funcionamiento es totalmente correcto.  Las llamadas entre Asterisk se llevan a cabo sin problemas tanto en lo referente a la señalización como en lo referente a la voz. 

Asterisk B

Asterisk A

Los dos Asterisk conectados a través de routers en el aula de telefonía del CIFP Tartanga

Conexiones del lado LAN y del lado WAN en el router B

Conexiones del lado LAN y del lado WAN en el router A

Detalle de la sección [general] en el  fichero sip.conf del Asterisk A

LLamada entrante en el Asterisk 

ATENCIÓN: LOS ROUTERS DE TIPO “RESIDENCIAL” COMO LOS USADOS EN ESTE EJEMPLO, SUELEN SER DE TIPO “FULL CONE NAT” Y DEBIDO A ESTE MODO DE FUNCIONAMIENTO, AUN SIN CONFIGURAR EL PORT FORWARDING, EN DETERMINADAS CONDICIONES ES POSIBLE ESTABLECER UNA LLAMADA DE VOZ. 

Funcionamiento en modo Full Cone NAT – (Irontec)

En el modo Full Cone Nat, cualquier paquete que se dirija hacia la IP pública del router y hacia un puerto desde el que haya habido previamente una salida, atraviesa el router y llega hasta el equipo que hizo la petición original. En el ejemplo de la figura, obtenido de la documentación técnica de Irontec, la máquina interna se dirige a Google saliendo con su IP pública y con el puerto origen 4702. Las respuestas desde Google vuelven hacia la IP pública del router y hacia el puerto 4702. Si a continuación un ordenador situado en Irontec envía un paquete hacia la IP pública del router y al puerto 4702, el modo Full Cone Nat entiende que se trata de una respuesta a la petición enviada por la máquina interna y redirige ese paquete hacia dicha máquina interna.

En la señalización SIP el modo Full Cone Nat de los routers da lugar al siguiente funcionamiento:

Con routers de tipo “residencial” no es necesario configurar “virtual server”

Si el Asterisk A intenta iniciar la llamada hacia el Asterisk B, su mensaje INVITE atravesará sin problemas el router A pero será detenido por el router B, ya que por ese router no ha salido ningún paquete hacia el router A. La llamada será, por tanto, finalizada. Si ahora el Asterisk B intenta hacer una llamada hacia el Asterisk A, su mensaje INVITE atravesará sin problemas el router B y también atravesará el router A al aplicarse la regla de “Full Cone NAT“, ya que se dirige a la IP pública del router y puerto 5060, donde previamente ha salido un paquete hacia el exterior.  De la misma manera, ahora las respuestas del Asterisk A al INVITE enviado por el Asterisk B atravesarán sin problemas el router B. Es de señalar que en este tipo de router cuando sale un paquete desde el lado LAN al lado WAN, el router siempre realiza NAT con la dirección IP, colocando como dirección de origen del paquete su propia dirección “IP pública”, pero no hace translación de puertos. Es decir, el paquete viene desde el Asterisk A con origen en el puerto 5060 UDP y se dirige al Asterisk B con destino en el puerto 5060 UDP, tanto antes de pasar por el router A como después. El router A solo hará traslación de puertos en el caso de que un tercer servidor de Asterisk situado en el lado izquierdo intente enviar un paquete hacia el Asterisk B situado en el lado derecho. 

Respecto del tráfico de voz sucede algo similar: una vez que la señalización se ha establecido, ambos Asterisk envían un primer paquete RTP hacia la dirección IP pública del router situado en el otro extremo, cuyo puerto de origen es donde esperan recibir el audio desde la otra parte. Cuando el Asterisk situado en el otro extremo envía un segundo paquete de voz a la IP pública del router y puerto donde está escuchando el Asterisk de destino, esos paquetes atraviesan sin problemas el router, pues se dirigen a una IP pública y puerto desde donde ya ha habido previamente una salida. Nuevamente el funcionamiento del router en modo “Full Cone NAT” posibilita este hecho. 

Tráfico RTP de voz a través de los router sin reglas de “virtual servers”

El funcionamiento en modo Full Cone Nat es el que permite que un Asterisk conectado “al exterior” reciba continuos ataques de equipos que intentan hacer llamadas fraudulentas. Los mensajes de INVITE que envían estos equipos “piratas” llegan hasta nuestro Asterisk, porque se dirigen a la IP pública del router y al puerto 5060, que es el utilizado por la señalización SIP. Afortunadamente, al no existir un enlace SIP con estos equipos, los mensajes INVITE se envían al contexto default, donde es extremadamente importante que su configuración no permita llamadas al exterior con los números de extensión recibidos.

Ataques de mensajes INVITE debido a la característica de Full Cone Nat

Es importante tener en cuenta que aunque las reglas de Virtual Server no son estrictamente necesarias para que funcione la señalización y el tráfico de voz si los routers tienen la característica de Full Cone Nat, si que es totalmente aconsejable colocar la regla de virtual server o port forwarding para la señalización, ya que en caso contrario, si siempre intentan establecer la llamada teléfonos del mismo Asterisk, nunca podrán conseguirlo. Si la regla de virtual server para la señalización está colocada, cualquiera de los teléfonos de ambos Asterisk podrán iniciar la llamada sin ninguna dificultad.

Otro detalle técnico importante a tener en cuenta es que Asterisk solo modifica las direcciones internas de los mensajes SIP mediante el parámetro externip cuando se dirigen a una red distinta a la del propio Asterisk. Es decir, en el ejemplo anterior cuando hacemos una llamada “interna” entre extensiones de una misma centralita, los parámetros externip y localnet serán ignorados por Asterisk, ya que tanto el Asterisk como las extensiones se encuentran en la misma red.  Se puede observar sin dificultad que no tiene ningún sentido que Asterisk coloque en llamadas de este tipo la dirección IP pública del router como dirección de respuesta para la señalización o para recibir los paquetes de voz, ya que la llamada en ningún momento “sale” por el router. 

Ámbito de actuación de los parámetros externip y localnet

Esta configuración forma parte de los contenidos impartidos en el módulo de Sistemas de Telefonía Fija y Móvil a los alumnos del ciclo formativo de grado superior de Sistemas de Telecomunicación e Informáticos. La conexión de dos Asterisk a través de una red pública como es Internet se lleva a cabo de forma similar, y solo nos deberemos enfrentar a las dificultades relativas a la configuración del NAT en los router situados en ambos extremos. Puesto que estos router habitualmente tienen una IP pública de tipo dinámico en el lado WAN, será necesario consultar esta dirección IP previa a la puesta en marcha del enlace SIP en los respectivos ficheros sip.conf, cosa que no será necesaria si los router situados en ambos extremos disponen de una IP pública estática en el lado WAN.

Nota:  Se agradece a Jesús Ortíz de Barrón, profesor de electrónica del CIFP Tartanga, la colaboración prestada para el desarrollo de esta actividad.