Mój artykuł nie jest pełnym opisem produktu, a jedynie lekkim rozwinięciem dobrej publikacji "FusionPBX, czyli znowu świetny FreeSWITCH". Wydaje mi się, że temat ACL w FusionPBX nie jest w nim zbyt dobrze ujawniony. Postaram się wypełnić tę lukę bazując na własnych doświadczeniach z FreeSWITCH/FusionPBX.
I tak mamy zainstalowaną centralę FusionPBX z zarejestrowanym numerem wewnętrznym 1010 w domenie domain.local i skonfigurowaną trasą połączeń zewnętrznych do miasta. Używamy ACL, aby zabezpieczyć nasz system telefoniczny przed nieautoryzowanymi połączeniami, które odbiorą nam pieniądze. Te. tylko z sieci opisanych na liście ACL zezwalają na połączenia wychodzące. I tutaj potrzebne jest całkowicie jasne zrozumienie działania listy ACL w FusionPBX, jej funkcji, logiki i punktu zakotwiczenia.
Podobnie jak szanowny autor powyższego artykułu, również nadepnąłem na wszystkie raki związane z ACL.
Zacznę od SipProfile.
Obydwa profile (tak je będę nazywać), zarówno wewnętrzne, jak i zewnętrzne, znajdują się w kontekście Publicznym i nie jest to przypadkowe. Rejestracja numerów odbywa się w profilu wewnętrznym i będziemy na to zwracać uwagę. W profilu wewnętrznym lista ACL domen jest powiązana jako Apply-Inbound-Acl. To właśnie ta linia odpowiada za działanie listy ACL na poziomie profilu. To tyle, jeśli chodzi o profile.
Kontekst
Kontekst wykorzystywany jest między innymi w kierowaniu połączeń. Wszystkie trasy przychodzące są powiązane z kontekstem publicznym.
Trasy wychodzące (do miasta, do sieci komórkowej, międzymiastowe, międzynarodowe i inne) są (domyślnie) w kontekście nazwy domeny (nazwijmy ją domena.local).
ACL
Zajmijmy się teraz listami ACL. Domyślnie świeżo zainstalowana centrala FusionPBX ma dwie listy ACL:
domyślna akcja domeny: odmów - ten arkusz jest powiązany z profilem wewnętrznym
domyślna akcja LAN: zezwól
Na liście ACL domen podajemy sieć (no cóż, na przykład 192.168.0.0/24), zezwalamy na zezwolenie dla tej sieci, używamy reloadacl.
Następnie rejestrujemy telefon z tej sieci i wszystko wydaje się być w porządku, zgodnie z instrukcją i logicznie.
Przystępujemy do testów, dzwonimy na numer zewnętrzny i… dostajemy pączka, a raczej pączkową dziurę. Nagle!
Zaczynamy analizować logi w konsoli lub poprzez przeglądarkę logów FusioPBX.
Widzimy nasze wyzwanie:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Widzimy listę ACL, która zadziałała:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.I dalej:
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] Brak trasy! Chociaż trasę uczciwie zarejestrowaliśmy.
Odpowiedź jest naprawdę prosta.
Nadeszło wezwanie. ACL tego przegapiło. A ponieważ lista ACL jest powiązana z profilem wewnętrznym, a profil ten znajduje się w kontekście publicznym, FreeSWITCH uczciwie przygląda się routingowi w kontekście publicznym. Ale w kontekście publicznym tylko trasy przychodzące, a system szczerze nam mówi, że nie ma tam żadnych tras do miasta.
Wyjścia z tej sytuacji są co najmniej dwa.
- Dołącz tę listę ACL nie do profilu, ale do samego numeru wewnętrznego. Może to być najwłaściwszy sposób rozwiązania, ponieważ. Lepiej jest powiązać listę ACL jak najbliżej rozszerzenia, aby uzyskać dokładniejsze dostrojenie. Te. możesz ustawić konkretny adres/adres sieciowy telefonu, z którego będzie on mógł wykonywać połączenia wychodzące. Wadą tej opcji jest to, że każde rozszerzenie będzie musiało to zrobić.
- Napraw listę ACL, aby działała poprawnie na poziomie profilu. Wybrałem tę opcję, ponieważ wydawało mi się, że łatwiej jest dodać sieć do listy ACL raz, niż przepisywać ją w każdym rozszerzeniu. Ale to jest specjalnie do mojego zadania. W przypadku innych zadań możesz potrzebować innej logiki podejmowania decyzji.
Więc. Naprawmy domeny ACL w następujący sposób:
domyślna akcja domeny: zezwól
Na liście ACL domen rejestrujemy sieć:
odrzuć 192.168.0.0/24
Zastosuj, załaduj ponownie
Testujemy: ponownie wybieramy numer 98343379xxxx i… zbliża się punkt kontrolny… WITAM. Wszystko działa.
Zobaczmy, co wydarzyło się we FreeSWITCH:
rozpoczyna się połączenie:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL nie ominęło:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.i dalej:
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 Trasowanie minęło, a potem następuje nawiązanie połączenia, co wykracza poza zakres tematu.
Jeśli zmienimy adres sieciowy w liście ACL, ale uzyskamy obraz z pierwszego testu, tj. Lista ACL pominie połączenie, a routing powie NO_ROUTE_DESTINATION.
To chyba wszystko, co chciałem dodać do ACL FusionPBX.
Mam nadzieję, że komuś się przyda.
Źródło: www.habr.com