🥇FusionPBX et ACL

Mon article n'est pas une description complète du produit, mais plutôt une petite précision sur une bonne publication « FusionPBX, ou rebonjour, FreeSWITCH ». Je pense que le sujet des ACL dans FusionPBX n'est pas très bien couvert. Je vais essayer de combler cette lacune, en me basant sur mon expérience avec FreeSWITCH/FusionPBX.

Donc, nous avons installé FusionPBX avec un numéro interne enregistré 1010 dans le domaine domain.local et une route configurée pour les appels externes en ville. Nous utilisons les ACL pour protéger notre système de téléphonie contre les appels non autorisés qui pourraient nous coûter cher. Autrement dit, seuls les appels sortants sont autorisés depuis les réseaux décrits dans l'ACL. Il est donc nécessaire de bien comprendre comment fonctionnent les ACL dans FusionPBX, leurs particularités, leur logique et leur point d'attache.

Tout comme l'auteur respecté de l'article mentionné ci-dessus, j'ai également rencontré tous les pièges liés aux ACL.

Je commencerai par SipProfiles.
Les deux profils (je vais les appeler ainsi), à savoir internal et external, se trouvent dans le contexte Public, et ce n'est pas un hasard. L'enregistrement des numéros se fait dans le profil internal, c'est celui-là que nous allons examiner. Dans le profil internal, la liste ACL domains est liée comme apply-inbound-acl. Cette ligne est responsable du fonctionnement des ACL au niveau du profil. Pour l'instant, tout est clair avec les profils.

Contexte

Le contexte, en plus de tout cela, est utilisé dans le routage des appels. Tous les itinéraires entrants sont liés au contexte Public.

Les itinéraires sortants (vers la ville, vers les mobiles, les interurbains, l'international, et tout autre) se trouvent (par défaut) dans le contexte du nom de domaine (appelons-le domain.local).

ACL

Voyons maintenant les ACL. Par défaut, dans une FusionPBX nouvellement installée, il y a deux listes ACL :

domains action par défaut : deny — cette liste est liée au profil internal
lan action par défaut : allow

Dans la liste ACL domains, nous insérons le réseau (prenons par exemple 192.168.0.0/24), nousCEDONS à ce réseau l'autorisation allow, puis appliquons reloadacl.

Ensuite, nous enregistrons un téléphone depuis ce réseau, et cela semble correct, aussi bien en instruction qu'en logique.
Nous commençons à tester, nous faisons un appel vers un numéro externe et… nous obtenons un beignet, plus précisément un trou dans le beignet. Étonnant !

Nous commençons à analyser le log dans la console ou via le Log Viewer de FusioPBX.

Nous voyons notre appel :

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

Nous voyons l'ACL qui s'est déclenchée :

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

Et ensuite :

mod_dialplan_xml.c:637 Traitement de 1010 ->98343379xxxx dans le contexte public
switch_core_state_machine.c:311 Pas de route, abandon
switch_core_state_machine.c:312 Raccrochage sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Pas de route ! Bien que nous ayons une route inscrite.

La réponse est en réalité simple.

L'appel est arrivé. L'ACL l'a autorisé. Et comme l'ACL est lié au profil interne, et ce profil se trouve dans le contexte public, FreeSWITCH examine honnêtement le routage dans le contexte public. Mais dans le contexte public, seul le routage entrant est autorisé, et le système nous indique honnêtement qu'il n'y a aucune route en ville.

De cette situation, il y a au moins deux solutions.

Attacher cet ACL non pas au profil, mais au numéro interne lui-même. Cela pourrait être la meilleure méthode pour résoudre le problème, car il est préférable de lier l'ACL aussi près que possible de l’Extension pour un réglage plus fin. C'est-à-dire que l'on peut spécifier une adresse / réseau de téléphone spécifique à partir de laquelle il pourra passer un appel sortant. Le inconvénient de cette option est que cela doit être fait dans chaque Extension.
Ajuster l'ACL pour qu'il fonctionne correctement au niveau du profil. J'ai choisi cette option, car ajouter un réseau à l'ACL une fois me semblait plus simple que de l'inscrire dans chaque Extension. Mais cela est spécifiquement adapté à ma tâche. Pour d'autres tâches, une logique de décision différente peut être nécessaire.

Alors, corrigeons l'ACL domains comme suit :

action par défaut de domains : autoriser

Dans la liste ACL domains, nous inscrivons le réseau :

deny 192.168.0.0/24

Appliquons, reloadacl.
Testons : nous composons à nouveau le numéro 98343379xxxx et… ça sonne… ALLÔ. Tout fonctionne.
Voyons ce qui se passait dans FreeSWITCH :
début de l'appel :

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

L'ACL n'a pas autorisé :

[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejeté par acl "domains". Retour à l'authentification Digest.

et ensuite :

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

Le routage a réussi, et ensuite l'établissement de la connexion suit, ce qui dépasse le sujet.

Si nous changeons l'adresse réseau dans l'ACL, nous obtiendrons cependant le même résultat que lors du premier test, c'est-à-dire que l'ACL autorisera l'appel et que le routage indiquera NO_ROUTE_DESTINATION.

Voilà probablement tout ce que je voulais ajouter concernant l'ACL FusionPBX.

J'espère que cela sera utile à quelqu'un.

Source : habr.com