Mi artículo no es una descripción completa del producto, sino sólo un ligero refinamiento de la buena publicación "FusionPBX, o nuevamente genial, FreeSWITCH". Me parece que el tema de ACL en FusionPBX no está muy bien explicado en él. Intentaré llenar este vacío basándome en mi propia experiencia con FreeSWITCH/FusionPBX.
Y así, tenemos un FusionPBX instalado con un número interno registrado 1010 en el dominio dominio.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 quitarán nuestro dinero. Aquellos. Sólo desde las redes descritas en la ACL se permiten llamadas salientes. Y aquí necesita una comprensión completamente clara de cómo funciona ACL en FusionPBX, sus características, lógica y su punto de anclaje.
Al igual que el respetado autor del artículo anterior, también pisé todos los rastrillos relacionados con ACL.
Voy a empezar con Perfiles Sip.
Ambos perfiles (los llamaré así), tanto el interno como el externo, están en el contexto Público, y esto no es casual. El registro de números se realiza en el perfil interno y le prestaremos atención. En el perfil interno, la ACL del dominio está vinculada como apply-inbound-acl. Es esta línea la responsable del funcionamiento de la ACL a nivel de perfil. Hasta ahora, eso es todo con los perfiles.
Contexto
El contexto se utiliza, entre otras cosas, en el enrutamiento de llamadas. Todas las rutas entrantes están vinculadas al contexto público.
Las rutas salientes (a la ciudad, al celular, de larga distancia, internacionales y cualquier otra) están (por defecto) en el contexto de un nombre de dominio (llamémoslo dominio.local).
ACL
Ahora tratemos con las ACL. De forma predeterminada, un FusionPBX recién instalado tiene dos ACL:
Acción predeterminada de dominios: negar: esta hoja está vinculada al perfil interno
Acción predeterminada de LAN: permitir
En la lista ACL de dominios, registramos la red (bueno, por ejemplo, 192.168.0.0/24), otorgamos permiso para esta red y usamos reloadacl.
A continuación, registramos un teléfono de esta red, y todo parece estar bien y según las instrucciones y de forma lógica.
Empezamos a probar, hacemos una llamada a un número externo y... obtenemos un donut, o más bien un período sin cobertura. ¡De repente!
Comenzamos a analizar el log en la consola o mediante el Visor de Logs de FusioPBX.
Vemos nuestro desafío:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Vemos la ACL que funcionó:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.Y más:
mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context public
switch_core_state_machine.c:311 No Route, Aborting
switch_core_state_machine.c:312 Hangup sofia/internal/[email protected] [CS_ROUTING] [NO_ROUTE_DESTINATION] ¡Ninguna ruta! Aunque la ruta la hemos registrado honestamente.
La respuesta es realmente sencilla.
La llamada ha llegado. ACL se lo perdió. Y dado que la ACL está vinculada al perfil interno y este perfil está en el contexto público, FreeSWITCH analiza honestamente el enrutamiento en el contexto público. Pero en el contexto público, solo hay rutas entrantes, y el sistema honestamente nos dice que allí no hay rutas a la ciudad.
Hay al menos dos salidas a esta situación.
- Adjunte esta ACL no al perfil, sino al número interno mismo. Esta puede ser la forma más correcta de solucionarlo, porque. Es mejor vincular ACL lo más cerca posible de Extension para un ajuste más preciso. Aquellos. puede especificar una dirección/dirección de red específica del teléfono desde la cual puede realizar una llamada saliente. La desventaja de esta opción es que cada Extensión tendrá que hacer esto.
- Repare la ACL para que funcione correctamente a nivel de perfil. Elegí esta opción porque me pareció más fácil agregar la red a la ACL una vez que prescribirla en cada extensión. Pero esto es específicamente para mi tarea. Para otras tareas, es posible que necesite una lógica de toma de decisiones diferente.
Entonces. Arreglemos los dominios ACL de la siguiente manera:
acción predeterminada de dominios: permitir
En la lista ACL de dominios, registramos la red:
negar 192.168.0.0/24
Aplicar, recargar.
Estamos probando: volvemos a marcar el número 98343379xxxx y… viene el control… HOLA. Todo está funcionando.
Veamos qué pasó en FreeSWITCH:
comienza la llamada:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL no se perdió:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.y además:
mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context domain.local
sofia/internal/[email protected] Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]d{6})$/ break=on-false El enrutamiento ha pasado y luego viene el establecimiento de la conexión, que está más allá del alcance del tema.
Si cambiamos la dirección de red en la ACL, pero obtenemos la imagen de la primera prueba, es decir La ACL omitirá la llamada y la ruta dirá NO_ROUTE_DESTINATION.
Probablemente eso es todo lo que quería agregar en ACL FusionPBX.
Espero que sea útil para alguien.
Fuente: habr.com