🥇FusionPBX a ACL

Můj článek není úplným popisem produktu, ale pouze malým upřesněním dobrého publikování „FusionPBX, aneb znovu zdravé, FreeSWITCH“. Myslím, že téma ACL v FusionPBX není v něm dobře rozpracováno. Pokusím se vyplnit tuto mezeru na základě vlastních zkušeností s FreeSWITCH/FusionPBX.

Takže máme nainstalovaný FusionPBX se zaregistrovaným interním číslem 1010 v doméně domain.local a nastavenou trasou pro venkovní hovory do města. ACL používáme k zajištění našeho telefonního systému před neoprávněnými hovory, které by nám mohly vzít peníze. Tj. pouze z popsaných v ACL sítí povolit odchozí hovory. A zde je třeba naprosto jasné porozumění, jak funguje ACL v FusionPBX, jeho zvláštnosti, logika a bod jeho připojení.

Stejně jako vážený autor výše zmíněného článku jsem také narazil na všechny problémy spojené s ACL.

Začnu s SipProfiles.
Oba profily (budu je tak nazývat), jak internal, tak external, se nacházejí v kontextu Public, a to není náhoda. Registrace čísel probíhá v profilu internal, na něj se také zaměříme. V profilu internal je připojen ACL seznam domains jako apply-inbound-acl. Tento řádek je zodpovědný za fungování ACL na úrovni profilu. Zatím je vše ohledně profilů v pořádku.

Context

Kromě všeho ostatního se kontext používá v trasování hovorů. Všechny příchozí trasy jsou připojeny k kontextu Public.

Odchozí (do města, na mobilní, meziměstské, mezinárodní a jakékoli jiné) trasy se nacházejí (ve výchozím nastavení) v kontextu jména domény (nazvěme jej domain.local).

ACL

Teď se pojďme podívat na ACL. Ve výchozím nastavení má právě nainstalovaný FusionPBX dva ACL seznamy:

domains výchozí akce: deny — tento seznam je připojen k profilu internal
lan výchozí akce: allow

Do ACL seznamu domains zapisujeme síť (například 192.168.0.0/24), dáváme této síti povolení allow, aplikujeme reloadacl.

Dále registrujeme telefon z této sítě, a vypadá to, že je vše v pořádku podle instrukcí a logicky.
Začínáme testovat, provádíme hovor na venkovní číslo a… dostáváme kruh, přesněji díru od kruhu. Nečekaně!

Začínáme analyzovat log v konzoli nebo prostřednictvím Log Viewer FusionPBX.

Vidíme náš hovor:

switch_channel.c:1104 New Channel sofia/internal/1010@domain.local

Vidíme aktivovaný ACL:

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

A dále:

mod_dialplan_xml.c:637 Zpracovávám 1010 ->98343379xxxx v kontextu public
switch_core_state_machine.c:311 Žádná trasa, přerušení 
switch_core_state_machine.c:312 Ukončení sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Žádná trasa! I když jsme měli trasu pečlivě nastavenou.

Odpověď je ve skutečnosti jednoduchá.

Hovor přišel. ACL ho pustil. A protože je ACL připojen k profilu internal a tento profil se nachází v kontextu public, FreeSWITCH pečlivě kontroluje trasování v kontextu public. Ale v kontextu public je pouze příchozí trasování, a systém nám jasně říká, že tam žádné trasy do města nejsou.

Z nynější situace existují alespoň dva východy.

Připojit tento ACL ne k profilu, ale k samotnému vnitřnímu číslu. To může být i nejvhodnější způsob řešení, protože ACL je lepší připojit co nejblíže k Extension pro jemnější nastavení. Tedy lze zapsat konkrétní adresu/ adresu sítě telefonu, ze které bude mít možnost uskutečnit odchozí volání. Nevýhodou této varianty je to, že to bude nutné udělat v každém Extension.
Opravit ACL tak, aby fungoval správně na úrovni profilu. Vybral jsem tuto variantu, protože přidat jednou síť do ACL mi připadalo jednodušší, než ji zapisovat v každém Extension. Ale to je konkrétně pod můj úkol. Pro jiné úkoly může být potřeba jiná logika rozhodování.

A tak. Oprávníme ACL domains následujícím způsobem:

domains výchozí akce: povolit

Do ACL seznamu domains zapisujeme síť:

deny 192.168.0.0/24

Používáme, reloadacl.
Testujeme: znovu volíme číslo 98343379xxxx a… běží KPZ… HALÓ. Všechno funguje.
Podíváme se, co se stalo ve FreeSWITCH:
zahajuje se hovor:

switch_channel.c:1104 New Channel sofia/internal/1010@domain.local

ACL neprošel:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Odepřeno pomocí acl "domains". Vracíme se k Digest auth.

a dále:

mod_dialplan_xml.c:637 Zpracovávám 1010 ->98343379xxxx v kontextu domain.local
sofia/internal/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]d{6})$/ break=on-false

Trasování proběhlo, a dále probíhá spojení, které přesahuje rámec tématu.

Pokud změníme adresu sítě v ACL, ale dostaneme obrázek z prvního testování, tj. ACL hovor pustí a trasování řekne NO_ROUTE_DESTINATION.

To je pravděpodobně vše, co jsem chtěl dodat k ACL FusionPBX.

Doufám, že to někomu pomůže.

Zdroj: habr.com