Min artikel er ikke en fuldstændig beskrivelse af produktet, men kun en lille forfining af den gode publikation "FusionPBX, eller igen-fantastisk, FreeSWITCH". Det forekommer mig, at emnet ACL i FusionPBX ikke er særlig godt beskrevet i det. Jeg vil forsøge at udfylde dette hul baseret på min egen erfaring med FreeSWITCH/FusionPBX.
Og så har vi en installeret FusionPBX med et registreret internt nummer 1010 i domænet domain.local og en konfigureret rute for eksterne opkald til byen. Vi bruger ACL til at sikre vores telefonisystem mod uautoriserede opkald, der vil tage vores penge fra os. De der. kun fra netværkene beskrevet i ACL tillader udgående opkald. Og her har du brug for en helt klar forståelse af, hvordan ACL fungerer i FusionPBX, dens funktioner, logik og dens ankerpunkt.
Ligesom den respekterede forfatter til ovenstående artikel, trådte jeg også på alle rakes relateret til ACL.
Jeg starter med SipProfiler.
Begge profiler (det vil jeg kalde dem), både interne og eksterne, er i den offentlige sammenhæng, og det er ikke tilfældigt. Registrering af numre foregår i den interne profil, og det vil vi være opmærksomme på. I den interne profil er domænerne ACL bundet som anvende-indgående-acl. Det er denne linje, der er ansvarlig for driften af ACL på profilniveau. Indtil videre er det det med profilerne.
Kontekst
Kontekst bruges blandt andet ved opkaldsdirigering. Alle indgående ruter er bundet til den offentlige kontekst.
Udgående (til byen, til mobil, langdistance, international og andre) ruter er (som standard) i sammenhæng med et domænenavn (lad os kalde det domain.local).
ACL
Lad os nu beskæftige os med ACL'er. Som standard har en nyinstalleret FusionPBX to ACL'er:
domæner standardhandling: afvis - dette ark er bundet til den interne profil
lan standardhandling: tillade
I domænernes ACL-liste foreskriver vi netværket (nå, for eksempel 192.168.0.0/24), vi giver tillade tilladelse til dette netværk, vi bruger reloadacl.
Dernæst registrerer vi en telefon fra dette netværk, og alt ser ud til at være i orden og i henhold til instruktionerne og logisk.
Vi begynder at teste, ringer til et eksternt nummer og ... vi får en donut, eller rettere sagt et donuthul. Pludselig!
Vi begynder at analysere loggen i konsollen eller gennem Log Viewer FusioPBX.
Vi ser vores udfordring:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Vi ser ACL, der virkede:
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! Selvom ruten har vi ærligt registreret.
Svaret er virkelig enkelt.
Kaldet er kommet. ACL savnede det. Og da ACL er bundet i den interne profil, og denne profil er i den offentlige kontekst, ser FreeSWITCH ærligt på routing i den offentlige sammenhæng. Men i offentlig sammenhæng kun indgående routing, og systemet fortæller os ærligt, at der ikke er ruter til byen der.
Der er mindst to veje ud af denne situation.
- Vedhæft denne ACL ikke til profilen, men til selve det interne nummer. Dette kan være den mest korrekte måde at løse, fordi. Det er bedre at binde ACL så tæt som muligt på Extension for at få en finjustering. De der. du kan angive en specifik adresse/netværksadresse på telefonen, hvorfra den kan foretage et udgående opkald. Ulempen ved denne mulighed er, at hver udvidelse skal gøre dette.
- Fastgør ACL, så den fungerer korrekt på profilniveau. Jeg valgte denne mulighed, fordi det forekom mig nemmere at tilføje netværket til ACL én gang end at ordinere det i hver udvidelse. Men dette er specifikt til min opgave. Til andre opgaver kan du have brug for en anden beslutningslogik.
Så. Lad os rette ACL-domænerne som følger:
domæner standardhandling: tillade
I domænernes ACL-liste registrerer vi netværket:
benægte 192.168.0.0/24
Anvend, genindlæsacl.
Vi tester: vi ringer til nummeret 98343379xxxx igen og ... checkpointet kommer ... HEJ. Alt fungerer.
Lad os se, hvad der skete i FreeSWITCH:
opkaldet starter:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL gik ikke glip af:
[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 Routing er bestået, og så kommer forbindelsesetableringen, som ligger uden for emnets rammer.
Hvis vi ændrer netværksadressen i ACL, men får billedet fra den første test, dvs. ACL'en springer opkaldet over, og routingen vil sige NO_ROUTE_DESTINATION.
Det er nok alt, jeg ville tilføje på ACL FusionPBX.
Jeg håber, det vil være nyttigt for nogen.
Kilde: www.habr.com