🥇FusionPBX og ACL

Min artikel er ikke en fuldstændig beskrivelse af produktet, men kun en lille præcisering af en god publikation "FusionPBX, eller igen sundt fornuft, FreeSWITCH". Jeg synes, at emnet ACL i FusionPBX ikke er meget godt dækket i den. Jeg vil forsøge at udfylde dette hul baseret på min egen erfaring med FreeSWITCH/FusionPBX.

Så vi har FusionPBX installeret med et registreret internt nummer 1010 i domænet domain.local og en konfiguration for udgående opkald til byen. ACL bruges til at sikre vores telefonisystem mod uautoriserede opkald, som kan koste os penge. Det vil sige, kun de netværk, der er beskrevet i ACL, får lov til at foretage udgående opkald. Her er det vigtigt at have en klar forståelse af, hvordan ACL fungerer i FusionPBX, dets karakteristika, logik og tilknyttede punkter.

Ligesom den respektable forfatter af den nævnte artikel er jeg også trådt på alle spidserne relateret til ACL.

Lad mig starte med SipProfiles.
Begge profiler (som jeg vil kalde dem), både internal og external, befinder sig i konteksten Public, og det er ikke tilfældigt. Registreringen af numre sker i profilen internal, som vi vil fokusere på. I profilen internal er ACL-listen domains knyttet som apply-inbound-acl. Denne linje styrer ACL's funktion på profileniveau. Indtil videre ser alt godt ud i forhold til profilerne.

Context

Kontexten bruges desuden til opkaldsrouting. Alle indkommende ruter er knyttet til konteksten Public.

Udgående (til byen, mobilnumre, intercity, international og alle andre) ruter findes (som standard) i konteksten navnet domænet (lad os kalde det domain.local).

ACL

Lad os nu se nærmere på ACL. Som standard er der i det nyinstallerede FusionPBX to ACL-lister:

domains standardhandling: deny — denne liste er knyttet til profilen internal
lan standardhandling: allow

I ACL-listen domains angiver vi netværket (for eksempel 192.168.0.0/24), giver denne netværk tilladelse allow, anvender reloadacl.

Derefter registrerer vi en telefon fra dette netværk, og alt ser godt ud ifølge instruktionerne og virker logisk.
Vi begynder at teste og laver et opkald til et eksternt nummer og... får en bageri, eller rettere sagt et hul fra et bageri. Overraskende!

Vi begynder at analysere loggen i konsollen eller via Log Viewer i FusionPBX.

Vi ser vores opkald:

switch_channel.c:1104 Ny Kanal sofia/internal/1010@domain.local

Vi ser det aktiverede ACL:

sofia.c:10208 IP 192.168.0.150 Godkendt af acl "domains[]". Adgang givet.

Og herefter:

mod_dialplan_xml.c:637 Behandler 1010 ->98343379xxxx i kontekst public
switch_core_state_machine.c:311 Ingen rute, annullering
switch_core_state_machine.c:312 Afbrud sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Ingen rute! Selvom ruten er korrekt angivet.

Svaret er faktisk enkelt.

Opkaldet kom ind. ACL tillod det. Da ACL er knyttet til profilen intern, og denne profil befinder sig i konteksten public, ser FreeSWITCH nøje på routingen i konteksten public. Men i konteksten public er der kun indgående routing, og systemet fortæller os tydeligt, at der ikke findes nogen ruter til byen.

Fra den nuværende situation er der i det mindste to udveje.

Få denne ACL knyttet ikke til profilen, men til det interne nummer. Dette kan være den mest korrekte løsning, da ACL bedst skal knyttes så tæt på Extension som muligt for mere finjusteret kontrol. Dvs. man kan specificere en bestemt adresse/netværk for telefonen, som den kan lave udgående opkald fra. Ulempen ved denne mulighed er, at det skal gøres i hver Extension.
Korrigere ACL, så den fungerer korrekt på profilniveau. Jeg valgte netop denne mulighed, da det synes lettere at tilføje et netværk til ACL én gang end at indtaste det i hver Extension. Men dette er specifikt for min opgave. For andre opgaver kan der være brug for en anden beslutningslogik.

Så. Lad os forbedre ACL domains som følger:

domains standard handling: tillad

I ACL-listen domains angiver vi netværket:

deny 192.168.0.0/24

Vi anvender, reloadacl.
Tester: indtaster igen nummeret 98343379xxxx og… det går igennem… ALLO. Alt fungerer.
Lad os se, hvad der skete i FreeSWITCH:
opkaldet starter:

switch_channel.c:1104 Ny Kanal sofia/internal/1010@domain.local

ACL tillod ikke:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Afvist af acl "domains". Falder tilbage til Digest auth.

og derefter:

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

Routing gik igennem, og derefter går forbindelsen i gang, som går ud over emnet.

Hvis vi ændrer netværksadressen i ACL, vil vi dog få det samme billede som ved den første test, dvs. ACL vil tillade opkaldet, og routing siger NO_ROUTE_DESTINATION.

Det er nok alt, hvad jeg ønskede at tilføje om ACL i FusionPBX.

Jeg håber, det bliver til nytte for nogen.

Kilde: habr.com