Artikkelini ei ole täydellinen kuvaus tuotteesta, vaan vain hieno jalostus hyvään julkaisuun "FusionPBX, or again-great, FreeSWITCH". Minusta näyttää siltä, että FusionPBX:n ACL-aihe ei ole siinä kovin hyvin esitelty. Yritän täyttää tämän aukon omien kokemusteni perusteella FreeSWITCH/FusionPBX:stä.
Ja niin, meillä on asennettu FusionPBX, jonka rekisteröity sisäinen numero 1010 domain.local-verkkotunnuksessa ja määritetty reitti ulkopuheluille kaupunkiin. Käytämme ACL:ää suojataksemme puhelinjärjestelmämme luvattomilta puheluilta, jotka vievät rahamme. Nuo. vain ACL:ssä kuvatuista verkoista sallivat lähtevät puhelut. Ja tässä tarvitaan täysin selkeä käsitys siitä, miten ACL toimii FusionPBX:ssä, sen ominaisuuksista, logiikasta ja sen ankkuripisteestä.
Kuten yllä olevan artikkelin arvostettu kirjoittaja, minäkin astuin kaikkien ACL:ään liittyvien rakeiden päälle.
Aloitan SipProfiilit.
Molemmat profiilit (kutsun niitä niin), sekä sisäiset että ulkoiset, ovat julkisessa kontekstissa, eikä tämä ole sattumaa. Numeroiden rekisteröinti tapahtuu sisäisessä profiilissa ja kiinnitämme siihen huomiota. Sisäisessä profiilissa toimialueiden ACL on sidottu soveltamis-saapuva-acl-muodossa. Tämä rivi on vastuussa ACL:n toiminnasta profiilitasolla. Toistaiseksi se on profiilien kanssa.
Tausta
Kontekstia käytetään muun muassa puhelun reitityksessä. Kaikki saapuvat reitit on sidottu julkiseen kontekstiin.
Lähtevät (kaupunkiin, matkapuhelinverkkoon, kauko-, kansainväliseen ja mihin tahansa muuhun) reitit ovat (oletusarvoisesti) verkkotunnuksen (kutsutaanko sitä domain.local) yhteydessä.
ACL
Käsitellään nyt ACL:itä. Oletuksena juuri asennetussa FusionPBX:ssä on kaksi ACL-luetteloa:
domains default action: deny - tämä taulukko on sidottu sisäiseen profiiliin
lan oletustoiminto: salli
Domains ACL -listassa määritämme verkon (no esim. 192.168.0.0/24), teemme tälle verkolle sallimisluvan, käytämme reloadaclia.
Seuraavaksi rekisteröimme puhelimen tästä verkosta ja kaikki näyttää olevan kunnossa ja ohjeiden mukaan ja loogisesti.
Aloitamme testaamisen, soitamme ulkoiseen numeroon ja ... saamme donitsin, tai pikemminkin donitsireiän. Yhtäkkiä!
Aloitamme lokin analysoinnin konsolissa tai Log Viewer FusioPBX:n kautta.
Näemme haasteemme:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Näemme toimineen ACL:n:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.Ja edelleen:
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] Ei reittiä! Vaikka reitin olemme rehellisesti rekisteröityneet.
Vastaus on todella yksinkertainen.
Kutsu on tullut. ACL missasi sen. Ja koska ACL on sidottu sisäiseen profiiliin ja tämä profiili on julkisessa kontekstissa, FreeSWITCH tarkastelee rehellisesti reititystä julkisessa kontekstissa. Mutta julkisessa kontekstissa vain saapuvat reititys, ja järjestelmä kertoo meille rehellisesti, että sinne ei ole reittejä kaupunkiin.
Tästä tilanteesta on ainakin kaksi ulospääsyä.
- Älä liitä tätä ACL-luetteloa profiiliin, vaan itse sisäiseen numeroon. Tämä saattaa olla oikea tapa ratkaista, koska. On parempi sitoa ACL mahdollisimman lähelle Extensionia hienosäätöä varten. Nuo. voit määrittää puhelimelle tietyn osoitteen/verkko-osoitteen, josta se voi soittaa lähtevän puhelun. Tämän vaihtoehdon haittana on, että jokaisen laajennuksen on tehtävä tämä.
- Korjaa ACL niin, että se toimii oikein profiilitasolla. Valitsin tämän vaihtoehdon, koska minusta tuntui helpommalta lisätä verkko ACL:ään kerran kuin määrätä se jokaiseen laajennukseen. Mutta tämä on nimenomaan minun tehtävääni. Muissa tehtävissä saatat tarvita erilaista päätöksentekologiikkaa.
Niin. Korjataan ACL-verkkotunnukset seuraavasti:
verkkotunnusten oletustoiminto: salli
Verkkotunnusten ACL-luettelossa rekisteröimme verkon:
kieltää 192.168.0.0/24
Käytä, lataa uudelleen.
Testaamme: näppäilemme uudelleen numeroon 98343379xxxx ja ... tarkistuspiste on tulossa... HEI. Kaikki toimii.
Katsotaan mitä tapahtui FreeSWITCHissa:
puhelu alkaa:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL ei missannut:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.ja edelleen:
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 Reititys on ohi, ja sitten tulee yhteyden muodostaminen, mikä ei kuulu aiheen piiriin.
Jos muutamme verkko-osoitetta ACL:ssä, mutta saamme kuvan ensimmäisestä testistä, ts. ACL ohittaa puhelun ja reititys sanoo NO_ROUTE_DESTINATION.
Se on luultavasti kaikki, mitä halusin lisätä ACL FusionPBX:hen.
Toivottavasti siitä on jollekin hyötyä.
Lähde: will.com