Artikkelen min er ikke en fullstendig beskrivelse av produktet, men kun en liten foredling av den gode publikasjonen "FusionPBX, eller igjen-great, FreeSWITCH". Det virker for meg som om emnet ACL i FusionPBX ikke er veldig godt beskrevet i det. Jeg vil prøve å fylle dette gapet basert på min egen erfaring med FreeSWITCH/FusionPBX.
Og så har vi en installert FusionPBX med et registrert internt nummer 1010 i domain.local-domenet og en konfigurert rute for eksterne anrop til byen. Vi bruker ACL for å sikre telefonisystemet vårt mot uautoriserte anrop som vil ta bort pengene våre. De. bare fra nettverkene beskrevet i ACL tillate utgående anrop. Og her trenger du en helt klar forståelse av hvordan ACL fungerer i FusionPBX, dens funksjoner, logikk og ankerpunkt.
I likhet med den respekterte forfatteren av artikkelen ovenfor, tråkket jeg også på alle rakene relatert til ACL.
Jeg begynner med SipProfiles.
Begge profilene (jeg vil kalle dem det), både interne og eksterne, er i offentlig kontekst, og dette er ikke tilfeldig. Registrering av nummer skjer i den interne profilen, og vi vil ta hensyn til den. I den interne profilen er domenene ACL bundet som anvende-inngående-acl. Det er denne linjen som er ansvarlig for driften av ACL på profilnivå. Så langt er det det med profilene.
Kontekst
Kontekst brukes blant annet i samtalerouting. Alle innkommende ruter er bundet til den offentlige konteksten.
Utgående (til byen, til mobilnettet, langdistanse, internasjonalt og andre) ruter er (som standard) i sammenheng med et domenenavn (la oss kalle det domain.local).
ACL
La oss nå forholde oss til ACL. Som standard har en nyinstallert FusionPBX to tilgangskontrollister:
domener standard handling: nekte - dette arket er bundet til den interne profilen
lan standard handling: tillat
I ACL-listen for domener foreskriver vi nettverket (vel, for eksempel 192.168.0.0/24), vi gir tillatelse for dette nettverket, vi bruker reloadacl.
Deretter registrerer vi en telefon fra dette nettverket, og alt ser ut til å være i orden og i henhold til instruksjonene og logisk.
Vi begynner å teste, ringer til et eksternt nummer og ... vi får en smultring, eller rettere sagt et smultringhull. Plutselig!
Vi begynner å analysere loggen i konsollen eller gjennom Log Viewer FusioPBX.
Vi ser utfordringen vår:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Vi ser ACL som fungerte:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.Og videre:
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] Ingen rute! Selv om ruten har vi ærlig talt registrert.
Svaret er veldig enkelt.
Oppfordringen har kommet. ACL savnet det. Og siden ACL er bundet i den interne profilen, og denne profilen er i offentlig kontekst, ser FreeSWITCH ærlig på ruting i offentlig kontekst. Men i offentlig sammenheng er det kun innkommende ruting, og systemet forteller oss ærlig at det ikke er ruter til byen der.
Det er minst to veier ut av denne situasjonen.
- Fest denne ACL ikke til profilen, men til selve det interne nummeret. Dette kan være den mest korrekte måten å løse, fordi. Det er bedre å binde ACL så nært som mulig til Extension for finjustering. De. du kan angi en spesifikk adresse/nettverksadresse til telefonen som den kan foreta et utgående anrop fra. Ulempen med dette alternativet er at hver utvidelse må gjøre dette.
- Fest ACL slik at den fungerer riktig på profilnivå. Jeg valgte dette alternativet, fordi det virket lettere for meg å legge nettverket til ACL én gang enn å foreskrive det i hver utvidelse. Men dette er spesielt for min oppgave. For andre oppgaver kan det hende du trenger en annen beslutningslogikk.
Så. La oss fikse ACL-domenene som følger:
domener standard handling: tillat
I domener ACL-listen registrerer vi nettverket:
nekte 192.168.0.0/24
Apply, reloadacl.
Vi tester: vi ringer nummeret 98343379xxxx igjen og ... sjekkpunktet kommer ... HEI. Alt fungerer.
La oss se hva som skjedde i FreeSWITCH:
samtalen starter:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL gikk ikke glipp av:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.og videre:
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 Ruting er passert, og så kommer forbindelsesetableringen, som ligger utenfor temaet.
Hvis vi endrer nettverksadressen i ACL, men får bildet fra den første testen, dvs. ACL vil hoppe over samtalen og rutingen vil si NO_ROUTE_DESTINATION.
Det er sannsynligvis alt jeg ønsket å legge til på ACL FusionPBX.
Jeg håper det vil være nyttig for noen.
Kilde: www.habr.com