Al analizar los problemas que surgen en las llamadas IP cuando existen routers con NAT por el medio, surge de inmediato la duda de por qué el protocolo SIP introduce direcciones IP en el contenido o payload de los mensajes de señalización. La introducción de estas direcciones IP en el contenido del mensaje SIP no tiene ningún efecto negativo cuando el servidor de Asterisk y los teléfonos IP están en la misma red, pero es una fuente de problemas cuando los mensajes SIP atraviesan routers con NAT, ya que el NAT se encarga de modificar direcciones IP y puertos en la cabecera del paquete IP, pero ni examina ni altera en ningún caso el contenido de los mensajes.
SIP es un protocolo que se encarga únicamente de la señalización, no del transporte de la voz. Observando el esquema clásico de una llamada SIP a través de un Proxy Server, es fácil darse cuenta que los teléfonos IP se envían los mensajes de señalización SIP a través del Proxy Server, mientras que los paquetes de voz RTP van de forma directa entre ellos, sin pasar por el Proxy Server.
Esquema simplificado de una llamada SIP
Lógicamente para que los teléfonos se puedan enviar los paquetes de voz entre sí es necesario que cada uno de ellos conozca la dirección IP del otro. Esta información solo puede transmitirse en la fase de señalización y, como existe un Proxy Server por medio, las direcciones IP de cada teléfono se deben introducir necesariamente en el contenido de los mensajes de señalización, ya que en las cabeceras de los paquetes IP solo aparecen las direcciones IP de origen y destino de cada paquete, y no hay espacio para ninguna otra información añadida. En el siguiente esquema se muestra de nuevo la señalización SIP anterior pero ahora incluyendo las direcciones IP de cada uno de los teléfonos y también la dirección IP del Proxy Server, que en el caso que nos ocupa es un servidor de Asterisk, aunque realmente Asterisk es mas que un Proxy Server.
Esquema simplificado de una llamada SIP con direcciones IP
Se observa en el diagrama anterior que el mensaje INVITE que llega al teléfono B tiene como dirección IP de origen la del Proxy Server, la 192.168.1.160, y como dirección de destino la del propio teléfono B, la 192.168.1.42, no apareciendo en dicha cabecera IP la dirección IP del teléfono A, la 192.168.1.38, ya que no hay espacio para ello. Lógicamente, para que el teléfono B conozca la dirección IP del teléfono A, esta dirección debe de ir en el contenido del propio mensaje INVITE. De la misma manera, cuando B responde a A, debe de informar de su propia dirección IP también en el contenido de ese mensaje de respuesta.
Captura de la señalización SIP correspondiente a la llamada anterior
En la captura de la señalización SIP correspondiente a la llamada descrita en los diagramas anteriores se observa que, además de los mensajes INVITE entre el teléfono A y el Proxy Server y entre este y el teléfono B (mensajes 1 y 2), también aparecen unos mensajes INVITE que salen directamente del Proxy Server hacia el teléfono B (5) y posteriormente hacia el teléfono A (6). Es en estos dos mensajes donde el Proxy Server, que conoce la dirección IP donde está cada teléfono, informa a cada uno de ellos de la dirección IP del teléfono opuesto.
Mensaje INVITE desde el Proxy Server al teléfono B (5)
Mensaje INVITE desde el Proxy Server al teléfono A (6)
Como se ha indicado anteriormente, el que SIP coloque direcciones IP en el contenido de los mensajes de señalización no tiene ninguna importancia hasta que estos mensajes atraviesan un router con NAT. En esos casos es necesario sustituir las direcciones IP privadas del interior de los mensajes por las correspondientes IP públicas de los respectivos interfaces WAN, a fin de que cada extremo de la llamada conozca la verdadera dirección IP donde debe enviar las respuestas a los mensajes y el audio. Si se conocen esas direcciones IP públicas es cuando se utilizan los parámetros externip y localnet en el fichero sip.conf, pero cuando no se conocen es necesario utilizar un servidor STUN. Otro problema que surge cuando hay routers con NAT es que, dependiendo del tipo de NAT, puede ser necesario utilizar un servidor de tipo TURN o Relay para que pueda entrar a través del router el flujo de audio.
En las prácticas de telefonía IP que llevamos a cabo en el CIFP Tartanga dentro del módulo de Sistemas de Telefonía Fija y Móvil, otra duda que surge frecuentemente cuando utilizamos routers para el establecimiento de enlaces o trunk SIP es porqué la mayoría de ellos utilizan NAT de tipo Full Cone y no otras formas más avanzadas como Address-restricted Cone NAT, Port-restricted Cone NAT o NAT de tipo simétrico.
NAT de tipo Full Cone (Irontec)
Con un NAT de tipo Full Cone se pueden crear “reglas de entrada” de tipo estático que permitan la visibilidad en Internet de dispositivos situados en la zona LAN, como por ejemplo un servidor de Asterisk, una conexión a escritorio remoto o cualquier otro servicio que se esté ejecutando en una máquina local. En nuestro instituto, el CIFP Tartanga, existen una serie de servicios en máquinas locales que pueden ser accedidas desde el exterior (servicio de correo electrónico con la plataforma Zimbra, disco duro en la nube con NextCloud, una Intranet para profesores y alumnos con WordPress, una plataforma de aprendizaje con Moodle, etc). A todos estos servicios se puede acceder sin tener en cuenta la dirección IP de origen o puerto, y eso solo es posible con un NAT de tipo Full Cone y las consiguientes reglas estáticas de entrada.
A un NAT de tipo Full Cone se le suele denominar también como Static NAT, por contraposición a los otros tipos de NAT que son de tipo dinámico. En estos es el router el encargado de mantener una tabla “dinámica” con las direcciones IP y puertos a los que se ha enviado paquetes para, en cada caso, permitir o bloquear entradas desde el lado WAN hacia el lado LAN.
Finalmente, es necesario tener en cuenta que un NAT de tipo Full Cone permite también que seamos “atacados” desde el exterior por cualquiera que conozca la dirección IP y puerto donde, al existir una regla estática de entrada, el router está “escuchando”. Un ejemplo claro son los continuos ataques que recibe el servidor de Asterisk que tenemos en servicio de forma continuada en el aula de telefonía del instituto, el cual es visible desde el exterior en una dirección IP pública que está mapeada a la dirección IP privada donde se encuentra el servidor y en el puerto 5060 UDP, que es el puerto utilizado por defecto con el protocolo SIP. En estos casos, un cortafuegos es la herramienta que complementa la acción del NAT de tipo Full Cone para hacerlo seguro y permitir conexiones entrantes únicamente desde determinados rangos de direcciones IP. En el servidor de Asterisk del aula de telefonía utilizamos el cortafuegos de Linux iptables a través de la utilidad UFW, aunque con esta herramienta es complicado bloquear ataques que vienen de direcciones IP que cambian continuamente, por lo que también utilizamos Fail2ban, una aplicación que inserta de forma automática reglas en iptables cada vez que detecta un comportamiento anómalo en los intentos de conexión desde el exterior.