Por qué el Verificador de Cortafuegos no Miente
3CX tiene un verificador de cortafuegos automatizado incorporado que valida la configuración de su cortafuegos en términos de "reenvío de puertos" y también "preservación de puertos".
Reenvío de Puertos
3CX verificará si el "NAT de Como Completo" está correctamente configurado en el dispositivo firewall/puerta de enlace (firewall/gateway). El NAT de Cono Completo permite a cualquier entidad externa conectarse a 3CX sin la necesidad de que el cortafuegos primero confirme que el paquete real se originó desde 3CX antes de permitir la conexión. Esto es muy importante especialmente para proveedores VoIP, ya que el servidor SIP no es el mismo servidor (dirección IP de origen) que entregará el audio final a su sistema. En algunos casos, la implementación de cortafuegos pondrá tráfico entrante "no permitido" en una lista de rechazo, lo cual prevendrá una conexión al destino, incluso si 3CX comienza a enviar datos (audio) a su destino.
Preservación de Puertos
La preservación de puertos es otro factor clave que comprueba el verificador de cortafuegos. Detecta si el cortafuegos altera al puerto durante la traducción de IP LAN a IP WAN. Técnicamente hablando, esto no debería importar, sin embargo, depende de la implementación del proveedor, si ellos responden al puerto fuente de transporte de 3CX visto en la cabecera UDP, en lugar de lo definido por el RFC. El RFC define que un servidor SIP DEBE responder a la IP y puerto de "contacto" definidos, los cuales están en el contenido del mensaje SIP. Para eliminar cualquier "quizás" el verificador de cortafuegos también valida este mapeo. Se requiere que si un mensaje SIP es generado localmente por 3CX desde el puerto origen 5060 (puerto SIP por defecto), entonces traducido a la dirección IP pública (IP WAN) el puerto, en este caso 5060 permanece sin cambios.
Para hacer esto, el verificador de cortafuegos ejecutará dos pruebas independientes con el primer servidor STUN configurado en su sistema. Por defecto está configurado como stun.3cx.com. Se recomienda enfáticamente no alterar esta configuración. En general, el verificador de cortafuegos es una forma programada de detectar su dirección IP pública, similar al uso de un sitio web como "cuál es mi IP", pero se amplía para comprobar también el puerto.
Ejemplos
Abajo se muestra una verificación de cortafuegos fallida reportada por la Consola de Administración 3CX y una captura wireshark correspondiente del flujo. En esta guía desarrollaremos los pasos que son tomados por el firewall checker y le mostraremos los resultados. La captura de wireshark está limitada a mostrar "el puerto 3378 o el puerto 3379" solamente, en el cual se basó esta prueba. Es importante para el verificador de cortafuegos que el cortafuegos de Windows esté deshabilitado. La instalación de 3CX crea excepciones para algunas aplicaciones 3CX, ¡pero no para el verificador de cortafuegos!
Prueba 1
3CX detiene los servicios para liberar el puerto local con el fin de enlazarlo al verificador de cortafuegos. Este documento solo se enfocará en el primer puerto que se prueba (5060) sin embargo el procedimiento es el mismo para todos los demás puertos.
La imagen arriba muestra los siguientes pasos:
- El servidor local 3CX con dirección IP 192.168.3.159, envía una petición clásica de “stun” a stun.3cx.com con la IP 198.50.247.220.
- Desde el puerto local 5060 UDP.
- Hacia el puerto 3478, que es el puerto del servidor “stun” por defecto.
- Declarando que el servidor STUN NO debe cambiar su IP o el Puerto para responder a esta petición.
Cada solicitud tiene un "ID de transacción" único para garantizar de forma confiable que los datos recibidos pertenecen a la solicitud inicial. En raras ocasiones, es posible que el servidor envíe varias solicitudes sin obtener nunca una respuesta, como se muestra a continuación. Esto implica que:
a) El tráfico saliente fue bloqueado por el cortafuegos o b) No se ha devuelto nada al servidor. En ambos casos, ¡compruebe la configuración de su cortafuegos!
El servidor STUN entonces responde con:
- Una Respuesta Vinculante a las peticiones
- A continuación, define que la IP pública y el puerto desde donde se envió la solicitud son iguales al puerto 5060 y la dirección IP es XX.XX.96.162.
Basado en la definición anterior - la preservación de puertos está funcionando ya que el servidor STUN puede ver al PBX en el puerto definido. Si ve cualquier otro puerto en el campo "Mapped-Address" la comprobación del cortafuegos fallará y la preservación de puertos NO está funcionando correctamente. En este caso, tendrá que ponerse en contacto con el fabricante del cortafuegos para resolver el problema.
Prueba 2
En la prueba 2, el servidor enviará una solicitud al mismo servidor STUN que antes.
Sin embargo,
- El servidor 3CX marca la petición como diferente a la anterior y establece "Cambiar IP y Cambiar Puerto" a (1). Esto significa que el servidor STUN debe enviar su respuesta a 3CX desde una dirección IP y puerto que ahora es desconocido para el cortafuegos esperando una respuesta a la solicitud.
- Está claro que el servidor envió la misma petición 3 veces sin obtener respuesta del servidor STUN. Esto indica que el NAT de cono completo no está funcionando.
Comparado con la prueba 1, donde el servidor 3CX activamente envía datos al servidor STUN y recibe una respuesta, la prueba 2 muestra que los datos regresan de una fuente con la que 3CX nunca ha contactado (es decir, el servidor de audio de un proveedor VoIP) y no fue capaz de recibir ninguna respuesta. En este caso contacte al fabricante del cortafuegos para resolver el problema.
La respuesta correcta sería recibir datos en la segunda prueba en la que la "Mapped-Address" es exactamente la misma que en la prueba 1 para IP y Puerto.
Si quiere ver de donde debería haber venido el tráfico, revise los registros de su cortafuegos para las direcciones IP de los servidores STUN 3CX. Se esperaba que la respuesta viniera de los servidores STUN 3CX pero nunca llegó al NIC de 3CX.
Prueba de SIP ALG (Desde la V15.5 SP1)
Además de la prueba NAT existente, 3CX evalúa si el cortafuegos tiene SIP ALG habilitado. SIP ALG en resumen, son funciones encontradas en algunos dispositivos cortafuegos que inspeccionan, además de la lista de acceso desde y hacia IP/Puertos, el contenido de los paquetes. En este caso SIP. Para el administrador de 3CX esto puede causar numerosos problemas y debido al hecho de que los cambios a los mensajes SIP son hechos por un salto intermedio, las trazas hechas en 3CX no mostrarán esos cambios. Sin embargo, pueden causar problemas de incompatibilidad con teléfonos IP remotos o proveedores VoIP.
Validación: 3CX generará un mensaje INVITE genérico y lo enviará hacia un servicio en línea hospedado por 3CX. Exceptuando la dirección IP pública, toda la otra información es genérica.
3CX local genera el valor de hash CRC32 del mensaje enviado y espera a cambio una respuesta del servicio en la nube de que el hash tendrá el mismo valor.
Si el valor de retorno "X-CSREQ" coincide con el valor calculado localmente, se espera que SIP ALG no haya alterado el mensaje o no esté presente. Si los valores no coinciden, la prueba muestra que un salto entre 3CX y el servicio en línea ha alterado el contenido = SIP ALG.
Sobre una base de validación, el valor hash esperado puede ser calculado dado que wireshark ha capturado el INVITE saliente al servicio de detección SIP ALG.
Haga clic derecho en la Invitación enviada desde 3CX, Copiar, Bytes, Hex Stream.
Abra: http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
Y pegue el Hex Stream copiado en el recuadro CRC Input Data.
El resultado obtenido debe coincidir con el valor devuelto.
Última Actualización
Este documento se actualizó por última vez el 25 de Enero de 2019
Central Telefónica 
