🥇FusionPBX e ACL

Meu artigo não é uma descrição completa do produto, mas apenas um pequeno esclarecimento sobre uma boa publicação "FusionPBX, ou novamente, FreeSWITCH". Acredito que o tema ACL no FusionPBX não foi muito bem abordado. Tentarei preencher essa lacuna com base na minha própria experiência com FreeSWITCH/FusionPBX.

Então, temos o FusionPBX instalado com o número interno registrado 1010 no domínio domain.local e uma rota configurada para chamadas externas para a cidade. Usamos ACL para proteger nosso sistema telefônico de chamadas não autorizadas que podem custar dinheiro. Ou seja, permitir chamadas de saída apenas das redes descritas no ACL. Aqui é necessário um entendimento claro de como o ACL funciona no FusionPBX, suas características, lógica e ponto de ligação.

Assim como o respeitado autor do artigo mencionado, eu também cometi todos os erros relacionados ao ACL.

Começarei com SipProfiles.
Ambos os perfis (eu os chamarei assim), tanto o internal quanto o external, estão no contexto Public, e isso não é por acaso. O registro dos números acontece no perfil internal, que é onde devemos nos concentrar. No perfil internal, a lista ACL é vinculada como apply-inbound-acl. Essa linha é responsável pelo funcionamento do ACL no nível do perfil. Por enquanto, tudo certo com os perfis.

Contexto

O contexto, além de tudo, é usado na roteamento de chamadas. Todas as rotas de entrada estão vinculadas ao contexto Public.

As rotas de saída (para a cidade, para celulares, interurbanas, internacionais e outras) estão (por padrão) no contexto nome de domínio (vamos chamá-lo de domain.local).

ACL

Agora vamos entender o ACL. Por padrão, no recém-instalado FusionPBX, existem duas listas ACL:

domains ação padrão: deny — esta lista está vinculada ao perfil internal
lan ação padrão: allow

Na lista ACL domains, inserimos a rede (por exemplo, 192.168.0.0/24), damos permissão allow a essa rede e aplicamos reloadacl.

Em seguida, registramos o telefone dessa rede e, aparentemente, tudo está bem e de acordo com as instruções.
Começamos a testar, fazemos uma chamada para um número externo e… recebemos um erro, ou melhor, um vazio. Surpreendente!

Começamos a analisar o log no console ou através do Log Viewer FusioPBX.

Vemos nossa chamada:

switch_channel.c:1104 Novo Canal sofia/internal/1010@domain.local

Vemos o ACL que foi ativado:

sofia.c:10208 IP 192.168.0.150 Aprovado pelo acl "domains[]". Acesso Permitido.

E então:

mod_dialplan_xml.c:637 Processando 1010 ->98343379xxxx no contexto público
switch_core_state_machine.c:311 Sem Rota, Abortando 
switch_core_state_machine.c:312 Desconectar sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Sem rota! Embora a rota esteja corretamente definida.

A resposta é na verdade simples.

A chamada chegou. O ACL a permitiu. E como o ACL está vinculado ao perfil interno, e esse perfil está no contexto público, o FreeSWITCH honestamente verifica a roteamento no contexto público. Mas no contexto público, só há roteamento de entrada, e o sistema nos diz honestamente que não há rotas na cidade.

Há pelo menos duas saídas para a situação atual.

Vincular esse ACL não ao perfil, mas ao próprio número interno. Este pode ser o modo mais correto de resolver, pois o ACL é melhor vinculado o mais próximo possível da Extensão para uma configuração mais detalhada. Ou seja, pode-se especificar um endereço/espaço de rede do telefone de onde ele poderá fazer uma chamada de saída. A desvantagem dessa opção é que será necessário fazer isso em cada Extensão.
Ajustar o ACL para que funcione corretamente no nível do perfil. Escolhi essa opção, pois parecia mais simples adicionar uma vez a rede no ACL do que especificá-la em cada Extensão. Mas isso é específico para a minha tarefa. Para outras tarefas, talvez outra lógica de decisão seja necessária.

Então, vamos ajustar o ACL domains da seguinte forma:

ações padrão do domains: permitir

No ACL-lista domains, especificamos a rede:

negar 192.168.0.0/24

Aplicamos, reloadacl.
Testamos: ligamos novamente para o número 98343379xxxx e… o CPV… ALÔ. Tudo funcionando.
Verificamos o que aconteceu no FreeSWITCH:
iniciando a chamada:

switch_channel.c:1104 Novo Canal sofia/internal/1010@domain.local

ACL não permitiu:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejeitado pelo acl "domains". Voltando à autenticação Digest.

e então:

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

A roteação passou, e então estabelece-se a conexão, que vai além do tema.

Se mudarmos o endereço da rede no ACL, mas obtivermos a mesma imagem do primeiro teste, ou seja, o ACL permitirá a chamada e a roteação dirá NO_ROUTE_DESTINATION.

Provavelmente é isso que eu queria acrescentar sobre o ACL FusionPBX.

Espero que ajude alguém.

Fonte: habr.com