Mon article n'est pas une description complète du produit, mais seulement un léger perfectionnement de la bonne publication "FusionPBX, ou encore une fois génial, FreeSWITCH". Il me semble que le sujet de l'ACL dans FusionPBX n'y est pas très bien divulgué. J'essaierai de combler cette lacune en me basant sur ma propre expérience avec FreeSWITCH/FusionPBX.
Et donc, nous avons un FusionPBX installé avec un numéro interne enregistré 1010 dans le domaine domain.local et un itinéraire configuré pour les appels externes vers la ville. Nous utilisons les ACL pour sécuriser notre système téléphonique contre les appels non autorisés qui pourraient voler notre argent. Ceux. seuls les réseaux décrits dans l'ACL autorisent les appels sortants. Et ici, vous avez besoin d'une compréhension parfaitement claire du fonctionnement de l'ACL dans FusionPBX, de ses fonctionnalités, de sa logique et de son point d'ancrage.
Comme l'auteur respecté de l'article ci-dessus, j'ai également marché sur tous les râteaux liés à l'ACL.
Je vais commencer par Profils Sip.
Les deux profils (je les appellerai ainsi), tant internes qu'externes, sont dans le contexte Public, et ce n'est pas accidentel. L'enregistrement des numéros a lieu dans le profil interne et nous y prêtons attention. Dans le profil interne, l'ACL du domaine est liée en tant que apply-inbound-acl. C'est cette ligne qui est responsable du fonctionnement de l'ACL au niveau du profil. Pour l'instant, c'est tout avec les profils.
Comportementale
Le contexte est utilisé, entre autres, dans le routage des appels. Toutes les routes entrantes sont liées au contexte Public.
Les itinéraires sortants (vers la ville, vers le cellulaire, longue distance, international et tout autre) sont (par défaut) dans le contexte d'un nom de domaine (appelons-le domaine.local).
ACL
Parlons maintenant des ACL. Par défaut, un FusionPBX fraîchement installé possède deux ACL :
action par défaut des domaines : refuser - cette feuille est liée au profil interne
action par défaut du réseau local : autoriser
Dans la liste ACL des domaines, nous prescrivons le réseau (enfin, par exemple, 192.168.0.0/24), nous accordons l'autorisation pour ce réseau, nous utilisons reloadacl.
Ensuite, nous enregistrons le téléphone de ce réseau, et tout semble aller bien et selon les instructions et logiquement.
On commence les tests, on appelle un numéro externe et... on obtient un beignet, ou plutôt un trou de beignet. Soudainement!
Nous commençons à analyser le journal dans la console ou via le Log Viewer FusioPBX.
Nous voyons notre défi :
switch_channel.c:1104 New Channel sofia/internal/[email protected]Nous voyons l'ACL qui a fonctionné :
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.Et plus loin:
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] Pas d'itinéraire ! Bien que l'itinéraire que nous ayons honnêtement enregistré.
La réponse est vraiment simple.
L'appel est venu. ACL l'a raté. Et puisque l'ACL est liée au profil interne et que ce profil est dans le contexte public, FreeSWITCH examine honnêtement le routage dans le contexte public. Mais dans le contexte public, seul le routage entrant, et le système nous dit honnêtement qu'il n'y a pas de route vers la ville là-bas.
Il existe au moins deux solutions pour sortir de cette situation.
- Attachez cette ACL non pas au profil, mais au numéro interne lui-même. C'est peut-être la façon la plus correcte de résoudre, car. Il est préférable de lier l'ACL aussi près que possible de l'extension pour un réglage plus fin. Ceux. vous pouvez prescrire une adresse/adresse réseau spécifique du téléphone à partir de laquelle il peut passer un appel sortant. L’inconvénient de cette option est que chaque extension devra le faire.
- Corrigez l'ACL pour qu'elle fonctionne correctement au niveau du profil. J'ai choisi cette option, car il me semblait plus facile d'ajouter le réseau à l'ACL une seule fois que de le prescrire dans chaque extension. Mais c'est spécifiquement pour ma tâche. Pour d’autres tâches, vous aurez peut-être besoin d’une logique de prise de décision différente.
Donc. Corrigeons les domaines ACL comme suit :
action par défaut des domaines : autoriser
Dans la liste ACL des domaines, nous enregistrons le réseau :
refuser 192.168.0.0/24
Postulez, rechargez.
On teste : on compose à nouveau le numéro 98343379xxxx et... le checkpoint arrive... BONJOUR. Tout fonctionne.
Voyons ce qui s'est passé dans FreeSWITCH :
l'appel démarre :
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL n'a pas manqué :
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.et plus loin:
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 Le routage est passé, puis vient l'établissement de la connexion, qui dépasse le cadre du sujet.
Si nous modifions l'adresse réseau dans l'ACL, mais obtenons l'image du premier test, c'est-à-dire L'ACL ignorera l'appel et le routage dira NO_ROUTE_DESTINATION.
C'est probablement tout ce que je voulais ajouter sur ACL FusionPBX.
J'espère que cela sera utile à quelqu'un.
Source: habr.com