My article is not a full description of the product, but only a slight refinement of the good publication "FusionPBX, or again-great, FreeSWITCH". It seems to me that the topic of ACL in FusionPBX is not very well disclosed in it. I will try to fill this gap based on my own experience with FreeSWITCH/FusionPBX.
And so, we have an installed FusionPBX with a registered internal number 1010 in the domain.local domain and a configured route for external calls to the city. We use ACLs to secure our telephony system from unauthorized calls that will steal our money. Those. only from the networks described in the ACL allow outgoing calls. And here you need a completely clear understanding of how ACL works in FusionPBX, its features, logic and its anchor point.
Like the respected author of the above article, I also stepped on all the rakes related to ACL.
I will begin with SipProfiles.
Both profiles (I will call them that), both internal and external, are in the Public context, and this is not accidental. Registration of numbers takes place in the internal profile, and we will pay attention to it. In the internal profile, the domains ACL is bound as apply-inbound-acl. It is this line that is responsible for the operation of the ACL at the profile level. So far, that's it with the profiles.
Context
Context is used, among other things, in call routing. All incoming routes are bound to the Public context.
Outgoing (to the city, to cellular, long distance, international, and any other) routes are (by default) in the context of a domain name (let's call it domain.local).
ACL
Now let's deal with ACLs. By default, a freshly installed FusionPBX has two ACLs:
domains default action: deny - this sheet is bound to the internal profile
lan default action: allow
In the domains ACL list, we prescribe the network (well, for example, 192.168.0.0/24), we make the allow permission for this network, we use reloadacl.
Next, we register a phone from this network, and everything seems to be fine and according to the instructions and logically.
We start testing, make a call to an external number and ... we get a donut, or rather a donut hole. Suddenly!
We begin to analyze the log in the console or through the Log Viewer FusioPBX.
We see our challenge:
switch_channel.c:1104 New Channel sofia/internal/[email protected]We see the ACL that worked:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.And further:
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] No route! Although the route we have honestly registered.
The answer is really simple.
The call has come. ACL missed it. And since the ACL is bound in the internal profile, and this profile is in the public context, FreeSWITCH honestly looks at routing in the public context. But in the public context, only incoming routing, and the system honestly tells us that there are no routes to the city there.
There are at least two ways out of this situation.
- Attach this ACL not to the profile, but to the internal number itself. This may be the most correct way to solve, because. It is better to bind ACL as close as possible to Extension for finer tuning. Those. you can prescribe a specific address / network address of the phone from which it can make an outgoing call. The disadvantage of this option is that each Extension will have to do this.
- Fix the ACL so that it works correctly at the profile level. I chose this option, because it seemed to me easier to add the network to the ACL once than to prescribe it in each Extension. But this is specifically for my task. For other tasks, you may need a different decision-making logic.
So. Let's fix the ACL domains as follows:
domains default action: allow
In the domains ACL list, we register the network:
deny 192.168.0.0/24
Apply, reloadacl.
We are testing: we dial the number 98343379xxxx again and ... the checkpoint is coming ... HELLO. Everything is working.
Let's see what happened in FreeSWITCH:
call starts:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL did not miss:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.and further:
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 has passed, and then comes the connection establishment, which is beyond the scope of the topic.
If we change the network address in the ACL, but get the picture from the first test, i.e. The ACL will skip the call and the routing will say NO_ROUTE_DESTINATION.
That's probably all I wanted to add on ACL FusionPBX.
I hope it will be useful to someone.
Source: habr.com