🥇FusionPBX și ACL

Articolul meu nu este o descriere completă a produsului, ci doar o mică clarificare a unei publicații bune intitulată „FusionPBX, sau din nou, FreeSWITCH”. Mi se pare că subiectul ACL în FusionPBX nu este foarte bine abordat în ea. Voi încerca să completez această lacună, bazându-mă pe propria experiență cu FreeSWITCH/FusionPBX.

Așadar, avem instalat FusionPBX cu un număr intern înregistrat, 1010, în domeniul domain.local, și un rutare configurată pentru apeluri externe în oraș. Folosim ACL pentru a ne proteja sistemul de telefonie de apeluri neautorizate, care ne-ar putea costa bani. Adică, doar din rețelele descrise în ACL vor fi permise apelurile externe. Și aici este necesar o înțelegere foarte clară a modului în care funcționează ACL în FusionPBX, a caracteristicilor, logicii și punctului său de legătură.

Ca și autorul respectat al articolului menționat mai sus, am trecut și eu prin toate capcanele legate de ACL.

Voi începe cu SipProfiles.
Ambele profile (le voi numi așa), atât internal, cât și external, se află în contextul Public, și nu este o întâmplare. Înregistrarea numerelor se face în profilul internal, la care ne vom concentra. În profilul internal este legat lista ACL domains ca apply-inbound-acl. Această linie este responsabilă pentru funcționarea ACL la nivelul profilului. Până acum, cu profilele e totul clar.

Context

Contextul, pe lângă toate celelalte, este utilizat în rutarea apelurilor. Toate rutele intrante sunt legate de contextul Public.

Rutele externe (în oraș, pe telefonul mobil, interurbane, internaționale și orice altele) se află (în mod implicit) în contextul denumit domeniu (să-l numim domain.local).

ACL

Acum să înțelegem ACL. În mod implicit, în FusionPBX proaspăt instalat există două liste de ACL:

domains acțiunea implicită: deny — această listă este legată de profilul internal
lan acțiunea implicită: allow

În lista ACL domains, specificăm rețeaua (de exemplu, 192.168.0.0/24), oferim acestei rețele permisiunea allow, aplicăm reloadacl.

Apoi, înregistrăm telefonul din această rețea, și se pare că totul este în regulă, conform instrucțiunilor și logic.
Începem să testăm, facem un apel către un număr extern și… obținem un eșec, sau mai bine zis, o gaură. Ne așteptam la asta!

Începem să analizăm jurnalul în consolă sau prin Log Viewer FusioPBX.

Vedem apelul nostru:

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

Vedem ACL-ul activat:

sofia.c:10208 IP 192.168.0.150 Aprobat de acl "domains[]". Accesul permis.

Și mai departe:

mod_dialplan_xml.c:637 Procesare 1010 ->98343379xxxx în context public
switch_core_state_machine.c:311 Fără rută, abatere 
switch_core_state_machine.c:312 Deconectare sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Fără rută! Deși ruta este corect definită.

Răspunsul este de fapt simplu.

Apelul a sosit. ACL l-a lăsat să treacă. Și deoarece ACL este legat de profilul intern, iar acest profil se află în context public, FreeSWITCH verifică în mod corect rutarea în contextul public. Dar în contextul public există doar rutare intrare, iar sistemul ne spune corect că nu există rute pentru oraș.

Din această situație, există cel puțin două soluții.

Să legăm acest ACL nu la profil, ci la numărul intern însuși. Aceasta ar putea fi cea mai corectă soluție, deoarece ACL este mai bine să fie legat cât mai aproape de Extensie pentru o configurare mai fină. Adică, putem specifica o adresă specifică/adresa rețelei de telefon de la care poate efectua un apel ieșit. Dezavantajul acestei variante este că va trebui să facem acest lucru în fiecare Extensie.
Să corectăm ACL astfel încât să funcționeze corect la nivel de profil. Am ales această variantă, deoarece să adaug o rețea în ACL mi s-a părut mai simplu decât să o specific în fiecare Extensie. Dar aceasta este specific pentru nevoile mele. Pentru alte sarcini, poate fi necesară o altă logică de decizie.

Așadar, să corectăm ACL domains astfel:

domains acțiunea implicită: allow

În lista ACL domains, specificăm rețeaua:

deny 192.168.0.0/24

Aplicăm, reloadacl.
Testăm: apelăm din nou numărul 98343379xxxx și… se aude KP și… ALO. Totul funcționează.
Să vedem ce s-a întâmplat în FreeSWITCH:
începe apelul:

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

ACL nu a lăsat să treacă:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Respins de acl "domains". Revenire la autentificarea Digest.

și apoi:

mod_dialplan_xml.c:637 Procesare 1010 ->98343379xxxx în context domain.local
sofia/internal/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^(9(8343[23]d{6}))$/ break=on-false

Rutarea a trecut, iar apoi urmează stabilirea conexiunii, care depășește tema.

Dacă schimbăm adresa rețelei în ACL, dar obținem imaginea din primul test, adică ACL va lăsa apelul să treacă și rutarea va spune NO_ROUTE_DESTINATION.

Cam aceasta ar fi tot ce am vrut să adaug despre ACL FusionPBX.

Sper că va fi de folos cuiva.

Sursa: habr.com