🥇FusionPBX и ACL

Moj članek ni poln opis izdelka, temveč le majhna dopolnitev dobre objave »FusionPBX, ali ponovno živimo, FreeSWITCH«. Zdi se mi, da tema ACL v FusionPBX ni bila dobro obravnavana. Poskusil bom zapolniti to vrzel na osnovi lastnih izkušenj s FreeSWITCH/FusionPBX.

Torej, imamo nameščen FusionPBX z registrirano interno številko 1010 v domeni domain.local in nastavljeno pot za zunanje klice v mesto. ACL uporabljamo, da zaščitimo naš telefonijski sistem pred nepooblaščenimi klici, ki bi nam vzeli denar. To pomeni, da dovolimo izhodne klice le iz omrežij, opisanih v ACL. Tu je potrebno zelo jasno razumevanje, kako ACL deluje v FusionPBX, njegove posebnosti, logiko in točko vezave.

Kot cenjeni avtor zgoraj omenjenega članka sem tudi jaz naletel na vse ovire, povezane z ACL.

Začel bom s SipProfiles.
Oba profila (imenoval ju bom tako), in internal in external se nahajata v kontekstu Public, kar ni naključje. Registracija številk poteka v profilu internal, na katerega se bomo usmerili. V profilu internal je vezan ACL seznam domains kot apply-inbound-acl. Prav ta vrstica je odgovorna za delovanje ACL na nivoju profila. Torej, s profili je vse jasno.

Context

Kontekst se, poleg vsega, uporablja za usklajevanje klicev. Vse vhodne poti so vezane na kontekst Public.

Izhodne poti (za mestne, mobilne, medkrajevne, mednarodne in vse druge) se po privzetku nahajajo v kontekstu imena domene (imenujmo ga domain.local).

ACL

Zdaj pa se lotimo ACL. Po privzetku imata pravkar nameščen FusionPBX dva ACL seznama:

domains privzeto dejanje: deny — ta seznam je povezan s profilom internal
lan privzeto dejanje: allow

V ACL seznam domains vnesemo omrežje (na primer 192.168.0.0/24), tej mreži omogočimo dovoljenje allow, uporabimo reloadacl.

Nato registriramo telefon iz te mreže, in vse se zdi dobro in smiselno po navodilih.
Začnemo s testiranjem, opravimo klic na zunanjo številko in… dobimo praznjenje, natančneje luknjo od praznjenja. Presenečenje!

Začnemo analizirati zapis v konzoli ali prek Log Viewer FusioPBX.

Vidimo naš klic:

switch_channel.c:1104 Nov kanal sofia/internal/1010@domain.local

Vidimo delujoči ACL:

sofia.c:10208 IP 192.168.0.150 Odobren z acl "domains[]". Dostop Dovoljen.

In nato:

mod_dialplan_xml.c:637 Обработка 1010 ->98343379xxxx в контексте public
switch_core_state_machine.c:311 Нет маршрута, прерывание 
switch_core_state_machine.c:312 Разрыв связи sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Нет маршрута! Хотя маршрут у нас честно прописан.

Ответ на самом деле прост.

Вызов пришел. ACL его пропустил. А так как ACL привязан к профилю internal, а этот профиль находится в контексте public, FreeSWITCH честно смотрит маршрутизацию в контексте public. Но в контексте public только входящая маршрутизация, и система честно нам говорит, что нет там никакого маршрута в город.

Из сложившейся ситуации есть как минимум два выхода.

Прикрутить этот ACL не к профилю, а к самому внутреннему номеру. Это может быть и самым правильным способом решения, так как ACL лучше привязывать как можно ближе к Extension для более тонкой настройки. Т.е. можно прописать конкретный адрес/адрес сети телефона, с которого он сможет сделать исходящий вызов. Минус этого варианта в том, что в каждом Extension придется это делать.
Поправить ACL так, чтобы он корректно работал на уровне профиля. Я выбрал именно этот вариант, ибо добавить один раз сеть в ACL мне показалось проще, чем прописывать его в каждом Extension. Но это конкретно под мою задачу. Для других задач, возможно, нужна другая логика принятия решения.

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

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

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

deny 192.168.0.0/24

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

switch_channel.c:1104 Nov kanal sofia/internal/1010@domain.local

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

[DEBUG] sofia.c:10263 IP 192.168.0.150 Отклонен acl "domains". Переход к Digest auth.

и далее:

mod_dialplan_xml.c:637 Обработка 1010 ->98343379xxxx в контексте 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.

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

Izvor: habr.com