FusionPBX y ACL

Mi artículo no es una descripción completa del producto, sino solo una pequeña aclaración de una buena publicación "FusionPBX, o de nuevo, FreeSWITCH". Creo que en ella no se aborda bien el tema de ACL en FusionPBX. Intentaré llenar este vacío en base a mi propia experiencia trabajando con FreeSWITCH/FusionPBX.

Así que tenemos FusionPBX instalado con el número interno registrado 1010 en el dominio domain.local y una ruta configurada para llamadas externas a la ciudad. Usamos ACL para proteger nuestro sistema de telefonía de llamadas no autorizadas que nos costarán dinero. Es decir, solo permitir llamadas salientes desde las redes descritas en ACL. Y aquí se necesita una comprensión muy clara de cómo funciona ACL en FusionPBX, sus características, lógica y punto de conexión.

Al igual que el respetado autor del artículo mencionado anteriormente, también pisé todos los problemas relacionados con ACL.

Empezaré con SipProfiles.
Ambos perfiles (los llamaré así), tanto internal como external, están en el contexto Public, y no es casualidad. Los números se registran en el perfil internal, así que nos centraremos en él. En el perfil internal, se vincula la lista ACL domains como apply-inbound-acl. Esta línea es la que responde por la funcionalidad de ACL a nivel de perfil. Hasta aquí todo claro con los perfiles.

Contexto

El contexto, entre otras cosas, se usa para la ruta de las llamadas. Todas las rutas entrantes están vinculadas al contexto Public.

Las rutas salientes (a la ciudad, a móviles, de larga distancia, internacionales, y cualquier otra) se encuentran (por defecto) en el contexto llamado dominio (lo llamaremos domain.local).

ACL

Ahora hablemos de ACL. Por defecto, en una FusionPBX recién instalada hay dos listas ACL:

domains acción por defecto: deny — esta lista está vinculada al perfil internal
lan acción por defecto: allow

En la lista ACL domains, escribimos la red (por ejemplo, 192.168.0.0/24), le damos permiso allow, aplicamos reloadacl.

Luego registramos un teléfono desde esta red, y parece que todo está bien y conforme a la instrucción y es lógico.
Empezamos a probar, hacemos una llamada a un número externo y… nos encontramos con un bache, o más bien un agujero de bache. ¡Inesperado!

Comenzamos a analizar el log en la consola o a través del Visor de Log de FusioPBX.

Vemos nuestra llamada:

switch_channel.c:1104 New Channel sofia/internal/1010@domain.local

Vemos el ACL activado:

sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.

Y luego:

mod_dialplan_xml.c:637 Procesando 1010 ->98343379xxxx en el contexto público
switch_core_state_machine.c:311 ¡Sin ruta, abortando!
switch_core_state_machine.c:312 Colgando sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION] 

¡No hay ruta! Aunque la ruta está correctamente configurada.

La respuesta es en realidad simple.

La llamada ha llegado. El ACL lo permitió. Y dado que el ACL está vinculado al perfil interno, y este perfil se encuentra en el contexto público, FreeSWITCH mira honestamente la ruta en el contexto público. Pero en el contexto público solo hay enrutamiento entrante, y el sistema nos dice honestamente que no hay ninguna ruta en la ciudad.

De la situación actual hay, como mínimo, dos salidas.

1. Vincular este ACL no al perfil, sino al propio número interno. Este puede ser el método más adecuado de resolución, ya que es mejor vincular el ACL lo más cerca posible de la Extensión para un ajuste más fino. Es decir, se puede especificar una dirección concreta / dirección de la red del teléfono desde el cual se puede realizar una llamada saliente. La desventaja de esta opción es que hay que hacerlo en cada Extensión.
2. Corregir el ACL para que funcione correctamente a nivel del perfil. Elegí esta opción porque me pareció más fácil agregar una sola vez la red en el ACL en lugar de configurarla en cada Extensión. Pero esto es específicamente para mi tarea. Para otras tareas, puede que se necesite otra lógica de toma de decisiones.

Y entonces. Corregiremos el ACL de los domains de la siguiente manera:

acción por defecto de domains: permitir

En la lista de ACL de domains especificamos la red:

deny 192.168.0.0/24

Aplicamos, reloadacl.
Probamos: marcamos de nuevo el número 98343379xxxx y… está sonando… ¡ALÓ! Todo funciona.
Veamos lo que ocurrió en FreeSWITCH:
comienza la llamada:

switch_channel.c:1104 New Channel sofia/internal/1010@domain.local

ACL no permitió:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Rechazado por acl "domains". Volviendo a la autenticación Digest.

y luego:

mod_dialplan_xml.c:637 Procesando 1010 ->98343379xxxx en el contexto domain.local
sofia/internal/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /9(8343[23]d{6})$/ break=on-false 

La ruta se procesó, y luego se establece la conexión, que está más allá del tema.

Si cambiamos la dirección de la red en el ACL, pero obtenemos el mismo resultado que en la primera prueba, es decir, el ACL permitirá la llamada y la ruta dirá NO_ROUTE_DESTINATION.

Eso es probablemente todo lo que quería añadir sobre el ACL de FusionPBX.

Espero que a alguien le sea útil.

Fuente: habr.com