FusionPBX ja ACL

Minu artikkel ei ole toote täiskirjeldus, vaid vaid väike täiendamine heale publikatsioonile "FusionPBX, või jälle-tervet, FreeSWITCH". Minu arust ei ole ACL teema FusionPBX-is piisavalt hästi avatud. Proovin seda puuduolevat kohta täita, lähtudes oma kogemustest FreeSWITCHi/FusionPBX-i tööga.

Nii et meil on installitud FusionPBX, millel on registreeritud sise number 1010 domeenis domain.local ja väliskõnede marsruut linnas. Kasutame ACL-i, et kaitsta meie telefonisüsteemi volitamata kõnede eest, mis võivad meie raha kaasa võtta. See tähendab, et ainult nendele saadud ACL-is kirjeldatud võrkudest on lubatud väliskõned. Siin on vajalik täiesti selge arusaam, kuidas ACL FusionPBX-is töötab, selle eripärad, loogika ja seose punkt.

Nagu auväärne autor ülalmainitud artiklis, olen ka mina astunud kõikidele kividele, mis on seotud ACL-iga.

Alustan SipProfiles.
Mõlemad profiilid (nimega internal ja external) asuvad kontekstis Public, mis ei ole juhuslik. Numbrite registreerimine toimub profiilis internal, millele keskendume. Profiilis internal on seotud ACL-loend domains, mis on määratud kui apply-inbound-acl. Just see rida vastutab ACL toimimise eest profiili tasemel. Praegu on profiilidega kõik.

Kontekst

Konteksti kasutatakse, muuhulgas, kõnede suunamiseks. Kõik sisendmarsruudid on seotud kontekstiga Public.

Väljaminevad (linna, mobiilsed, kaug- ja rahvusvahelised ning muud) marsruudid asuvad (vaikimisi) nime kontekstis domeeni (nimetame seda domain.local).

ACL

Nüüd vaatame ACL-i selgemalt. Vaikimisi on just paigaldatud FusionPBX-is kaks ACL-loendit:

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

ACL-loendis domains määrame võrgu (näiteks 192.168.0.0/24), anname sellele võrgule lubamise allow, rakendame reloadacl.

Seejärel registreerime telefoni sellest võrgust ja tundub, et kõik on vastavalt juhistele ja loogikaga korras.
Alustame testimist, teeme kõne välisele numbrile ja... saame bagažipundi, täpsemalt bagažipundi auku. Üllatav!

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

Näeme meie kõnet:

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

Näeme aktiveeritud 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öötlen 1010 <1010>->98343379xxxx kontekstis public
switch_core_state_machine.c:311 Ei ole marsruuti, katkestamine
switch_core_state_machine.c:312 Sulge sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION] 

Ei ole marsruuti! Kuigi marsruut on meil korrektselt määratud.

Vastus on tegelikult lihtne.

Kõne saabus. ACL lasi selle läbi. Ja kuna ACL on seotud internal profiiliga, mis on kontekstis public, vaatab FreeSWITCH õigesti marsruutimist kontekstis public. Kuid kontekstis public on ainult sissetulev marsruutimine, ja süsteem ütleb meile selgelt, et seal ei ole mingeid marsroute linnas.

Kuna olukorrast on vähemalt kaks väljapääsu.

1. Seosta see ACL mitte profiiliga, vaid otse sisemise numbriga. See võib olla ka kõige õigem lahendus, kuna ACL-i on parem seostada võimalikult lähedale Extensioonile, et saavutada täpsem seadistus. Tõenäoliselt saab määrata konkreetse aadressi/adresside võrgu telefoni jaoks, millelt ta saab teha väljakutse. Selle variandi miinus on see, et iga Extensiooniga tuleb seda teha.
2. Paranda ACL nii, et see töötaks õigesti profiilitasandil. Valisin just selle variandi, kuna ühe korra võrgu lisamine ACL-i tundus mulle lihtsam kui selle määramine igas Extension'is. Aga see on just minu ülesande jaoks. Teiste ülesannete jaoks võib-olla vajatakse teistsugust otsustuslogikat.

Nii. Parandame ACL domains järgmiselt:

domains vaikimisi tegevus: lubada

ACL-nimekirjas domains määrame võrgu:

deny 192.168.0.0/24

Rakendame, reloadacl.
Testime: valime jälle numbri 98343379xxxx ja… toimub KP… ALOO. Kõik toimib.
Vaadake, mis FreeSWITCH-is juhtus:
kõne algab:

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

ACL ei lubanud:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.

ja edasi:

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

Marsruutimine õnnestus ja seejärel toimub ühenduse loomine, mis ületab teema raame.

Kui me muudame võrgu aadressi ACL-is, kuid saame pildi, mis on esimese testimise tulemus, st. ACL lubab kõne ja marsruutimine ütleb NO_ROUTE_DESTINATION.

See on ilmselt kõik, mida ma soovisin ACL FusionPBX kohta lisada.

Loodan, et kellelegi on see kasuks.

Allikas: habr.com