FusionPBX und ACL

Mein Artikel ist keine umfassende Produktbeschreibung, sondern lediglich eine kleine Ergänzung zu dem guten Beitrag „FusionPBX, oder wieder einmal, FreeSWITCH“. Ich denke, dass das Thema ACL in FusionPBX nicht ganz ausreichend behandelt wird. Ich werde versuchen, diese Lücke basierend auf meiner eigenen Erfahrung mit FreeSWITCH/FusionPBX zu schließen.

Also haben wir FusionPBX installiert mit der registrierten internen Nummer 1010 im Domain domain.local und einer eingerichteten Route für externe Anrufe in die Stadt. Wir verwenden ACL, um unser Telefonsystem vor unbefugten Anrufen zu schützen, die unsere Kohle kosten könnten. Das bedeutet, dass nur aus den in der ACL beschriebenen Netzwerken ausgehende Anrufe erlaubt sind. Hier ist ein klares Verständnis darüber erforderlich, wie ACL in FusionPBX funktioniert, seine Besonderheiten, Logik und Bindung.

Wie der geschätzte Autor des oben genannten Artikels bin ich ebenfalls über alle Stolpersteine gestolpert, die mit ACL verbunden sind.

Ich beginne mit SipProfiles.
Beide Profile (ich werde sie so bezeichnen), sowohl internal als auch external, befinden sich im Kontext Public, und das ist kein Zufall. Die Registrierung der Nummern erfolgt im Profil internal, auf das wir achten werden. Im Profil internal ist die ACL-Liste domains als apply-inbound-acl gebunden. Genau diese Zeile ist verantwortlich für das Funktionieren der ACL auf Profilebene. Mit den Profilen ist alles klar.

Context

Der Kontext wird, unter anderem, auch für die Anrufweiterleitung verwendet. Alle eingehenden Routen sind an den Kontext Public gebunden.

Ausgehende Routen (in die Stadt, zu Mobiltelefonen, Ferngespräche, internationale Anrufe und alle anderen) befinden sich (standardmäßig) im Kontext des Namens der Domain unterscheiden, gesetzt werden. (nennen wir ihn domain.local).

ACL

Jetzt schauen wir uns die ACL genauer an. Standardmäßig hat die frisch installierte FusionPBX zwei ACL-Listen:

domains Standardaktion: deny — diese Liste ist an das Profil internal gebunden
lan Standardaktion: allow

In die ACL-Liste domains schreiben wir das Netzwerk (zum Beispiel 192.168.0.0/24), geben diesem Netzwerk die Erlaubnis allow und wenden reloadacl an.

Danach registrieren wir ein Telefon aus diesem Netzwerk, und anscheinend ist alles gut und gemäß der Anleitung auch logisch.
Wir beginnen mit dem Testen, rufen eine externe Nummer an und… bekommen ein Nichts, genauer gesagt ein Loch in der Mitte. Unerwartet!

Wir analysieren das Protokoll in der Konsole oder über den Log Viewer von FusionPBX.

Wir sehen unseren Anruf:

switch_channel.c:1104 Neuer Kanal sofia/internal/1010@domain.local

Wir sehen, dass die ACL aktiviert wurde:

sofia.c:10208 IP 192.168.0.150 Genehmigt durch acl "domains[]". Zugriff gewährt.

Und weiter:

mod_dialplan_xml.c:637 Verarbeite 1010 ->98343379xxxx im Kontext public
switch_core_state_machine.c:311 Kein Route, Abbruch 
switch_core_state_machine.c:312 Anrufbeendigung sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION] 

Kein Route! Obwohl die Route korrekt angegeben ist.

Die Antwort ist eigentlich einfach.

Der Anruf kam an. Die ACL hat ihn durchgelassen. Da die ACL jedoch dem Profil internal zugeordnet ist und sich dieses Profil im Kontext public befindet, betrachtet FreeSWITCH fairerweise die Routing-Regeln im Kontext public. Aber im Kontext public gibt es nur eingehende Routing-Regeln, und das System sagt uns ganz klar, dass es dort keine Routen in die Stadt gibt.

Es gibt mindestens zwei Möglichkeiten aus der bestehenden Situation.

1. Diese ACL nicht am Profil, sondern direkt an der internen Nummer zu fixieren. Dies könnte die beste Lösung sein, da ACLs möglichst nah an der Extension gebunden werden sollten, um gezielte Einstellungen vorzunehmen. Das heißt, es kann eine bestimmte Adresse oder ein Netzwerk des Telefons eingetragen werden, von dem aus ein ausgehender Anruf getätigt werden kann. Der Nachteil dieser Option ist, dass dies in jeder Extension gemacht werden muss.
2. Die ACL so anzupassen, dass sie korrekt auf Profil-Ebene funktioniert. Ich habe genau diese Option gewählt, da es mir einfacher erschien, ein Netzwerk einmal in die ACL einzufügen, als es in jeder Extension zu hinterlegen. Aber das ist konkret für meine Aufgabe. Für andere Aufgaben könnte eine andere Logik erforderlich sein.

Also, lassen Sie uns die ACL domains folgendermaßen anpassen:

domains Standardaktion: allow

Wir fügen das Netzwerk zur ACL-Liste domains hinzu:

deny 192.168.0.0/24

Anwenden, reloadacl.
Testen: Wir wählen erneut die Nummer 98343379xxxx und… es erfolgt eine Verbindung… HALLO. Alles funktioniert.
Schauen wir uns an, was in FreeSWITCH passiert ist:
Der Anruf beginnt:

switch_channel.c:1104 Neuer Kanal sofia/internal/1010@domain.local

Die ACL hat nicht zugelassen:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Von der ACL "domains" abgelehnt. Fallback zu Digest-Authentifizierung.

und weiter:

mod_dialplan_xml.c:637 Verarbeite 1010 ->98343379xxxx im Kontext domain.local
sofia/internal/1010@domain.local Regex (PASS) [Stadt] zielnummer(98343379xxxx) =~ /^9(8343[23]d{6})$/ break=on-false 

Das Routing hat funktioniert, und anschließend erfolgt der Verbindungsaufbau, der über das Thema hinausgeht.

Wenn wir die Netzwerkadresse in der ACL ändern, aber das Bild aus dem ersten Test erhalten, d.h. die ACL lässt den Anruf durch und das Routing sagt NO_ROUTE_DESTINATION.

Das ist wahrscheinlich alles, was ich zur ACL FusionPBX hinzufügen wollte.

Ich hoffe, es wird irgendjemandem nützlich sein.

Quelle: habr.com