Cikkem nem a termék teljes leírása, hanem csak a "FusionPBX, avagy ismét nagyszerű, FreeSWITCH" című jó kiadvány enyhe finomítása. Nekem úgy tűnik, hogy az ACL témája a FusionPBX-ben nem nagyon van benne. Ezt a hiányt megpróbálom pótolni a FreeSWITCH/FusionPBX-el kapcsolatos saját tapasztalataim alapján.
Így van egy telepített Fusion PBX-ünk 1010-es regisztrált belső számmal a domain.local tartományban, és egy konfigurált útvonallal a városba irányuló külső hívásokhoz. Az ACL-t használjuk, hogy megvédjük telefonrendszerünket a jogosulatlan hívásoktól, amelyek elveszik a pénzünket. Azok. csak az ACL-ben leírt hálózatokról engedélyezi a kimenő hívásokat. És itt teljesen világosan meg kell értenie az ACL működését a Fusion PBX-ben, annak jellemzőit, logikáját és rögzítési pontját.
A fenti cikk tisztelt szerzőjéhez hasonlóan én is ráléptem az ACL-lel kapcsolatos összes gereblyére.
azzal kezdem SipProfiles.
Mindkét profil (ennek nevezem őket), mind a belső, mind a külső, nyilvános kontextusban van, és ez nem véletlen. A számok regisztrációja a belső profilban történik, erre odafigyelünk. A belső profilban a tartományok ACL-je alkalmaz-bejövő-acl-ként van kötve. Ez a vonal felelős az ACL profilszintű működéséért. Eddig ennyi volt a profilokkal.
Kontextus
A kontextust többek között a hívásirányításban használják. Minden bejövő útvonal a nyilvános kontextushoz van kötve.
A kimenő (városba, mobilhálózatba, távolsági, nemzetközi és bármilyen más) útvonalak (alapértelmezés szerint) egy domain név kontextusában vannak (nevezzük domain.local).
ACL
Most foglalkozzunk az ACL-ekkel. Alapértelmezés szerint egy frissen telepített Fusion PBX két ACL-lel rendelkezik:
tartományok alapértelmezett művelete: deny - ez a lap a belső profilhoz van kötve
lan alapértelmezett művelet: engedélyezés
A domain ACL listában előírjuk a hálózatot (hát pl. 192.168.0.0/24), erre a hálózatra megadjuk az engedélyezési engedélyt, reloadacl-t használunk.
Ezután regisztrálunk egy telefont erről a hálózatról, és úgy tűnik, hogy minden rendben van, az utasításoknak megfelelően és logikusan.
Elkezdjük a tesztelést, felhívunk egy külső számot és ... kapunk egy fánkot, vagy inkább egy fánklyukat. Hirtelen!
Elkezdjük elemezni a naplót a konzolon vagy a Log Viewer FusioPBX-en keresztül.
Látjuk a kihívásunkat:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Látjuk az ACL-t, amely működött:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.És tovább:
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] Nincs útvonal! Bár az útvonalat őszintén regisztráltuk.
A válasz nagyon egyszerű.
Megjött a hívás. Az ACL kihagyta. És mivel az ACL a belső profilhoz van kötve, és ez a profil nyilvános, a FreeSWITCH őszintén nézi az útválasztást a nyilvános kontextusban. De nyilvánosan csak a bejövő routing, és a rendszer őszintén megmondja, hogy ott nincsenek útvonalak a városba.
Ebből a helyzetből legalább két kiút van.
- Ezt az ACL-t ne a profilhoz csatolja, hanem magához a belső számhoz. Ez lehet a leghelyesebb megoldás a megoldásra, mert. A finomabb hangolás érdekében jobb, ha az ACL-t a lehető legközelebb köti az Extension-hez. Azok. előírhat egy konkrét címet/hálózati címet a telefonnak, amelyről kimenő hívást kezdeményezhet. Ennek az opciónak az a hátránya, hogy ezt minden bővítménynek meg kell tennie.
- Javítsa ki az ACL-t úgy, hogy az megfelelően működjön a profil szintjén. Azért választottam ezt a lehetőséget, mert egyszerűbbnek tűnt egyszer hozzáadni a hálózatot az ACL-hez, mint minden bővítményben előírni. De ez kifejezetten az én feladatomra vonatkozik. Más feladatokhoz más döntési logikára lehet szükség.
Így. Javítsuk ki az ACL tartományokat a következőképpen:
domain alapértelmezett művelete: engedélyezés
A domain ACL listában regisztráljuk a hálózatot:
tagadás 192.168.0.0/24
Jelentkezés, újratöltés.
Tesztelünk: újra tárcsázzuk a 98343379xxxx számot és ... jön az ellenőrző pont... HELLO. Minden működik.
Lássuk, mi történt a FreeSWITCH-ben:
hívás indul:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Az ACL nem hagyta ki:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.és tovább:
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 Elmúlt az útválasztás, majd jön a kapcsolatépítés, ami túlmutat a téma keretein.
Ha az ACL-ben megváltoztatjuk a hálózati címet, de az első tesztből megkapjuk a képet, pl. Az ACL kihagyja a hívást, és az útválasztás a NO_ROUTE_DESTINATION feliratot jelzi.
Valószínűleg ennyit akartam hozzátenni az ACL Fusion PBX-hez.
Remélem hasznos lesz valakinek.
Forrás: will.com