Mia artikolo ne estas plena priskribo de la produkto, sed nur eta rafinado de la bona eldonaĵo "FusionPBX, aŭ denove bonega, FreeSWITCH". Ŝajnas al mi, ke la temo de ACL en FusionPBX ne estas tre bone diskonigita en ĝi. Mi provos plenigi ĉi tiun mankon surbaze de mia propra sperto kun FreeSWITCH/FusionPBX.
Kaj tiel, ni havas instalitan FusionPBX kun registrita interna numero 1010 en la domajno.loka domajno kaj agordita itinero por eksteraj vokoj al la urbo. Ni uzas ACL por sekurigi nian telefonan sistemon de neaŭtorizitaj vokoj, kiuj forprenos nian monon. Tiuj. nur de la retoj priskribitaj en la ACL permesas eksiĝintajn vokojn. Kaj ĉi tie vi bezonas tute klaran komprenon pri kiel ACL funkcias en FusionPBX, ĝiaj trajtoj, logiko kaj ĝia ankropunkto.
Kiel la respektata aŭtoro de la ĉi-supra artikolo, mi ankaŭ tretis ĉiujn rastilojn rilatajn al ACL.
Mi komencos per SipProfiles.
Ambaŭ profiloj (mi nomos ilin tiel), kaj internaj kaj eksteraj, estas en la Publika kunteksto, kaj tio ne estas hazarda. Registrado de numeroj okazas en la interna profilo, kaj ni atentos ĝin. En la interna profilo, la domajnoj ACL estas ligita kiel apply-inbound-acl. Estas ĉi tiu linio, kiu respondecas pri la funkciado de la ACL ĉe la profilnivelo. Ĝis nun, tio estas ĝi kun la profiloj.
kunteksto
Kunteksto estas uzata, interalie, en vokovojigo. Ĉiuj alvenantaj itineroj estas ligitaj al la Publika kunteksto.
Eksiĝintaj (al la urbo, al ĉela, longdistanca, internacia, kaj ajna alia) itineroj estas (defaŭlte) en la kunteksto de domajna nomo (ni nomu ĝin domajno.loka).
ACL
Nun ni traktu ACL-ojn. Defaŭlte, ĵus instalita FusionPBX havas du ACL-ojn:
defaŭlta ago de domajnoj: nei - ĉi tiu folio estas ligita al la interna profilo
lan default ago: permesi
En la listo de domajnoj ACL, ni preskribas la reton (nu, ekzemple, 192.168.0.0/24), ni faras la permeson por ĉi tiu reto, ni uzas reloadacl.
Poste, ni registras telefonon de ĉi tiu reto, kaj ĉio ŝajnas esti bona kaj laŭ la instrukcioj kaj logike.
Ni komencas testi, voki eksteran numeron kaj ... ni ricevas bengon, aŭ pli ĝuste benbultruon. Subite!
Ni komencas analizi la protokolon en la konzolo aŭ per la Log Viewer FusioPBX.
Ni vidas nian defion:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Ni vidas la ACL kiu funkciis:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.Kaj plu:
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] Neniu vojo! Kvankam la itinero ni honeste registris.
La respondo estas vere simpla.
La voko venis. ACL maltrafis ĝin. Kaj ĉar la ACL estas ligita en la interna profilo, kaj ĉi tiu profilo estas en la publika kunteksto, FreeSWITCH honeste rigardas vojigon en la publika kunteksto. Sed en la publika kunteksto, nur envenanta vojigo, kaj la sistemo honeste diras al ni, ke ne ekzistas vojoj al la urbo tie.
Estas almenaŭ du vojoj el ĉi tiu situacio.
- Aligu ĉi tiun ACL ne al la profilo, sed al la interna numero mem. Ĉi tio povas esti la plej ĝusta maniero solvi, ĉar. Estas pli bone ligi ACL kiel eble plej proksime al Extension por pli fajna agordado. Tiuj. vi povas preskribi specifan adreson/retan adreson de la telefono, de kiu ĝi povas fari eksiĝintan vokon. La malavantaĝo de ĉi tiu opcio estas, ke ĉiu Etendo devos fari tion.
- Ripari la ACL por ke ĝi funkciu ĝuste ĉe la profilnivelo. Mi elektis ĉi tiun opcion, ĉar ŝajnis al mi pli facile aldoni la reton al la ACL unufoje ol preskribi ĝin en ĉiu Etendo. Sed ĉi tio estas specife por mia tasko. Por aliaj taskoj, vi eble bezonos malsaman decidlogikon.
Do. Ni riparu la ACL-domajnojn jene:
domajnoj defaŭlta ago: permesi
En la listo de domajnoj ACL, ni registras la reton:
nei 192.168.0.0/24
Apply, reloadacl.
Ni testas: ni markas la numeron 98343379xxxx denove kaj ... la kontrolpunkto venas ... SALUTON. Ĉio funkcias.
Ni vidu kio okazis en FreeSWITCH:
voko komenciĝas:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL ne maltrafis:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.kaj plue:
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 Enrutado pasis, kaj tiam venas la konektoestablado, kiu estas preter la amplekso de la temo.
Se ni ŝanĝas la retadreson en la ACL, sed ricevas la bildon de la unua testo, t.e. La ACL preterlasos la vokon kaj la vojigo diros NO_ROUTE_DESTINATION.
Tio verŝajne estas ĉio, kion mi volis aldoni sur ACL FusionPBX.
Mi esperas, ke ĝi estos utila al iu.
fonto: www.habr.com