Meu artigo não é uma descrição completa do produto, mas apenas um ligeiro refinamento da boa publicação "FusionPBX, ou, novamente, ótimo, FreeSWITCH". Parece-me que o tema ACL no FusionPBX não está muito bem divulgado nele. Tentarei preencher essa lacuna com base em minha própria experiência com FreeSWITCH/FusionPBX.
E assim, temos um FusionPBX instalado com número interno registrado 1010 no domínio domain.local e rota configurada para chamadas externas para a cidade. Usamos ACL para proteger nosso sistema de telefonia contra chamadas não autorizadas que tirarão nosso dinheiro. Aqueles. somente das redes descritas na ACL permitem chamadas de saída. E aqui você precisa de uma compreensão completamente clara de como o ACL funciona no FusionPBX, seus recursos, lógica e seu ponto de ancoragem.
Assim como o respeitado autor do artigo acima, também pisei em todos os rakes relacionados ao ACL.
Eu vou começar com SipProfiles.
Ambos os perfis (vou chamá-los assim), tanto internos quanto externos, estão no contexto Público, e isso não é acidental. O cadastro dos números ocorre no perfil interno, e estaremos atentos a isso. No perfil interno, a ACL dos domínios está vinculada como apply-inbound-acl. É esta linha a responsável pelo funcionamento da ACL no nível do perfil. Até agora, é isso com os perfis.
Contexto
O contexto é usado, entre outras coisas, no roteamento de chamadas. Todas as rotas de entrada estão vinculadas ao contexto Público.
As rotas de saída (para a cidade, para celular, de longa distância, internacional e qualquer outra) estão (por padrão) no contexto de um nome de domínio (vamos chamá-lo de domínio.local).
ACL
Agora vamos lidar com ACLs. Por padrão, um FusionPBX recém-instalado possui duas ACLs:
ação padrão dos domínios: negar - esta planilha está vinculada ao perfil interno
ação padrão da lan: permitir
Na lista ACL de domínios, prescrevemos a rede (bem, por exemplo, 192.168.0.0/24), fazemos a permissão de permissão para esta rede, usamos reloadacl.
A seguir, cadastramos um telefone desta rede, e tudo parece estar bem e de acordo com as instruções e de forma lógica.
Começamos o teste, fazemos uma ligação para um número externo e... pegamos um donut, ou melhor, um buraco de donut. De repente!
Começamos a analisar o log no console ou através do Log Viewer FusioPBX.
Vemos nosso desafio:
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 mais:
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] Sem rota! Embora a rota tenhamos registrado honestamente.
A resposta é muito simples.
A chamada chegou. ACL perdeu. E como a ACL está vinculada ao perfil interno, e esse perfil está no contexto público, o FreeSWITCH analisa honestamente o roteamento no contexto público. Mas no contexto público, apenas rotas de entrada, e o sistema nos diz honestamente que lá não há rotas para a cidade.
Existem pelo menos duas maneiras de sair desta situação.
- Anexe esta ACL não ao perfil, mas ao próprio número interno. Essa pode ser a forma mais correta de resolver, pois. É melhor vincular a ACL o mais próximo possível da extensão para um ajuste mais preciso. Aqueles. você pode prescrever um endereço/endereço de rede específico do telefone a partir do qual ele pode fazer uma chamada. A desvantagem desta opção é que cada Extensão terá que fazer isso.
- Corrija a ACL para que funcione corretamente no nível do perfil. Escolhi esta opção porque me pareceu mais fácil adicionar a rede à ACL uma vez do que prescrevê-la em cada Ramal. Mas isso é especificamente para minha tarefa. Para outras tarefas, você pode precisar de uma lógica de tomada de decisão diferente.
Então. Vamos corrigir os domínios ACL da seguinte forma:
ação padrão de domínios: permitir
Na lista ACL de domínios, registramos a rede:
negar 192.168.0.0/24
Aplicar, recarregar.
Estamos testando: discamos novamente o número 98343379xxxx e... o posto de controle está chegando... OLÁ. Tudo está funcionando.
Vamos ver o que aconteceu no FreeSWITCH:
a chamada começa:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL não faltou:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.e ainda mais:
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 roteamento já passou e depois vem o estabelecimento da conexão, o que foge ao escopo do tópico.
Se alterarmos o endereço de rede na ACL, mas obtivermos a imagem do primeiro teste, ou seja, A ACL irá ignorar a chamada e o roteamento dirá NO_ROUTE_DESTINATION.
Provavelmente isso é tudo que eu queria adicionar ao ACL FusionPBX.
Espero que seja útil para alguém.
Fonte: habr.com