🥇FusionPBX és ACL

A cikkem nem egy teljes körű termékismertető, csupán egy rövid pontosítás a jó publikációra, a «FusionPBX, vagy újra egészséges, FreeSWITCH»-re. Úgy érzem, a FusionPBX ACL témája nincs kellően kifejtve benne. Megpróbálom kitölteni ezt az űrt, a FreeSWITCH/FusionPBX-el kapcsolatos saját tapasztalataim alapján.

Tehát, van egy telepített FusionPBX-ünk, egy 1010-es belső számmal a domain.local tartományban, és beállítottuk a városi hívásokra vonatkozó útvonalat. Az ACL-t azért használjuk, hogy megvédjük telefonos rendszerünket a jogosulatlan hívásoktól, amelyek megcsapolhatják a pénzünket. Azaz, csak az ACL-ben leírt hálózatokból engedjük meg a kimenő hívásokat. Itt teljesen világos megértésre van szükség, hogy hogyan működik az ACL a FusionPBX-ben, annak sajátosságaira, logikájára és a megkötött pontjára vonatkozóan.

Ahogyan a fent említett cikk tisztelt szerzője, én is találkoztam minden ACL-el kapcsolatos buktatóval.

Kezdjük a SipProfiles.
Mindkét profil (én most így fogom hívni őket), internal és external a Public kontextusban van, és ez nem véletlen. A számok regisztrálása az internal profilban történik, amit figyelembe fogunk venni. Az internal profil az ACL-lista domains mappához van csatolva, mint apply-inbound-acl. Pontosan ez a sor felelős az ACL működéséért a profil szintjén. A profilokkal most álljunk meg.

Context

A kontextus, a többi mellett, a hívásroutolásban van használva. Minden bejövő útvonal a Public kontextushoz van kötve.

A kimenő (városi, mobil, távolsági, nemzetközi és minden egyéb) útvonalak (alapértelmezés szerint) a név kontextusában találhatók. domain (nevezhetjük domain.local-nak).

ACL

Most nézzük meg az ACL-t. Alapértelmezés szerint a frissen telepített FusionPBX-ben két ACL-lista van:

domains alapértelmezett művelet: deny — ez a lista az internal profilhoz van csatolva.
lan alapértelmezett művelet: allow.

Az ACL-listába domains beírjuk a hálózatot (például 192.168.0.0/24), ennek a hálózatnak engedélyezzük az allow-t, alkalmazzuk a reloadacl-t.

Ezután regisztrálunk egy telefont ebből a hálózatból, és úgy tűnik, minden rendben van az utasításokkal és logikával.
Kezdjük a tesztelést, hívunk egy külső számot, és… üresedést kapunk, pontosabban egy fánk lyukat. Meglepetés!

Kezdjük elemezni a logot a konzolon vagy a FusioPBX Log Viewer-en keresztül.

Látjuk hívásunkat:

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

Látjuk a működő ACL-t:

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

És ezután:

mod_dialplan_xml.c:637 Feldolgozás 1010 ->98343379xxxx nyilvános kontextusban
switch_core_state_machine.c:311 Nincs útvonal, megszakítás 
switch_core_state_machine.c:312 Hívás bontva: sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Nincs útvonal! Bár az útvonalat korrekt módon megadtuk.

A válasz valójában egyszerű.

A hívás bejött. Az ACL átengedte. Mivel az ACL a belső profilhoz van kötve, és ez a profil a nyilvános kontextusban található, a FreeSWITCH tisztán nézi az útvonalakat a nyilvános kontextusban. De a nyilvános kontextusban csak a bejövő útvonalak vannak, és a rendszer világosan jelzi nekünk, hogy nincsenek ott városi útvonalak.

A kialakult helyzetből legalább két megoldás létezik.

Az ACL-t nem a profilhoz, hanem magához a belső számhoz kellene kapcsolni. Ez lehet a legjobb megoldás, mivel az ACL-t minél közelebb kell kötni az Extensionhöz a finomabb beállítás érdekében. Tehát megadhatunk egy konkrét címet/hálózatot a telefonhoz, amiről kimenő hívást indíthat. Ennek a megoldásnak hátránya, hogy minden Extensionnél ezt meg kell tenni.
Az ACL-t úgy kellene módosítani, hogy korrekt módon működjön a profil szintjén. Én éppen ezt a megoldást választottam, mert egyszerűbbnek tűnt egy hálózatot egyszer hozzáadni az ACL-hez, mint minden egyes Extensionben beírni. De ez konkrétan az én feladatomra vonatkozik. Más feladatokhoz lehet, hogy más logika szükséges.

Tehát. Módosítjuk az ACL domains-t a következőképpen:

domains alapértelmezett művelete: allow

Az ACL-listán a domains-hez hozzáírjuk a hálózatot:

deny 192.168.0.0/24

Alkalmazzuk, reloadacl.
Teszteljük: újra hívjuk a 98343379xxxx számot, és… jön a KP… HALLO. Minden működik.
Nézzük meg, mi történt a FreeSWITCH-ben:
a hívás kezdődik:

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

Az ACL nem engedte át:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Elutasítva az acl "domains" által. Visszatér a Digest hitelesítéshez.

és tovább:

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

Az útvonal átment, ezután következik a kapcsolat létrehozása, ami már kívül esik a téma keretein.

Ha megváltoztatjuk a hálózat címét az ACL-ben, de ugyanazt a képet kapjuk, mint az első tesztelés során, azaz az ACL átengedi a hívást, és az útvonal NO_ROUTE_DESTINATION-t mond.

Talán ennyi volt, amit szerettem volna hozzátenni az ACL FusionPBX-hez.

Remélem, valakinek hasznos lesz.

Forrás: habr.com