Mon article n'est pas une description complète du produit, mais seulement une petite clarification de la bonne publication «FusionPBX, ou encore, génial, FreeSWITCH». Il me semble que le sujet ACL dans FusionPBX n'est pas très bien couvert. Je vais essayer de combler cette lacune, sur la base de ma propre expérience avec FreeSWITCH / FusionPBX.
Et donc, nous avons installé FusionPBX avec le numéro de poste enregistré 1010 dans le domaine domain.local et une route configurée pour les appels externes vers la ville. Nous utilisons des listes de contrôle d'accès pour protéger notre système téléphonique contre les appels non autorisés qui nous prendraient notre argent. C'est-à-dire seuls les réseaux décrits dans ACL autorisent les appels sortants. Et ici, vous avez besoin d'une compréhension complètement claire du fonctionnement de l'ACL dans FusionPBX, de ses fonctionnalités, de sa logique et de son point d'attache.
Comme l'auteur respecté de l'article ci-dessus, j'ai également marché sur tous les râteaux associés à l'ACL.
Je vais commencer par
SipProfiles .
Les deux profils (je vais les appeler ainsi), et internes et externes sont dans le contexte de Public, et ce n'est pas un hasard. L'enregistrement des numéros a lieu dans le profil interne, et faites-y attention. Dans le profil interne, les domaines ACL sont liés en tant qu'appliquer-entrant-acl. Cette ligne est responsable du fonctionnement de l'ACL au niveau du profil. Jusqu'ici avec des profils.
Contexte
Le contexte, entre autres, est utilisé dans le routage des appels. Toutes les routes entrantes sont liées au contexte public.
Les itinéraires sortants (vers la ville, vers les réseaux cellulaires, interurbains, internationaux et tout autre) sont situés (par défaut) dans le contexte du nom de domaine (appelons-le domain.local).
ACL
Passons maintenant à l'ACL. Par défaut, le FusionPBX nouvellement installé possède deux ACL:
domaines action par défaut: refuser - cette feuille est liée au profil interne
lan action par défaut: autoriser
Dans la liste ACL des domaines, nous définissons le réseau (enfin, par exemple, 192.168.0.0/24), autorisons le réseau pour ce réseau, utilisez reloadacl.
Ensuite, enregistrez le téléphone à partir de ce réseau, et tout semble bien se passer selon les instructions et la logique.
Nous commençons les tests, appelons un numéro externe et ... nous obtenons un bagel, ou plutôt un trou d'un bagel. De façon inattendue!
Nous commençons à analyser le journal dans la console ou via le Log Viewer FusioPBX.
Nous voyons notre appel:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.local
Nous voyons l'ACL déclenché:
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/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]
Pas de route! Bien que l'itinéraire que nous avons honnêtement enregistré.
La réponse est vraiment simple.
L'appel est venu. ACL l'a raté. Et comme l'ACL est liée dans le profil interne et que ce profil est dans le contexte public, FreeSWITCH regarde honnêtement le routage dans le contexte public. Mais dans le contexte du public, il n'y a que le routage entrant, et le système nous dit honnêtement qu'il n'y a pas de routes vers la ville.
Il existe au moins deux façons de sortir de cette situation.
- Attachez cette ACL non pas au profil, mais au numéro interne. C'est peut-être la façon la plus correcte de résoudre, car Les listes de contrôle d'accès doivent être liées aussi près que possible de l'extension pour un réglage plus fin. C'est-à-dire Vous pouvez spécifier une adresse / adresse réseau spécifique du téléphone à partir de laquelle il peut effectuer un appel sortant. L'inconvénient de cette option est que dans chaque extension, vous devez le faire.
- Corrigez l'ACL pour qu'il fonctionne correctement au niveau du profil. J'ai choisi cette option, car ajouter un réseau à l'ACL me semblait une fois plus facile que de l'écrire dans chaque extension. Mais c'est spécifiquement pour ma tâche. Pour d'autres tâches, vous pouvez avoir besoin d'une logique de décision différente.
Et ainsi. Corrigeons les domaines ACL comme suit:
action par défaut des domaines: autoriser
Dans la liste ACL des domaines, nous définissons le réseau:
nier 192.168.0.0/24
Appliquez reloadacl.
On teste: on compose à nouveau le numéro 98343379xxxx et ... le CPV passe ... ALLO. Tout fonctionne.
Nous regardons ce qui s'est passé dans FreeSWITCH:
L'appel commence:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.local
ACL n'a pas manqué:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.
et en plus:
mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context domain.local sofia/internal/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]\d{6})$/ break=on-false
Le routage est passé, puis une connexion est établie qui dépasse la portée du sujet.
Si nous changeons l'adresse réseau dans l'ACL, mais obtenons l'image du premier test, c'est-à-dire L'appel ACL sautera et le routage dira NO_ROUTE_DESTINATION.
C'est probablement tout ce que je voulais ajouter à l'ACL FusionPBX.
J'espère que quelqu'un vous sera utile.