🥇FusionPBX och ACL

Min artikel är inte en fullständig beskrivning av produkten, utan bara en liten förklaring av en bra publikation "FusionPBX, eller återigen, FreeSWITCH". Jag tycker att ämnet ACL i FusionPBX inte riktigt behandlas på ett bra sätt i den. Jag kommer att försöka fylla detta tomrum baserat på min egen erfarenhet av att arbeta med FreeSWITCH/FusionPBX.

Så, vi har installerat FusionPBX med det registrerade interna numret 1010 i domänen domain.local och ett konfigurerat route för externa samtal till staden. Vi använder ACL för att skydda vårt telefonsystem från obehöriga samtal som kan kosta oss pengar. Det innebär att endast de nätverk som beskrivs i ACL tillåts göra utgående samtal. Här krävs det en tydlig förståelse för hur ACL fungerar i FusionPBX, dess egenskaper, logik och kopplingspunkt.

Precis som den respekterade författaren av den nämnda artikeln så har även jag stött på alla fallgropar kopplade till ACL.

Jag börjar med SipProfiles.
Båda profilerna (som jag kommer att kalla dem), både internal och external, finns i kontexten Public, vilket inte är en slump. Registreringen av nummer sker i profilen internal, och vi kommer att fokusera på den. I profilen internal är ACL-listan domains kopplad som apply-inbound-acl. Det är just den här raden som ansvarar för ACL:s funktion på profilenivå. Så långt har vi klarat profilerna.

Context

Kontexten används också vid samtalsroutning. Alla inkommande rutter är kopplade till kontexten Public.

Utgående (till staden, till mobiltelefoner, långdistans, internationella, och andra) rutter finns (som standard) i kontexten med namnet domän (låt oss kalla den domain.local).

ACL

Låt oss nu titta på ACL. Som standard finns det två ACL-listor i den nyinstallerade FusionPBX:

domains default action: deny — denna lista är kopplad till profilen internal
lan default action: allow

I ACL-listan domains anger vi nätverket (till exempel 192.168.0.0/24), ger detta nätverk tillstånd allow, och tillämpar reloadacl.

Därefter registrerar vi en telefon från detta nätverk, och det verkar vara okej både enligt instruktionerna och logiskt.
Vi börjar testa, gör ett samtal till ett externt nummer och… får ett bakslag, eller snarare en donut. Oväntat!

Vi börjar analysera loggen i konsolen eller via Log Viewer i FusioPBX.

Vi ser vårt samtal:

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

Vi ser den aktiverade ACL:

sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.

Och vidare:

mod_dialplan_xml.c:637 Bearbetning 1010 ->98343379xxxx i kontext offentlig
switch_core_state_machine.c:311 Inga rutter, avbryter 
switch_core_state_machine.c:312 Överge sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Ingen rutt! Trots att rutten är korrekt angiven.

Svaret är faktiskt enkelt.

Samtalet kom in. ACL tillät det. Eftersom ACL är kopplad till profilen internal och denna profil befinner sig i kontexten offentlig, kontrollerar FreeSWITCH routing i den offentliga kontexten. Men i den offentliga kontexten finns det endast ingående routing, och systemet säger ärligt att det inte finns några rutter i staden.

Det finns minst två alternativ i den uppkomna situationen.

Koppla denna ACL inte till profilen, utan till det interna numret själv. Detta kan vara det mest rätta sättet att lösa det, eftersom ACL är bättre att binda så nära på Extension som möjligt för mer finjustering. D.v.s. man kan ange en specifik adress/nätverksadress för telefonen från vilken den kan göra samtal. Nackdelen med detta alternativ är att man måste göra detta i varje Extension.
Korrigera ACL så att den fungerar korrekt på profileringsnivå. Jag valde detta alternativ, eftersom det verkade enklare att lägga till nätet i ACL en gång snarare än att ange det i varje Extension. Men detta är specifikt för mitt syfte. För andra uppgifter kan det möjligtvis krävas en annan beslutslogik.

Så. Vi korrigerar ACL domains på följande sätt:

domains standardåtgärd: tillåt

I ACL-listan domains anger vi nätverket:

deny 192.168.0.0/24

Tillämpa, reloadacl.
Testa: slå åter numret 98343379xxxx och… det finns en koppling… HALLO. Allt fungerar.
Vi tittar på vad som hände i FreeSWITCH:
samtalet inleds:

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

ACL tillät inte:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Avvisad av acl "domains". Återgår till Digest autentisering.

och vidare:

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

Routing passerade, och vidare går anslutningen, vilket går bortom ämnet.

Om vi ändrar nätverksadressen i ACL, men får samma resultat som vid första testet, d.v.s. ACL tillåter samtalet och routing säger NO_ROUTE_DESTINATION.

Det är nog allt jag ville lägga till angående ACL FusionPBX.

Hoppas det här är till nytta för någon.

Källa: habr.com