🥇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) [Sity] destination_number(98343379xxxx) =~ / ^9(8343[23]d{6}) $/ break=on-false

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

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

Вероятно това е всичко, което исках да добавя относно ACL FusionPBX.

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

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