🥇 FusionPBX und ACL

Mein Artikel ist keine umfassende Produktbeschreibung, sondern lediglich eine kleine Erweiterung der hervorragenden Veröffentlichung 'FusionPBX oder wiedersehen, FreeSWITCH'. Ich finde, dass das Thema ACL in FusionPBX nicht ausreichend behandelt wird. Ich werde versuchen, diese Lücke anhand meiner eigenen Erfahrungen mit FreeSWITCH/FusionPBX zu schließen.

Also, wir haben FusionPBX installiert, mit der intern registrierten Nummer 1010 in der Domain domain.local und einer konfigurierten Route für externe Anrufe in die Stadt. ACL verwenden wir, um unser Telefonsystem vor unbefugten Anrufen zu schützen, die uns Geld kosten könnten. Das bedeutet, dass nur aus den in ACL beschriebenen Netzwerken ausgehende Anrufe erlaubt sind. Hier ist es wichtig, ein klares Verständnis für die Funktionsweise von ACL in FusionPBX zu haben, einschließlich seiner Besonderheiten, Logik und Bindepunkte.

Wie der respektierte Autor des oben genannten Artikels bin auch ich auf alle Hindernisse gestoßen, die mit ACL verbunden sind.

Ich beginne mit SipProfiles.
Beide Profile (ich werde sie so nennen), 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 uns konzentrieren werden. Im Profil internal ist eine ACL-Liste domains als apply-inbound-acl verknüpft. Genau diese Zeile ist für die Funktion der ACL auf Profilebene verantwortlich. So viel zu den Profilen.

Kontext

Der Kontext wird unter anderem in der Anrufweiterleitung verwendet. Alle eingehenden Routen sind mit dem Kontext Public verknüpft.

Ausgehende Routen (in die Stadt, zu Mobiltelefonen, Ferngespräche, international und andere) befinden sich (standardmäßig) im Kontext mit dem Namen Nach Abschluss des Transfers kann die Domain auf unser Hosting gerichtet werden. (nennen wir ihn domain.local).

ACL

Nun lassen Sie uns die ACL genauer ansehen. In der frisch installierten FusionPBX gibt es standardmäßig zwei ACL-Listen:

domains Standardaktion: deny — diese Liste ist mit dem Profil internal verknüpft
lan Standardaktion: allow

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

Dann registrieren wir ein Telefon in diesem Netzwerk, und alles scheint nach den Anweisungen und logisch zu sein.
Wir beginnen mit Tests, tätigen einen Anruf zu einer externen Nummer und… erhalten ein Loch, genauer gesagt ein Donutloch. Unerwartet!

Wir beginnen mit der Analyse des Protokolls in der Konsole oder über den Log Viewer von FusioPBX.

Wir sehen unseren Anruf:

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

Wir sehen die aktivierte ACL:

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

Und weiter:

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

Keine Route! Obwohl die Route korrekt eingerichtet ist.

Die Antwort ist eigentlich einfach.

Der Anruf kam an. Die ACL hat ihn durchgelassen. Da die ACL jedoch an das Profil internal gebunden ist und dieses Profil sich im Kontext public befindet, schaut FreeSWITCH ehrlicherweise in die Routing-Logik im Kontext public. Aber im Kontext public gibt es nur eingehendes Routing, und das System sagt uns ehrlich, dass es dort keine Routen in die Stadt gibt.

Aus der aktuellen Situation gibt es mindestens zwei Auswege.

Binden Sie diese ACL nicht an das Profil, sondern direkt an die interne Nummer. Dies könnte der sinnvollste Lösungsansatz sein, da ACLs besser so nah wie möglich an der Extension gebunden werden sollten, um eine feinere Anpassung zu ermöglichen. Das bedeutet, dass Sie eine spezifische IP-Adresse oder ein Netzwerk angeben können, von dem aus der Anruf ausgehende Verbindungen tätigen kann. Der Nachteil dieser Variante ist, dass dies in jeder Extension durchgeführt werden muss.
Поправить ACL так, чтобы он корректно работал на уровне профиля. Я выбрал именно этот вариант, ибо добавить один раз сеть в ACL мне показалось проще, чем прописывать его в каждом Extension. Но это конкретно под мою задачу. Для других задач, возможно, нужна другая логика принятия решения.

И так. Поправим ACL domains следующим образом:

domains действие по умолчанию: allow

В ACL-лист domains прописываем сеть:

deny 192.168.0.0/24

Применяем, reloadacl.
Тестируем: набираем снова номер 98343379хххх и… идёт КПВ… АЛЛО. Всё работает.
Смотрим, что происходило в FreeSWITCH:
начинается вызов:

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

ACL не пропустил:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.

и далее:

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

Маршрутизация прошла, и далее идет установление соединения, которое выходит за рамки темы.

Если мы поменяем адрес сети в ACL, но получим картину из первого тестирования, т.е. ACL вызов пропустит и маршрутизация скажет NO_ROUTE_DESTINATION.

Вот наверное и всё, что я хотел дополнить по ACL FusionPBX.

Надеюсь кому нибудь пригодится.

Quelle: habr.com