FusionPBX и ACL

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

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

Подобно на уважавания автор на горната статия, аз също стъпих на всички гребла, свързани с ACL.

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

Контекст

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

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

ACL

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

домейни действие по подразбиране: отказ - този лист е обвързан с вътрешния профил
lan действие по подразбиране: разреши

В списъка с ACL на домейни ние предписваме мрежата (добре, например 192.168.0.0/24), правим разрешение за разрешаване на тази мрежа, използваме reloadacl.

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

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

Виждаме нашето предизвикателство:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

Виждаме ACL, който работи:

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

И още:

mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context public
switch_core_state_machine.c:311 No Route, Aborting 
switch_core_state_machine.c:312 Hangup sofia/internal/[email protected] [CS_ROUTING] [NO_ROUTE_DESTINATION] 

Без маршрут! Въпреки че маршрутът сме честно регистрирани.

Отговорът е наистина прост.

Обаждането дойде. ACL го пропусна. И тъй като ACL е обвързан във вътрешния профил и този профил е в публичния контекст, FreeSWITCH честно гледа на маршрутизирането в публичния контекст. Но в публичния контекст само входящо маршрутизиране и системата честно ни казва, че няма маршрути до града там.

Има поне два изхода от тази ситуация.

1. Прикрепете този ACL не към профила, а към самия вътрешен номер. Това може да е най-правилният начин за решаване, т.к. По-добре е да свържете ACL възможно най-близо до разширението за по-фина настройка. Тези. можете да зададете конкретен адрес / мрежов адрес на телефона, от който да може да осъществява изходящо повикване. Недостатъкът на тази опция е, че всяко разширение ще трябва да прави това.
2. Коригирайте ACL, така че да работи правилно на ниво профил. Избрах тази опция, защото ми се стори по-лесно да добавя мрежата към ACL веднъж, отколкото да я предписвам във всяко разширение. Но това е специално за моята задача. За други задачи може да се нуждаете от различна логика за вземане на решения.

Така. Нека коригираме ACL домейните, както следва:

действие по подразбиране на домейни: разреши

В списъка с ACL на домейни регистрираме мрежата:

откажи 192.168.0.0/24

Прилагане, презареждане.
Тестваме: набираме отново номера 98343379xxxx и ... контролно-пропускателният пункт идва ... ЗДРАВЕЙТЕ. Всичко работи.
Нека да видим какво се случи във FreeSWITCH:
разговор започва:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

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

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

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

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

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

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