El meu article no és una descripció completa del producte, sinó només un lleuger refinament de la bona publicació "FusionPBX, o, de nou, genial, FreeSWITCH". Em sembla que el tema de l'ACL a FusionPBX no està molt ben divulgat. Intentaré omplir aquest buit basant-me en la meva pròpia experiència amb FreeSWITCH/FusionPBX.
Així, tenim instal·lat una FusionPBX amb un número intern registrat 1010 al domini domain.local i una ruta configurada per a trucades externes a la ciutat. Utilitzem ACL per protegir el nostre sistema de telefonia de trucades no autoritzades que ens llevaran diners. Aquells. només des de les xarxes descrites a l'ACL permeten trucades sortints. I aquí necessiteu una comprensió completament clara de com funciona l'ACL a FusionPBX, les seves característiques, la lògica i el seu punt d'ancoratge.
Igual que el respectat autor de l'article anterior, també vaig trepitjar tots els rastres relacionats amb ACL.
Començaré per SipProfiles.
Tots dos perfils (els anomenaré així), tant interns com externs, es troben en el context Públic, i això no és casual. El registre de números es fa al perfil intern, i hi pararem atenció. Al perfil intern, els dominis ACL s'enllacen com a apply-inbound-acl. És aquesta línia la responsable del funcionament de l'ACL a nivell de perfil. Fins ara, això és tot amb els perfils.
Context
El context s'utilitza, entre altres coses, en l'encaminament de trucades. Totes les rutes entrants estan vinculades al context públic.
Les rutes de sortida (a la ciutat, al mòbil, de llarga distància, internacionals i qualsevol altra) es troben (per defecte) en el context d'un nom de domini (anomenarem-lo domini.local).
ACL
Ara tractem les ACL. Per defecte, un FusionPBX recentment instal·lat té dues ACL:
Acció predeterminada de dominis: denegar: aquest full està lligat al perfil intern
acció per defecte de lan: permet
A la llista de dominis ACL, prescriu la xarxa (bé, per exemple, 192.168.0.0/24), fem el permís per permetre aquesta xarxa, fem servir reloadacl.
A continuació, registrem un telèfon des d'aquesta xarxa, i tot sembla estar bé i d'acord amb les instruccions i lògicament.
Comencem a provar, fem una trucada a un número extern i... ens surt un donut, o millor dit un forat de donut. De sobte!
Comencem a analitzar el log a la consola o mitjançant el Log Viewer FusioPBX.
Veiem el nostre repte:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Veiem l'ACL que va funcionar:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.I més enllà:
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] Sense ruta! Encara que la ruta l'hem registrat sincerament.
La resposta és realment senzilla.
Ha arribat la trucada. ACL s'ho va perdre. I com que l'ACL està vinculada al perfil intern i aquest perfil es troba en el context públic, FreeSWITCH mira honestament l'encaminament en el context públic. Però en el context públic, només l'encaminament d'entrada, i el sistema ens diu sincerament que no hi ha rutes cap a la ciutat allà.
Hi ha almenys dues maneres de sortir d'aquesta situació.
- Adjunteu aquesta ACL no al perfil, sinó al propi número intern. Aquesta pot ser la manera més correcta de resoldre, perquè. És millor lligar l'ACL el més a prop possible a l'extensió per a una sintonització més fina. Aquells. podeu prescriure una adreça específica/adreça de xarxa del telèfon des de la qual pot fer una trucada sortint. L'inconvenient d'aquesta opció és que cada extensió ho haurà de fer.
- Fixeu l'ACL perquè funcioni correctament a nivell de perfil. Vaig triar aquesta opció, perquè em va semblar més fàcil afegir la xarxa a l'ACL una vegada que prescriure-la a cada extensió. Però això és específicament per a la meva tasca. Per a altres tasques, és possible que necessiteu una lògica de presa de decisions diferent.
Tan. Arreglem els dominis ACL de la següent manera:
acció per defecte de dominis: permet
A la llista ACL de dominis, registrem la xarxa:
denegar 192.168.0.0/24
Aplicar, tornar a carregar.
Estem provant: tornem a marcar el número 98343379xxxx i... arriba el control... HOLA. Tot funciona.
Vegem què va passar a FreeSWITCH:
comença la trucada:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL no es va perdre:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.i més enllà:
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 L'encaminament ha passat, i després ve l'establiment de la connexió, que està fora de l'abast del tema.
Si canviem l'adreça de xarxa a l'ACL, però obtenim la imatge de la primera prova, és a dir. L'ACL saltarà la trucada i l'encaminament dirà NO_ROUTE_DESTINATION.
Això és probablement tot el que volia afegir a ACL FusionPBX.
Espero que sigui útil a algú.
Font: www.habr.com