FusionPBX ja ACL

Minu artikkel ei ole toote täielik kirjeldus, vaid hea väljaande "FusionPBX või jällegi suurepärane FreeSWITCH" väike täpsustus. Mulle tundub, et FusionPBX-i ACL-i teema pole selles kuigi hästi avalikustatud. Proovin seda lünka täita, tuginedes oma kogemusele FreeSWITCH/FusionPBX-iga.

Ja nii on meil installitud FusionPBX registreeritud sisenumbriga 1010 domeenis domain.local ja konfigureeritud marsruut linna väliskõnede jaoks. Kasutame ACL-i, et kaitsta oma telefonisüsteemi volitamata kõnede eest, mis võtavad meie raha ära. Need. väljaminevaid kõnesid lubada ainult ACL-is kirjeldatud võrkudest. Ja siin on teil vaja täiesti selget arusaama ACL-i toimimisest FusionPBX-is, selle funktsioonidest, loogikast ja kinnituspunktist.

Nagu ülaltoodud artikli lugupeetud autor, astusin ka mina kõikidele ACL-iga seotud rehadele.

Alustan sellest SipProfiilid.
Mõlemad profiilid (ma nimetan neid nii), nii sisemised kui ka välised, on avalikus kontekstis ja see pole juhuslik. Numbrite registreerimine toimub siseprofiilis ja me pöörame sellele tähelepanu. Siseprofiilis on domeenide ACL seotud kui rakenda-sissetulev-acl. Just see rida vastutab ACL-i toimimise eest profiili tasemel. Siiani on profiilidega kõik.

kontekst

Kõnede suunamisel kasutatakse muu hulgas konteksti. Kõik sissetulevad marsruudid on seotud avaliku kontekstiga.

Väljuvad marsruudid (linna, mobiilsidevõrku, kaug-, rahvusvahelisi ja muid) on (vaikimisi) domeeninime kontekstis (nimetagem seda domeeniks.local).

ACL

Nüüd tegeleme ACL-idega. Vaikimisi on värskelt installitud FusionPBX-l kaks ACL-i:

domeenide vaiketoiming: deny – see leht on seotud siseprofiiliga
LAN vaiketoiming: luba

Domeenide ACL-i loendis kirjutame ette võrgu (noh, näiteks 192.168.0.0/24), teeme sellele võrgule lubamise loa, kasutame reloadacli.

Järgmiseks registreerime sellest võrgust telefoni ja kõik tundub korras olevat ja vastavalt juhistele ja loogiliselt.
Hakkame testima, helistame välisnumbrile ja ... saame sõõriku, õigemini sõõrikuaugu. Järsku!

Alustame logi analüüsimist konsoolis või logivaaturi FusioPBX kaudu.

Näeme oma väljakutset:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

Näeme ACL-i, mis töötas:

sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.

Ja edasi:

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] 

Marsruuti pole! Kuigi marsruudi oleme ausalt registreerinud.

Vastus on tõesti lihtne.

Kõne on tulnud. ACL jättis selle vahele. Ja kuna ACL on seotud sisemise profiiliga ja see profiil on avalikus kontekstis, vaatab FreeSWITCH ausalt marsruutimist avalikus kontekstis. Aga avalikus kontekstis ainult sissetuleva suuna marsruutimine ja süsteem ütleb meile ausalt, et sinna linna marsruute ei ole.

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

  1. Kinnitage see ACL mitte profiilile, vaid sisenumbrile endale. See võib olla kõige õigem lahendus, sest. Täpsemaks häälestamiseks on parem siduda ACL laiendusele võimalikult lähedale. Need. saate määrata telefonile konkreetse aadressi / võrguaadressi, millelt see saab helistada. Selle valiku puuduseks on see, et iga laiendus peab seda tegema.
  2. Parandage ACL nii, et see töötaks õigesti profiili tasemel. Valisin selle variandi, kuna mulle tundus lihtsam üks kord ACL-i võrk lisada kui igas laienduses ette kirjutada. Kuid see on spetsiaalselt minu ülesande jaoks. Teiste ülesannete puhul võib teil vaja minna teistsugust otsustusloogikat.

Niisiis. Parandame ACL-i domeenid järgmiselt:

domeenide vaiketoiming: luba

Domeenide ACL-i loendis registreerime võrgu:

eitada 192.168.0.0/24

Rakenda, laadige uuesti.
Testime: valime uuesti numbri 98343379xxxx ja ... kontrollpunkt tuleb ... TERE. Kõik töötab.
Vaatame, mis FreeSWITCHis juhtus:
kõne algab:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

ACL ei jätnud vahele:

[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 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 

Marsruutimine on möödas ja siis tuleb ühenduse loomine, mis jääb teemast välja.

Kui muudame ACL-is võrguaadressi, aga saame pildi esimesest testist, s.t. ACL jätab kõne vahele ja marsruutimine ütleb NO_ROUTE_DESTINATION.

See on ilmselt kõik, mida tahtsin ACL FusionPBX-ile lisada.

Loodan, et see on kellelegi kasulik.

Allikas: www.habr.com

Lisa kommentaar