O meu artigo non é unha descrición completa do produto, senón só un lixeiro refinamento da boa publicación "FusionPBX, ou, de novo, xenial, FreeSWITCH". Paréceme que o tema da ACL en FusionPBX non está moi ben divulgado nel. Tentarei cubrir este oco baseándome na miña propia experiencia con FreeSWITCH/FusionPBX.
E así, temos instalado un FusionPBX cun número interno rexistrado 1010 no dominio domain.local e unha ruta configurada para chamadas externas á cidade. Usamos ACL para protexer o noso sistema de telefonía de chamadas non autorizadas que nos quitarán cartos. Eses. só desde as redes descritas na ACL permiten chamadas saíntes. E aquí precisa unha comprensión completamente clara de como funciona ACL en FusionPBX, as súas características, a lóxica e o seu punto de ancoraxe.
Do mesmo xeito que o respectado autor do artigo anterior, tamén pisei todos os anciños relacionados con ACL.
Vou comezar con SipProfiles.
Ambos os perfís (chamareilles así), tanto internos como externos, están no contexto Público, e isto non é casual. O rexistro de números realízase no perfil interno, e prestarémoslle atención. No perfil interno, os dominios ACL están ligados como apply-inbound-acl. É esta liña a responsable do funcionamento da ACL a nivel de perfil. Ata agora, iso é todo cos perfís.
Contexto
O contexto utilízase, entre outras cousas, no enrutamento de chamadas. Todas as rutas de entrada están vinculadas ao contexto público.
As rutas de saída (para a cidade, para móbiles, de longa distancia, internacionais e calquera outra) están (por defecto) no contexto dun nome de dominio (chamémoslle dominio.local).
ACL
Agora imos tratar coas ACL. Por defecto, un FusionPBX recentemente instalado ten dúas ACL:
acción predeterminada de dominios: denegar: esta folla está ligada ao perfil interno
acción predeterminada lan: permitir
Na lista de dominios ACL, prescribimos a rede (ben, por exemplo, 192.168.0.0/24), facemos o permiso de permiso para esta rede, usamos reloadacl.
A continuación, rexistramos un teléfono desta rede, e todo parece estar ben e segundo as instrucións e loxicamente.
Comezamos a probar, chamamos a un número externo e... sácanos unha rosquilla, ou mellor dito, unha rosquilla. De súpeto!
Comezamos a analizar o log na consola ou a través do Log Viewer FusioPBX.
Vemos o noso reto:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Vemos a ACL que funcionou:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.E máis:
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] Sen ruta! Aínda que a ruta temos rexistrada sinceramente.
A resposta é realmente sinxela.
Chegou a chamada. ACL perdeuno. E dado que a ACL está vinculada ao perfil interno e este perfil está no contexto público, FreeSWITCH mira honestamente o enrutamento no contexto público. Pero no contexto público, só as rutas de entrada, e o sistema sinceramente dinos que alí non hai rutas para a cidade.
Hai polo menos dúas formas de saír desta situación.
- Achegue esta ACL non ao perfil, senón ao propio número interno. Esta pode ser a forma máis correcta de resolver, porque. É mellor vincular ACL o máis preto posible de Extensión para un axuste máis fino. Eses. pode prescribir un enderezo específico/enderezo de rede do teléfono desde o que pode facer unha chamada saínte. A desvantaxe desta opción é que cada Extensión terá que facelo.
- Corrixe a ACL para que funcione correctamente a nivel de perfil. Escollín esta opción, porque me pareceu máis doado engadir a rede á ACL unha vez que prescribila en cada Extensión. Pero isto é específicamente para a miña tarefa. Para outras tarefas, pode necesitar unha lóxica de toma de decisións diferente.
Entón. Imos corrixir os dominios ACL do seguinte xeito:
acción predeterminada de dominios: permitir
Na lista de dominios ACL, rexistramos a rede:
denegar 192.168.0.0/24
Aplicar, recargar.
Estamos probando: marcamos de novo o número 98343379xxxx e... chega o posto de control... OLA. Todo está funcionando.
Vexamos que pasou en FreeSWITCH:
comeza a chamada:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL non faltou:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.e ademais:
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 O enrutamento pasou, e despois vén o establecemento da conexión, que está fóra do ámbito do tema.
Se cambiamos o enderezo de rede na ACL, pero obtemos a imaxe da primeira proba, é dicir. A ACL saltará a chamada e o enrutamento dirá NO_ROUTE_DESTINATION.
Probablemente iso é todo o que quería engadir a ACL FusionPBX.
Espero que lle sexa útil a alguén.
Fonte: www.habr.com