Moj članek ni popoln opis izdelka, ampak le majhno pojasnilo dobre publikacije "FusionPBX ali spet odlično, FreeSWITCH." Zdi se mi, da je tema ACL v FusionPBX premalo pokrita. To vrzel bom poskušal zapolniti na podlagi lastnih izkušenj s FreeSWITCH/FusionPBX.
In tako imamo nameščeno FusionPBX z registrirano interno številko 1010 v domeni domain.local in konfigurirano pot za zunanje klice v mesto. ACL uporabljamo za zaščito našega telefonskega sistema pred nepooblaščenimi klici, ki bodo ukradli naš denar. Tisti. Dovoli odhodne klice samo iz omrežij, opisanih v ACL. In tukaj potrebujete popolnoma jasno razumevanje, kako ACL deluje v FusionPBX, njegovih funkcij, logike in njegove vezivne točke.
Tako kot spoštovani avtor zgornjega članka sem tudi jaz stopil na vse napake, povezane z ACL.
Začel bom z SipProfiles.
Oba profila (tako ju bom imenoval), notranji in zunanji, sta v javnem kontekstu in to ni naključje. Številke so registrirane v internem profilu, zato bomo na to pozorni. V notranjem profilu so domene seznama ACL vezane kot apply-inbound-acl. Ta vrstica je odgovorna za delovanje ACL na ravni profila. To je zaenkrat vse s profili.
Ozadje
Kontekst se med drugim uporablja pri usmerjanju klicev. Vse dohodne poti so vezane na javni kontekst.
Odhodne (v mesto, na mobilne telefone, medkrajevne, mednarodne in katere koli druge) poti so (privzeto) v kontekstu imena domene (recimo mu domain.local).
ACL
Zdaj pa poglejmo ACL-je. Privzeto ima na novo nameščena centrala FusionPBX dva ACL-ja:
domene privzeto dejanje: zavrni - ta list je vezan na notranji profil
lan privzeto dejanje: dovoli
Registriramo omrežje na seznamu domen ACL (no, na primer 192.168.0.0/24), damo dovoljenje za dovoljenje za to omrežje, uporabimo reloadacl.
Nato registriramo telefon iz tega omrežja in zdi se, da je vse v redu, tako po navodilih kot logično.
Začnemo s testiranjem, pokličemo na zunanjo številko in ... dobimo krof oziroma luknjo za krof. Nenadoma!
Začnemo analizirati dnevnik v konzoli ali prek Log Viewer FusioPBX.
Vidimo svoj izziv:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Vidimo sproženi ACL:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.In nadalje:
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] Brez poti! Čeprav je naša pot pošteno zapisana.
Odgovor je pravzaprav preprost.
Klic je prišel. ACL je zgrešil. In ker je ACL vezan na notranji profil in je ta profil v javnem kontekstu, FreeSWITCH pošteno gleda na usmerjanje v javnem kontekstu. Toda v javnem kontekstu obstaja samo dohodno usmerjanje, sistem pa nam pošteno pove, da poti do mesta ni.
Iz te situacije sta vsaj dva izhoda.
- Tega ACL ne pritrdite na profil, ampak na samo interno številko. To je morda najbolj pravilna rešitev, saj... Bolje je, da ACL povežete čim bližje razširitvi za natančnejšo nastavitev. Tisti. Registrirate lahko določen naslov/omrežni naslov telefona, s katerega lahko opravlja odhodne klice. Pomanjkljivost te možnosti je, da bo morala to storiti vsaka razširitev.
- Popravite ACL, da bo pravilno deloval na ravni profila. To možnost sem izbral, ker se mi je zdelo enostavnejše dodajanje omrežja v ACL kot registracija v vsaki razširitvi. Ampak to je posebej za mojo nalogo. Za druge naloge bo morda potrebna drugačna logika odločanja.
torej. Popravimo domene ACL na naslednji način:
privzeto dejanje domene: dovoli
Omrežje registriramo na seznamu ACL domen:
zavrni 192.168.0.0/24
Prijavimo se, ponovno naložimo.
Testirajmo: ponovno zavrti številko 98343379xxxx in... je kontrolna točka... POZDRAVLJENI. Vse dela.
Poglejmo, kaj se je zgodilo v FreeSWITCH:
klic se začne:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL ni bil spregledan:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.in še:
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 Usmerjanje je končano, nato pa je vzpostavljena povezava, kar je izven obsega teme.
Če spremenimo omrežni naslov v ACL, vendar dobimo sliko iz prvega testiranja, tj. ACL bo zgrešil klic in usmerjanje bo reklo NO_ROUTE_DESTINATION.
To je verjetno vse, kar sem želel dodati na ACL FusionPBX.
Upam, da bo komu koristilo.
Vir: www.habr.com