Mein Artikel ist keine vollständige Beschreibung des Produkts, sondern nur eine kleine Klarstellung der guten Veröffentlichung „FusionPBX oder wieder großartig, FreeSWITCH“. Es scheint mir, dass das ACL-Thema in FusionPBX nicht sehr gut behandelt wird. Ich werde versuchen, diese Lücke zu schließen, basierend auf meinen eigenen Erfahrungen mit FreeSWITCH / FusionPBX.
Daher haben wir FusionPBX mit einer registrierten Nebenstellennummer 1010 in der Domäne domain.local und einer konfigurierten Route für externe Anrufe in die Stadt installiert. Wir verwenden ACLs, um unser Telefoniesystem vor unbefugten Anrufen zu schützen, die unser Geld kosten. Das heißt, Nur aus den in ACL beschriebenen Netzwerken können ausgehende Anrufe zugelassen werden. Und hier benötigen Sie ein sehr klares Verständnis der Funktionsweise der ACL in FusionPBX, ihrer Funktionen, ihrer Logik und ihres Bindungspunkts.
Wie der angesehene Autor des obigen Artikels bin ich auch auf alle mit der ACL verbundenen Rechen getreten.
Ich werde mit
SipProfiles beginnen .
Beide Profile (ich werde sie so nennen) sowie intern und extern stehen im Kontext der Öffentlichkeit, und dies ist kein Zufall. Die Registrierung von Nummern erfolgt im internen Profil und ist zu beachten. Im internen Profil ist die Domänen-ACL als apply-inbound-acl gebunden. Diese Zeile ist für den Betrieb der ACL auf Profilebene verantwortlich. Soweit mit Profilen.
Kontext
Der Kontext wird unter anderem bei der Anrufweiterleitung verwendet. Alle eingehenden Routen sind an den öffentlichen Kontext gebunden.
Ausgehende (in die Stadt, zu Mobilfunk-, Intercity-, internationale und andere) Routen befinden sich (standardmäßig) im Kontext des Domainnamens (nennen wir es domain.local).
ACL
Nun beschäftigen wir uns mit der ACL. Standardmäßig verfügt die neu installierte FusionPBX über zwei ACLs:
Standardaktion für Domänen: Verweigern - Dieses Blatt ist an das interne Profil gebunden
LAN-Standardaktion: Zulassen
In der Domänen-ACL-Liste legen wir das Netzwerk fest (z. B. 192.168.0.0/24), lassen das Netzwerk für dieses Netzwerk zulassen und verwenden reloadacl.
Registrieren Sie als Nächstes das Telefon aus diesem Netzwerk, und alles scheint gemäß den Anweisungen und der Logik in Ordnung zu sein.
Wir fangen an zu testen, rufen eine externe Nummer an und ... wir bekommen einen Bagel oder besser gesagt ein Loch von einem Bagel. Unerwartet!
Wir beginnen mit der Analyse des Protokolls in der Konsole oder über den Log Viewer FusioPBX.
Wir sehen unseren Ruf:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.local
Wir sehen die ausgelöste ACL:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.
Und weiter:
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]
Keine Route! Obwohl die Route wir ehrlich registriert haben.
Die Antwort ist wirklich einfach.
Der Anruf ist gekommen. ACL hat es verpasst. Und da die ACL im internen Profil gebunden ist und sich dieses Profil im öffentlichen Kontext befindet, betrachtet FreeSWITCH das Routing im öffentlichen Kontext ehrlich. Im öffentlichen Kontext gibt es jedoch nur eingehende Routen, und das System sagt uns ehrlich, dass es dort keine Routen in die Stadt gibt.
Es gibt mindestens zwei Auswege aus dieser Situation.
- Fügen Sie diese ACL nicht dem Profil, sondern der internen Nummer hinzu. Dies kann der richtigste Weg sein, um zu lösen, weil ACLs sollten für eine feinere Abstimmung so nah wie möglich an der Erweiterung gebunden werden. Das heißt, Sie können eine bestimmte Adresse / Netzwerkadresse des Telefons angeben, von dem aus er einen ausgehenden Anruf tätigen kann. Der Nachteil dieser Option ist, dass Sie dies in jeder Erweiterung tun müssen.
- Korrigieren Sie die ACL so, dass sie auf Profilebene ordnungsgemäß funktioniert. Ich habe diese Option gewählt, weil mir das Hinzufügen eines Netzwerks zur ACL einmal einfacher erschien, als es in jede Erweiterung zu schreiben. Dies ist jedoch speziell für meine Aufgabe. Für andere Aufgaben benötigen Sie möglicherweise eine andere Entscheidungslogik.
Und so. Korrigieren wir die ACL-Domänen wie folgt:
Standardaktion für Domänen: Zulassen
In der Domänen-ACL-Liste legen wir das Netzwerk fest:
verweigern 192.168.0.0/24
Reloadacl anwenden.
Wir testen: Wir wählen erneut die Nummer 98343379xxxx und ... der CPV geht ... ALLO. Alles arbeitet.
Wir schauen uns an, was in FreeSWITCH passiert ist:
Der Anruf beginnt:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.local
ACL hat nicht gefehlt:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.
und weiter:
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
Das Routing ist abgeschlossen, und dann wird eine Verbindung hergestellt, die über den Rahmen des Themas hinausgeht.
Wenn wir die Netzwerkadresse in der ACL ändern, aber das Bild vom ersten Test erhalten, d. H. Der ACL-Aufruf wird übersprungen und das Routing sagt NO_ROUTE_DESTINATION.
Das ist wahrscheinlich alles, was ich der FusionPBX-ACL hinzufügen wollte.
Ich hoffe, jemand ist nützlich.