🥇FusionPBX og ACL

Min artikel er ikke en fuldstændig beskrivelse af produktet, men kun en lille præcisering af den gode udgivelse "FusionPBX, eller igen, FreeSWITCH". Jeg tror ikke, det dækker emnet ACL i FusionPBX særlig godt. Jeg vil forsøge at udfylde dette hul baseret på min egen erfaring med FreeSWITCH/FusionPBX.

Så vi har 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 beskytte vores telefonsystem mod uautoriserede opkald, der vil stjæle vores penge. Dem. Tillad kun udgående opkald fra de netværk, der er beskrevet i ACL. Og her har du brug for en fuldstændig klar forståelse af, hvordan ACL fungerer i FusionPBX, dens funktioner, logik og dens tilknytningspunkt.

Ligesom den respekterede forfatter til ovenstående artikel, har jeg også trådt på alle de rakes, der er forbundet med 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. Denne linje er ansvarlig for driften af ACL på profilniveau. Det var alt for nu med profilerne.

Kontekst

Kontekst bruges blandt andet ved opkaldsdirigering. Alle indgående ruter er bundet til den offentlige kontekst.

Udgående ruter (til byen, til mobiltelefoner, langdistance, international og alle andre) er (som standard) placeret i navnets kontekst. domæne (lad os kalde det domain.local).

ACL

Lad os nu beskæftige os med ACL. Som standard har en nyinstalleret FusionPBX to ACL'er:

domæner standardhandling: afvis - dette ark er knyttet til den interne profil
lan standardhandling: tillade

I ACL-listens domæner skriver vi netværket (for eksempel 192.168.0.0/24), giver dette netværk tillad tilladelsen og bruger reloadacl.

Dernæst registrerer vi telefonen 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... får en doughnut, eller rettere et hul fra en doughnut. Pludselig!

Vi begynder at analysere loggen i konsollen eller gennem FusioPBX Log Viewer.

Vi ser vores udfordring:

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

Vi ser den udløste ACL:

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/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Ingen rute! Selvom vores rute er tydeligt skrevet ned.

Svaret er faktisk enkelt.

Kaldet er kommet. ACL savnede det. Og da ACL er bundet til den interne profil, og denne profil er i den offentlige kontekst, ser FreeSWITCH ærligt på routingen i den offentlige kontekst. Men i offentlig sammenhæng er der kun indgående routing, og systemet fortæller os ærligt, at der ikke er ruter til byen.

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 problemet på, fordi det er bedre at binde ACL så tæt på Extension som muligt for mere finkornet tilpasning. Dem. Du kan angive en specifik adresse/netværksadresse på telefonen, hvorfra den kan foretage et udgående opkald. Ulempen ved denne mulighed er, at du bliver nødt til at gøre dette i hver udvidelse.
Fastgør ACL, så den fungerer korrekt på profilniveau. Jeg valgte denne mulighed, fordi det syntes lettere at tilføje netværket til ACL én gang end at registrere det i hver udvidelse. Men dette er specifikt til min opgave. Andre opgaver kan kræve anden beslutningslogik.

Så. Lad os rette ACL-domænerne som følger:

domæner standardhandling: tillade

I ACL-listens domæner angiver vi netværket:

benægte 192.168.0.0/24

Vi anvender reloadacl.
Lad os teste: tast nummeret 98343379хххх igen, og... klartone kommer... HEJ. Alt virker.
Lad os se, hvad der skete i FreeSWITCH:
opkaldet begynder:

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

ACL bestod ikke:

[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/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]d{6})$/ break=on-false

Routing har fundet sted, og nu oprettes forbindelsen, hvilket ligger uden for dette emnes rammer.

Hvis vi ændrer netværksadressen i ACL, men får billedet fra den første test, dvs. ACL-kaldet vil passere, og routing vil sige NO_ROUTE_DESTINATION.

Det var nok det eneste, jeg ville tilføje om ACL FusionPBX.

Jeg håber, at dette vil være nyttigt for nogen.

Kilde: www.habr.com