FusionPBX 및 ACL

제 기사는 제품에 대한 전체적인 설명이 아니라, 좋은 출판물인 "FusionPBX, 또는 FreeSWITCH"에 대한 간략한 설명일 뿐입니다. FusionPBX의 ACL 주제를 잘 다루고 있다고 생각하지 않습니다. 저는 FreeSWITCH/FusionPBX에 대한 저의 경험을 토대로 이러한 차이를 메우려고 노력할 것입니다.

따라서 domain.local 도메인에 등록된 내부 번호 1010이 있는 FusionPBX를 설치하고 도시로의 외부 통화를 위한 경로를 구성했습니다. 우리는 승인되지 않은 전화로 인해 돈을 훔쳐가는 것을 막기 위해 ACL을 사용합니다. 저것들. ACL에 설명된 네트워크에서만 발신 통화를 허용합니다. 여기서는 FusionPBX에서 ACL이 작동하는 방식, 기능, 논리 및 연결 지점에 대해 완벽하게 이해해야 합니다.

위 기사를 쓴 존경하는 저자와 마찬가지로 저 역시 ACL과 관련된 모든 부상을 겪었습니다.

나부터 시작하겠습니다. SipProfiles.
두 가지 프로필(저는 이렇게 부르겠습니다)은 모두 내부적, 외부적 측면에서 대중적 맥락에 있으며, 이는 우연이 아닙니다. 숫자의 등록은 내부 프로필에서 이루어지며, 우리는 그것에 주의를 기울일 것입니다. 내부 프로필에서 도메인 ACL은 apply-inbound-acl로 바인딩됩니다. 이 라인은 프로필 수준에서 ACL의 작동을 담당합니다. 이제 프로필에 대한 설명은 모두 끝났습니다.

문맥

통화 라우팅에서는 컨텍스트가 사용됩니다. 모든 수신 경로는 공개 컨텍스트에 바인딩됩니다.

발신 경로(도시, 휴대전화, 장거리, 국제 등)는 (기본적으로) 이름 컨텍스트 내에 표시됩니다. 도메인 (이 도메인을 domain.local이라고 부르겠습니다.)

ACL

이제 ACL을 다루겠습니다. 기본적으로 새로 설치된 FusionPBX에는 두 개의 ACL이 있습니다.

도메인 기본 작업: 거부 - 이 시트는 내부 프로필에 연결되어 있습니다.
lan 기본 동작: 허용

ACL 목록 도메인에 네트워크를 작성합니다(예: 192.168.0.0/24). 이 네트워크에 허용 권한을 부여하고 reloadacl을 사용합니다.

다음으로 이 네트워크에서 전화를 등록했는데, 모든 것이 잘 진행되고 있고 지시와 논리에 맞는 것 같습니다.
우리는 테스트를 시작하고 외부 번호로 전화를 걸었고... 도넛을 얻었습니다. 아니, 도넛에 구멍이 생겼습니다. 갑자기!

콘솔이나 FusioPBX 로그 뷰어를 통해 로그 분석을 시작합니다.

우리는 우리의 과제를 봅니다:

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

트리거된 ACL을 확인합니다.

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

그리고 더 :

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] 

경로 없음! 우리의 경로는 명확하게 기록되어 있지만요.

대답은 정말 간단합니다.

전화가 왔습니다. ACL이 놓쳤습니다. 그리고 ACL이 내부 프로필에 바인딩되어 있고, 이 프로필이 공개 컨텍스트에 있기 때문에 FreeSWITCH는 공개 컨텍스트에서 라우팅을 정직하게 살펴봅니다. 하지만 공공의 맥락에서는 들어오는 경로만 있고, 시스템은 정직하게 도시로 가는 경로가 없다고 말합니다.

이 상황에서 벗어날 수 있는 방법은 적어도 두 가지가 있습니다.

1. 이 ACL을 프로필이 아닌 내부 번호 자체에 첨부하세요. 이것은 문제를 해결하는 가장 올바른 방법일 수 있습니다. 왜냐하면 더욱 세밀한 사용자 정의를 위해 ACL을 확장 기능에 최대한 가깝게 바인딩하는 것이 더 좋기 때문입니다. 저것들. 발신 통화가 가능한 전화기의 특정 주소/네트워크 주소를 지정할 수 있습니다. 이 옵션의 단점은 각 확장 프로그램에서 이 작업을 수행해야 한다는 것입니다.
2. ACL을 수정하여 프로필 수준에서 올바르게 작동하도록 합니다. 이 옵션을 선택한 이유는 각 확장에 네트워크를 등록하는 것보다 ACL에 네트워크를 한 번 추가하는 것이 더 쉬울 것 같았기 때문입니다. 하지만 이건 특별히 제 업무를 위한 거예요. 다른 작업에는 다른 의사결정 논리가 필요할 수 있습니다.

그래서. ACL 도메인을 다음과 같이 수정해 보겠습니다.

도메인 기본 동작: 허용

ACL 목록 도메인에서 네트워크를 지정합니다.

거부 192.168.0.0/24

우리는 재로딩을 적용합니다.
테스트해 봅시다: 98343379хххх 번호로 다시 전화를 걸어보세요. 그러면 다이얼 톤이 "안녕하세요"로 들립니다. 모든 것이 작동합니다.
FreeSWITCH에서 무슨 일이 일어났는지 살펴보겠습니다.
통화가 시작됩니다:

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

ACL이 통과되지 않았습니다:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.

이후 :

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 

라우팅이 이루어졌고 이제 연결이 설정되고 있는데, 이는 이 주제의 범위를 벗어납니다.

ACL에서 네트워크 주소를 변경하더라도 첫 번째 테스트의 상황과 같이 ACL 호출은 통과하고 라우팅은 NO_ROUTE_DESTINATION이라고 말할 것입니다.

아마도 이것이 제가 ACL FusionPBX에 대해 추가하고 싶었던 전부일 겁니다.

이것이 누군가에게 유용했으면 좋겠습니다.

출처 : habr.com