Mein Artikel ist keine vollständige Beschreibung des Produkts, sondern nur eine leichte Verfeinerung der guten Veröffentlichung „FusionPBX, oder wiederum großartig, FreeSWITCH“. Es scheint mir, dass das Thema ACL in FusionPBX darin nicht sehr gut behandelt wird. Ich werde versuchen, diese Lücke auf der Grundlage meiner eigenen Erfahrungen mit FreeSWITCH/FusionPBX zu schließen.
Und so haben wir eine installierte FusionPBX mit einer registrierten internen Nummer 1010 in der Domain domain.local und einer konfigurierten Route für externe Anrufe in die Stadt. Wir verwenden ACL, um unser Telefonsystem vor unbefugten Anrufen zu schützen, die uns Geld wegnehmen. Diese. Nur aus den in der ACL beschriebenen Netzwerken sind ausgehende Anrufe zulässig. Und hier benötigen Sie ein völlig klares Verständnis der Funktionsweise von ACL in FusionPBX, seiner Funktionen, seiner Logik und seines Ankerpunkts.
Wie der angesehene Autor des obigen Artikels bin auch ich auf alle mit ACL verbundenen Rechen getreten.
Ich werde beginnen mit SipProfiles.
Beide Profile (ich werde sie so nennen), sowohl interne als auch externe, befinden sich im öffentlichen Kontext, und das ist kein Zufall. Die Registrierung der Nummern erfolgt im internen Profil und wir werden darauf achten. 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. So weit, das wars mit den Profilen.
Kontext
Der Kontext wird unter anderem bei der Anrufweiterleitung verwendet. Alle eingehenden Routen sind an den öffentlichen Kontext gebunden.
Ausgehende Routen (in die Stadt, zum Mobilfunk, über Ferngespräche, ins Ausland und zu allen anderen Routen) stehen (standardmäßig) im Kontext eines Domänennamens (nennen wir ihn domain.local).
ACL
Kommen wir nun zu den ACLs. Standardmäßig verfügt eine frisch installierte FusionPBX über zwei ACLs:
Standardaktion für Domänen: verweigern – Dieses Blatt ist an das interne Profil gebunden
LAN-Standardaktion: erlauben
In der ACL-Liste der Domänen geben wir das Netzwerk vor (also zum Beispiel 192.168.0.0/24), wir erteilen die Zulassungsberechtigung für dieses Netzwerk und verwenden reloadacl.
Als nächstes registrieren wir ein Telefon aus diesem Netzwerk und alles scheint in Ordnung zu sein, den Anweisungen entsprechend und logisch.
Wir fangen an zu testen, rufen eine externe Nummer an und ... wir bekommen einen Donut, oder besser gesagt ein Donut-Loch. Plötzlich!
Wir beginnen mit der Analyse des Protokolls in der Konsole oder über den Log Viewer FusioPBX.
Wir sehen unsere Herausforderung:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Wir sehen die ACL, die funktioniert hat:
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/[email protected] [CS_ROUTING] [NO_ROUTE_DESTINATION] Kein Weg! Obwohl wir die Route 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 ehrlich im öffentlichen Kontext. Aber im öffentlichen Kontext nur eingehendes Routing, und das System sagt uns ehrlich, dass es dort keine Routen in die Stadt gibt.
Es gibt mindestens zwei Auswege aus dieser Situation.
- Hängen Sie diese ACL nicht an das Profil, sondern an die interne Nummer selbst an. Dies ist möglicherweise der korrekteste Lösungsweg, weil. Für eine feinere Abstimmung ist es besser, ACL so nah wie möglich an die Erweiterung zu binden. Diese. Sie können dem Telefon eine bestimmte Adresse/Netzwerkadresse vorgeben, von der aus es einen ausgehenden Anruf tätigen kann. Der Nachteil dieser Option besteht darin, dass dies von jeder Erweiterung durchgeführt werden muss.
- Korrigieren Sie die ACL, damit sie auf Profilebene ordnungsgemäß funktioniert. Ich habe mich für diese Option entschieden, weil es mir einfacher erschien, das Netzwerk einmal zur ACL hinzuzufügen, als es in jeder Erweiterung vorzuschreiben. Aber das ist speziell für meine Aufgabe. Für andere Aufgaben benötigen Sie möglicherweise eine andere Entscheidungslogik.
Also. Lassen Sie uns die ACL-Domänen wie folgt reparieren:
Standardaktion für Domänen: zulassen
In der Domänen-ACL-Liste registrieren wir das Netzwerk:
leugnen 192.168.0.0/24
Anwenden, neu ladenacl.
Wir testen: Wir wählen erneut die Nummer 98343379xxxx und ... der Checkpoint kommt ... HALLO. Alles arbeitet.
Mal sehen, was in FreeSWITCH passiert ist:
Anruf beginnt:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL hat nicht verpasst:
[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/[email protected] Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]d{6})$/ break=on-false Das Routing ist vorbei, und dann kommt der Verbindungsaufbau, der den Rahmen des Themas sprengen würde.
Wenn wir die Netzwerkadresse in der ACL ändern, erhalten wir aber das Bild vom ersten Test, d.h. Die ACL überspringt den Anruf und das Routing sagt NO_ROUTE_DESTINATION.
Das ist wahrscheinlich alles, was ich zu ACL FusionPBX hinzufügen wollte.
Ich hoffe, dass es jemandem nützlich sein wird.
Source: habr.com