Моя стаття — не повноцінний опис продукту, а лише невелике уточнення гарної публікації «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