Configuración del router para la Central Telefónica 3CX

La configuración correcta del router es fundamental para asegurar el correcto funcionamiento de la Central Telefónica 3CX con entidades externas, como extensiones remotas, proveedores VoIP y otras centrales telefónicas conectadas a través de un puente.

NAT y PAT – ¿Por qué son necesarios?

NAT – Network Address Translation (Traducción de Direcciones de Red)

Cuando un equipo A envía un mensaje por la red a otro equipo B, esperará una respuesta al mensaje enviado. Cuando ambos equipos se encuentran en una dirección IP pública, el intercambio es simple y directo.

Si alguno de los equipos reside en una dirección IP privada, las cosas se tornan más complejas, porque el entorno de red es un entorno NAT/PAT. Si el equipo A se encuentra en un entorno NAT/PAT, al enviar el mensaje al equipo B lo construirá utilizando la única dirección IP que conoce, su dirección IP privada. La dificultad aquí es que la dirección IP privada no puede ser alcanzada desde internet.

Aunque en estos casos deberíamos poder ver las respuestas que vuelven, dado que cuando el tráfico atraviesa el dispositivo WAN-LAN, éste manipulará la “Dirección IP de origen” en el encabezado del paquete, y traducirá la dirección IP privada (192.168.0.3) en la dirección IP pública antes de enviar el mensaje. De aquí el término NAT (Network Address Translation) – que significa que el tráfico sale con la Dirección IP Pública (212.213.214.215 en este caso). El dispositivo WAN-LAN mantendrá un registro de la manipulación, y la lista de las manipulaciones realizadas normalmente se la conoce como tabla de mapeos NAT. Podemos visualizar cómo se ve una entrada en esta tabla de mapeos NAT aquí:

De modo que cuando una respuesta arriba para este mensaje, el dispositivo WAN-LAN realizará la misma manipulación pero en inversa, sobre la “Dirección IP de destino” en el encabezado del paquete. En la tabla anterior, la dirección IP de destino en el encabezado del paquete necesitaría ser cambiada de “212.213.214.215″ a “192.168.0.3″, para luego ser reenviado a la LAN, donde el equipo con dirección IP “192.168.0.3” lo procesará.

NAT (Network Address Translation) y PAT (Port Address Translation)

Muy a menudo, el dispositivo WAN-LAN está manejando muchos requerimientos en forma simultánea, desde distintos equipos en el lado de la LAN, y podría ver un requerimiento desde 2 equipos diferentes en la LAN donde el número del puerto de origen es el mismo. Sin un mecanismo para manejar esta situación, el dispositivo WAN-LAN no podría satisfacer el segundo requerimiento, porque resultaría en algo como la siguiente tabla de mapeo NAT (imposible):

…y cuando la respuesta a uno de los requerimientos llega, con la “Dirección IP de destino” en el encabezado del paquete diciendo “212.213.214.215″, tendría 2 posibles equipos de LAN a los cuales podría enviarle el paquete, sin forma de discernir cuál de ellos es el correcto.

La solución para el dispositivo WAN-LAN es realizar PAT (Port Address Translation), también algunas veces llamado sobrecarga de NAT. Esto significa no solo traducir la dirección IP privada en una dirección IP pública, sino también traducir el puerto de origen en algún otro número de puerto que no aparezca en la tabla de mapeos NAT:

Esto permite que el dispositivo WAN-LAN enrute correctamente las respuestas cuando llegan desde un equipo de red remoto. De modo que ahora todo el tráfico que arribe con el Destino 212.213.214.215  y puerto 60000 será reenviado al lado LAN a la dirección IP 192.168.0.4 y puerto 5060, y todo el tráfico arribando con el Destino 212.213.214.215  y puerto 5060 será reenviado al lado LAN a la dirección IP 192.168.0.3 y puerto 5060 .

Paquetes Keep-Alive (mantener vivo)

Debe tener en mente que cada entrada en la tabla de mapeos NAT del dispositivo WAN-LAN tiene un período de validez (TTL – Time To Live), típicamente de 20 a 60 segundos. Cada vez que un paquete atraviesa la frontera WAN-LAN desde la misma dirección IP y puerto, hacia la misma dirección IP y puerto, mientras la entrada de mapeo NAT está activa, el TTL es reiniciado y el dispositivo WAN-LAN comienza a contabilizar el tiempo desde cero otra vez.

Cuando por ejemplo un cliente SIP, como un teléfono SIP, se registra con un servidor SIP, el mapeo NAT es creado. Pero si no hay tráfico intercambiado antes que el TTL expire, entonces el mapeo será eliminado y todo tráfico originado del lado WAN hacia el teléfono SIP no logrará alcanzarlo, dado que el mapeo ya no existe.

Por lo tanto un cliente SIP puede ser configurado para enviar mensajes “Keep-Alive” al servidor SIP, en intervalos de alrededor de 15 segundos (que debería ser suficiente para cualquier implementación razonable de NAT/PAT). El cliente SIP enviará un mensaje SIP al servidor SIP que es sintácticamente correcto (obligando al servidor a enviar una respuesta), pero requiriendo algún servicio o función que el servidor SIP no tenga disponible. Esto generará una respuesta de tipo “Método no implementado” desde el servidor SIP.

Funcionalmente esto no tiene impacto, pero es suficiente para asegurar que el mapeo NAT configurado en la frontera WAN-LAN nunca expire, y por lo tanto asegurar que el servidor SIP podrá contactar al cliente SIP a través del mapeo NAT.

SIP – Por qué NAT/PAT no es suficiente

Hay varias razones fundamentales por las que simplemente NATy PAT no son suficientes para resolver problemas de atravesamiento de NAT para tráfico VoIP en general, y para señalización IP más específicamente. Un pequeño subgrupo de razones:

• El estándar de SIP requiere que sean especificados varios campos de encabezado, algunos de los cuales necesitan contener la dirección IP donde deben enviarse las respuestas. Dado que NAT y PAT operan solamente en los encabezados de los paquetes IP y no en la carga útil de UDP, el dispositivo WAN-LAN no logra resolver esto del todo.
• SIP no solo realiza tareas de establecimiento, ajuste y finalización de llamadas, sino que incorpora la fase de negociación de codecs dentro del protocolo embebido llamado SDP (Session Description Protocol). Nuevamente, el dispositivo WAN-LAN no puede resolver la traducción de este contenido adicional en el nivel de NAT o PAT.

SIP ALGs o Asistentes SIP

Algunos dispositivos WAN-LAN tienen un SIP ALG o asistente implementado, el cual intenta corregir las dificultades de atravesamiento de NAT a través de la manipulación de los contenidos de los campos del encabezado SIP.

A medida que el estándar SIP y los dispositivos SIP han evolucionado, se han ido creando mecanismos más robustos, siendo el más común el uso de líneas “via” adicionales, y también extensiones a esta funcionalidad típicamente llamadas “rport” o extensiones RFC3581.

En muchos casos, dejar el SIP ALG habilitado en un dispositivo WAN-LAN romperá la funcionalidad SIP porque interfiere negativamente con las extensiones de SIP via + rport. Usted haría bien en dejar esta funcionalidad deshabilitada en todo momento, a menos que haya una situación muy específica para manejar, y que esté muy familiarizado con los retos técnicos, dado que dejar SIP ALG habilitado no está soportado.

STUN – Breve introducción

En la definición original de STUN en la RFC3489, “STUN” fue un acrónimo para “Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs)”. Desde la publicación de la RFC3489, se encontró que los métodos descriptos no son suficientes para identificar correctamente el comportamiento de una implementación NAT. Esto resultó en la publicación de una actualización en los métodos en la RFC5389 titulada “Session Traversal Utilities for NAT”.

Con la nueva RFC, el acrónimo no fue modificado, y los problemas que STUN intenta resolver son los mismos, pero algunos de los métodos más viejos fueron deprecados, y la postura de la nueva RFC no es más intentar ser una solución completa a problemas de atravesamiento de NAT, sino un conjunto de herramientas que pueden ser utilizadas en el contexto de solucionar problemas de atravesamiento de NAT.

En un intercambio STUN, un cliente STUN (típicamente un extremo VoIP, como un teléfono o una PBX) hará una serie de requerimientos a un servidor STUN (típicamente un servicio en un equipo de red en una dirección de internet pública, dedicado únicamente a responder requerimientos STUN). Las respuestas indicarán al cliente:

• De qué dirección IP vio el servidor STUN que vino el mensaje (la cual será una dirección IP pública dado que un dispositivo WAN-LAN habrá realizado NAT/PAT sobre el tráfico saliente).
• Qué traducción de número de puerto tuvo efecto para un tipo particular de tráfico UDP.

Esta información le permite a un teléfono SIP, por ejemplo, identificar su dirección IP pública y número de puerto que será puesto en los encabezados IP y UDP LUEGO de la traducción, de modo que al construir el CONTENIDO del paquete SIP (y también el SDP embebido cuando corresponda), declarará la dirección IP y puerto TRADUCIDOS. De esta forma, el teléfono se asegura que si un extremo SIP remoto utiliza el CONTENIDO del paquete SIP para identificar la dirección y puerto de retorno, tendrá la información correcta.