Můj článek není úplným popisem produktu, ale pouze mírným upřesněním dobré publikace "FusionPBX, aneb opět skvělé, FreeSWITCH". Zdá se mi, že téma ACL ve FusionPBX v něm není příliš dobře popsáno. Pokusím se tuto mezeru vyplnit na základě vlastní zkušenosti s FreeSWITCH/FusionPBX.
A tak máme nainstalovanou FusionPBX s registrovaným interním číslem 1010 v doméně domain.local a nakonfigurovanou trasu pro externí hovory do města. ACL používáme k zabezpečení našeho telefonního systému před neoprávněnými hovory, které nám vezmou peníze. Tito. pouze ze sítí popsaných v ACL umožňují odchozí hovory. A zde potřebujete zcela jasně porozumět tomu, jak ACL funguje ve FusionPBX, jeho funkcím, logice a kotevnímu bodu.
Stejně jako respektovaný autor výše uvedeného článku jsem také šlápl na všechny hrábě související s ACL.
Začnu SipProfiles.
Oba profily (budu je tak nazývat), interní i externí, jsou v kontextu Public, a to není náhodné. Registrace čísel probíhá v interním profilu a budeme se jí věnovat. V interním profilu jsou domény ACL svázány jako apply-inbound-acl. Právě tato linka je zodpovědná za provoz ACL na úrovni profilu. Zatím je to s profily.
Kontext
Kontext se používá mimo jiné při směrování hovorů. Všechny příchozí cesty jsou vázány na veřejný kontext.
Odchozí (do města, na mobilní, meziměstské, mezinárodní a jakékoli jiné) trasy jsou (ve výchozím nastavení) v kontextu názvu domény (říkejme tomu doména.místní).
ACL
Nyní se pojďme zabývat ACL. Ve výchozím nastavení má čerstvě nainstalovaná FusionPBX dva ACL:
domény výchozí akce: zakázat - tento list je vázán na interní profil
lan výchozí akce: povolit
V seznamu domén ACL předepíšeme síť (dobře například 192.168.0.0/24), uděláme povolení povolení pro tuto síť, použijeme reloadacl.
Dále registrujeme telefon z této sítě a vše se zdá být v pořádku a podle návodu a logicky.
Začneme testovat, zavoláme na externí číslo a ... dostaneme koblihu, nebo spíše dírku na koblihu. Najednou!
Začneme analyzovat protokol v konzole nebo prostřednictvím prohlížeče protokolů FusioPBX.
Vidíme naši výzvu:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Vidíme ACL, které fungovalo:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.A dále:
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] Žádná trasa! I když trasu máme poctivě registrovanou.
Odpověď je opravdu jednoduchá.
Přišel hovor. ACL to minul. A protože ACL je vázáno v interním profilu a tento profil je ve veřejném kontextu, FreeSWITCH se upřímně dívá na směrování ve veřejném kontextu. Ale ve veřejném kontextu pouze příchozí směrování a systém nám upřímně říká, že tam žádné cesty do města nevedou.
Z této situace existují minimálně dvě cesty.
- Tento ACL nepřipojujte k profilu, ale k samotnému internímu číslu. To může být nejsprávnější způsob řešení, protože. Pro jemnější ladění je lepší svázat ACL co nejblíže k Extension. Tito. můžete mu předepsat konkrétní adresu / síťovou adresu telefonu, ze kterého může uskutečňovat odchozí hovor. Nevýhodou této možnosti je, že to bude muset udělat každé rozšíření.
- Opravte ACL tak, aby fungoval správně na úrovni profilu. Zvolil jsem tuto možnost, protože se mi zdálo jednodušší přidat síť do ACL jednou, než ji předepisovat v každém rozšíření. Ale to je speciálně pro můj úkol. Pro jiné úkoly možná budete potřebovat jinou logiku rozhodování.
Tak. Opravme domény ACL následovně:
domény výchozí akce: povolit
V seznamu ACL domén registrujeme síť:
zamítnout 192.168.0.0/24
Použít, znovu načíst.
Testujeme: znovu vytočíme číslo 98343379xxxx a ... kontrolní bod se blíží ... AHOJ. Všechno funguje.
Podívejme se, co se stalo ve FreeSWITCH:
hovor začíná:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL si nenechalo ujít:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.a dále:
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 Směrování prošlo a pak přichází navázání spojení, což je nad rámec tématu.
Pokud změníme síťovou adresu v ACL, ale dostaneme obrázek z prvního testu, tzn. ACL přeskočí hovor a směrování řekne NO_ROUTE_DESTINATION.
To je asi vše, co jsem chtěl k ACL FusionPBX přidat.
Doufám, že to bude pro někoho užitečné.
Zdroj: www.habr.com