🥇FusionPBX ja ACL

Minu artikkel ei ole toote põhjalik kirjeldus, vaid vaid väike täiendamine heale publikatsioonile „FusionPBX, või jälle-tervist, FreeSWITCH“. Tundub, et selles ei ole ACL teemat FusionPBX-is väga hästi käsitletud. Proovin selle tühiku täita, tuginedes oma kogemustele FreeSWITCH/FusionPBX-iga.

Nii siis, meil on installitud FusionPBX, kus on registreeritud sisemine number 1010 domeenis domain.local ja seadistatud marsruut väliste kõnede jaoks linna. Kasutame ACL-i, et kaitsta meie telefonisüsteemi volitamata kõnede eest, mis võtavad meie raha. St. ainult ACC-s kirja pandud võrkudest lubatakse väljakutseid. Siin on vajalik täiesti selge arusaam, kuidas ACL FusionPBX-is töötab, selle omadustest, loogikast ja seotud punktidest.

Nagu ka aukartust äratav autor eespool mainitud artiklis, olen ka mina kõndinud kõikidel selle ACL-iga seotud mülgastele.

Alustan SipProfiles.
Mõlemad profiilid (nimetame neid nii), nii internal kui ka external, kuuluvad konteksti Public, ja see ei ole juhus. Numbrite registreerimine toimub profiilis internal, sellele pöörame tähelepanu. Profiilis internal on seotud ACL-loend domains, kui apply-inbound-acl. Just see rida vastutab ACL-i töö eest profiili tasandil. Praeguseks profiilidega kõik.

Context

Konteksti kasutatakse lisaks kõnede marsruutimisele. Kõik sissetulevad marsruudid on seotud konteksti Public.

Välismarsruudid (linnas, mobiilile, kaug- ja rahvusvahelisele, ja kõik muudele) asuvad (vaikimisi) kontekstis nimega domeen (nimetame seda domain.local).

ACL

Nüüd uurime ACL-i. Vaikimisi on just installitud FusionPBX-is kaks ACL-loendit:

domains vaikimisi tegevus: deny — see loend on seotud profiiliga internal
lan vaikimisi tegevus: allow

ACL-loendisse domains kirjutame võrgu (näiteks 192.168.0.0/24), anname sellele võrgule lubamise allow ja rakendame reloadacl.

Seejärel registreerime telefoni sellest võrgust ja kõik tundub olevat hästi ning vastab juhistele.
Alustame testimist, teeme välise numbri pöördumise ja… saame bublik, täpsemalt bubliku augu. Üllatav!

Alustame logi analüüsimist konsoolis või läbi Log Viewer FusioPBX-is.

Näeme meie kõnet:

switch_channel.c:1104 Uus kanal sofia/internal/1010@domain.local

Näeme tööle hakanud ACL-i:

sofia.c:10208 IP 192.168.0.150 Heaks kiidetud acl "domains[]". Juurdepääs lubatud.

Ja edasi:

mod_dialplan_xml.c:637 Töödeldakse 1010 ->98343379xxxx kontekstis public
switch_core_state_machine.c:311 Ei ole marsruuti, katkestatakse 
switch_core_state_machine.c:312 Kõne lõpetatud sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Ei ole marsruuti! Kuigi marsruut on meil õigesti kirjas.

Vastus on tegelikult lihtne.

Kõne tuli. ACL laskis selle läbi. Ja kuna ACL on seotud internal profiiliga, ning see profiil asub kontekstis public, vaatab FreeSWITCH ausalt marsruutimist kontekstis public. Kuid kontekstis public on ainult sissetulev marsruutimine, ja süsteem ütleb meile ausalt, et seal ei ole mingeid marsruute linnas.

Väljapääse sellest olukorrast on vähemalt kaks.

Seostada see ACL mitte profiiliga, vaid iseenda sisemise numbriga. See võib olla kõige õigem lahendus, kuna ACL on parem siduda võimalikult lähedal Extension’ile, et teha peenhäälestust. St. on võimalik määrata konkreetne aadress/võrguaadress telefonile, millest ta saab teha väljaminevaid kõnesid. Selle variandi miinus on see, et igas Extension’is peab seda tegema.
Parandada ACL niimoodi, et see töötaks korrektselt profiili tasemel. Valisin just selle variandi, kuna võrgus-sisestamise lisamine ACL’le näis mulle lihtsam kui selle märkimine igas Extension’is. Kuid see on konkreetselt minu ülesande jaoks. Teiste ülesannete puhul võib olla vajalik teine otsustusloogika.

Nii. Parandame ACL domaines järgmiselt:

domains vaiketoiming: allow

ACL loendisse domains lisame võrgud:

deny 192.168.0.0/24

Rakendame, reloadacl.
Testime: valime uuesti numbri 98343379xxxx ja… toimub KP… Tere. Kõik töötab.
Vaadakem, mis FreeSWITCH’is toimus:
kõne algab:

switch_channel.c:1104 Uus kanal sofia/internal/1010@domain.local

ACL ei lasknud läbi:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Keelatud acl'i "domains" põhjal. Tagasi vahekõne tõendamisele.

ja edasi:

mod_dialplan_xml.c:637 Töödeldakse 1010 ->98343379xxxx kontekstis domain.local
sofia/internal/1010@domain.local Regex (PASS) [Sity] sihtnumber(98343379xxxx) =~ /9(8343[23]d{6})$/ break=on-false

Marsruutimine läks läbi ja edasi toimub ühenduse loomine, mis jääb teema piiridest välja.

Kui me muudame võrguaadressi ACL’is, saame aga tulemuse esimese testimise kujul, st. ACL laseb kõne läbi ja marsruutimine ütleb NO_ROUTE_DESTINATION.

See on tõenäoliselt kõik, mida ma soovisin ACL FusionPBX kohta lisada.

Loodan, et see kellegile kasulikuks osutub.

Allikas: habr.com