Мой артыкул – не паўнавартаснае апісанне прадукта, а толькі невялікае ўдакладненне добрай публікацыі «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 на ўзроўні профіля. Пакуль з профілямі ўсё.
Кантэкст
Кантэкст, акрамя ўсяго іншага, выкарыстоўваецца ў маршрутызацыі выклікаў. Усе ўваходныя маршруты прывязаны да кантэксту 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/[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 прывязаны ў профілі 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 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.
Спадзяюся каму-небудзь спатрэбіцца.
Крыніца: habr.com