🥇FusionPBX и ACL

Моя статия не е пълноценно описание на продукта, а само кратко уточнение на добрата публикация «FusionPBX, или отново здравей, FreeSWITCH». Смятам, че темата за ACL в FusionPBX не е много добре разгледана в нея. Ще се опитам да запълня тази празнота, основавайки се на собствения си опит с FreeSWITCH/FusionPBX.

И така, имаме инсталиран FusionPBX с регистриран вътрешен номер 1010 в домейна domain.local и настроен маршрут за външни обаждания към града. Използваме ACL, за да защитим нашата телефонна система от несанкционирани обаждания, които могат да ни струват пари. Тоест, разрешаваме изходящи обаждания само от мрежите, описани в ACL. И тук е важно да разберем как точно работи ACL в FusionPBX, неговите особености, логиката и точката на свързване.

Както и уважаваният автор на споменатата статия, и аз също станах жертва на всички капани, свързани с ACL.

Ще започна с SipProfiles.
И двата профила (ще ги наричам така), и internal, и external, се намират в контекста Public, и това не е случайно. Регистрацията на номерата се извършва в профила internal, на който ще обърнем внимание. В профила internal е свързан ACL-лист domains като apply-inbound-acl. Именно тази линия отговаря за функционирането на ACL на ниво профил. Дотук с профилите.

Context

Контекстът, освен всичко друго, се използва в маршрутизацията на обажданията. Всички входящи маршрути са свързани с контекста Public.

Изходящите (за града, на мобилни, междуградски, международни и всякакви други) маршрути по подразбиране се намират в контекста на името домейн (нека го наречем domain.local).

ACL

Сега нека се разберем с ACL. По подразбиране, в току-що инсталирания FusionPBX има два ACL-листа:

domains, действие по подразбиране: deny — този лист е свързан с профила internal
lan, действие по подразбиране: allow

В ACL-листа domains вписваме мрежата (например 192.168.0.0/24), даваме разрешение allow на тази мрежа и прилагаме reloadacl.

След това регистрираме телефон от тази мрежа и изглежда, че всичко е в ред и по инструкциите и логично.
Започваме да тестваме, правим обаждане на външен номер и… получаваме дупка, а точното определение е бублик. Неочаквано!

Започваме да анализираме логовете в конзолата или през Log Viewer на FusioPBX.

Виждаме нашето обаждане:

switch_channel.c:1104 New Channel sofia/internal/1010@domain.local

Виждаме сработилия ACL:

sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.

И по-нататък:

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.
Тестуваме: набираме отново номер 98343379xxxx и… идва КПВ… АЛО. Всичко работи.
Гледаме какво се е случило в FreeSWITCH:
започва обаждането:

switch_channel.c:1104 New Channel 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) [Сити] destination_number(98343379xxxx) =~ / ^9(8343[23]d{6}) $/ break=on-false

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

Ако сменим адреса на мрежата в ACL, но получим картината от първото тестване, т.е. ACL ще допусне обаждането и маршрутизацията ще каже NO_ROUTE_DESTINATION.

Ето изобщо всичко, което исках да добавя по ACL FusionPBX.

Надявам се да е полезно на някого.

Източник: habr.com