🥇FusionPBX i ACL

Mój artykuł nie jest pełnym opisem produktu, lecz jedynie niewielkim uzupełnieniem dobrej publikacji „FusionPBX, czyli znowu w porządku, FreeSWITCH”. Wydaje mi się, że temat ACL w FusionPBX nie został w niej dostatecznie omówiony. Spróbuję wypełnić tę lukę, opierając się na własnym doświadczeniu pracy z FreeSWITCH/FusionPBX.

A więc mamy zainstalowany FusionPBX z zarejestrowanym wewnętrznym numerem 1010 w domenie domain.local oraz skonfigurowaną trasą dla połączeń zewnętrznych do miasta. Używamy ACL, aby zabezpieczyć nasz system telefonii przed nieautoryzowanymi połączeniami, które mogą nas kosztować. To znaczy, że tylko z sieci opisanych w ACL zezwalamy na połączenia wychodzące. Potrzebne jest tutaj całkowicie jasne zrozumienie, jak działa ACL w FusionPBX, jego cechy, logika i punkt jego przypisania.

Tak jak szanowany autor wspomnianego artykułu, również natrafiłem na wszystkie pułapki związane z ACL.

Zacznijmy od SipProfiles.
Oba profile (będę je tak nazywać), zarówno internal, jak i external znajdują się w kontekście Public, co nie jest przypadkowe. Rejestracje numerów odbywają się w profilu internal, na nim się skupimy. W profilu internal przypisany jest liste ACL domains jako apply-inbound-acl. To właśnie ten wiersz odpowiada za działanie ACL na poziomie profilu. Na razie z profilami wszystko.

Context

Kontekst, oprócz wszystko, jest wykorzystywany w routingu połączeń. Wszystkie trasy przychodzące są przypisane do kontekstu Public.

Trasy wychodzące (do miasta, na telefony komórkowe, międzymiastowe, międzynarodowe i inne) znajdują się (domyślnie) w kontekście nazwanym domeny (nazwijmy go domain.local).

ACL

Teraz przyjrzyjmy się ACL. Domyślnie, w nowo zainstalowanym FusionPBX są dwa listy ACL:

domains działanie domyślne: deny — ta lista jest przypisana do profilu internal
lan działanie domyślne: allow

W liście ACL domains zapisujemy sieć (na przykład 192.168.0.0/24), nadajemy tej sieci zezwolenie allow, stosujemy reloadacl.

Następnie rejestrujemy telefon z tej sieci, i z pozoru wszystko jest dobrze i zgodnie z instrukcją.
Zaczynamy testować, wykonujemy połączenie na zewnętrzny numer i… otrzymujemy puste miejsce, a dokładniej dziurę od pączka. Niespodzianka!

Zaczynamy analizować log w konsoli lub przez Log Viewer FusioPBX.

Widzimy nasze połączenie:

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

Widoczny działający ACL:

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

I dalej:

mod_dialplan_xml.c:637 Przetwarzanie 1010 ->98343379xxxx w kontekście public
switch_core_state_machine.c:311 Brak trasy, przerywanie 
switch_core_state_machine.c:312 Rozłączenie sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Brak trasy! Mimo że trasa jest poprawnie zdefiniowana.

Odpowiedź jest w rzeczywistości prosta.

Połączenie nadeszło. ACL go przepuścił. A ponieważ ACL jest przypisany do profilu internal, a ten profil znajduje się w kontekście public, FreeSWITCH uczciwie sprawdza trasowanie w kontekście public. Jednak w kontekście public działa tylko trasowanie przychodzące, a system uczciwie mówi nam, że nie ma tam żadnych tras do miasta.

Z tej sytuacji są co najmniej dwa wyjścia.

Podpiąć ten ACL nie do profilu, a do samego wewnętrznego numeru. To może być najwłaściwszy sposób rozwiązania, ponieważ ACL lepiej przypisać możliwie najbliżej do Extension dla bardziej precyzyjnego ustawienia. Tzn. można zdefiniować konkretny adres/adres sieci telefonu, z którego będzie mógł wykonać połączenie wychodzące. Minusem tej opcji jest to, że w każdym Extension trzeba to będzie zrobić.
Poprawić ACL w taki sposób, aby działał poprawnie na poziomie profilu. Wybrałem tę opcję, ponieważ dodanie sieci do ACL wydawało mi się prostsze niż definiowanie jej w każdym Extension. Ale to konkretnie pod moje zadanie. Dla innych zadań, być może, będzie potrzebna inna logika podejmowania decyzji.

I tak. Poprawmy ACL domains w następujący sposób:

domains działanie domyślne: allow

W liście ACL domains definiujemy sieć:

deny 192.168.0.0/24

Zastosować, reloadacl.
Testujemy: ponownie wybieramy numer 98343379xxxx i… idzie KP… HALO. Wszystko działa.
Patrzymy, co działo się w FreeSWITCH:
rozpoczyna się połączenie:

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

ACL nie przepuścił:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Odrzucony przez acl "domains". Powracanie do uwierzytelniania Digest.

i dalej:

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

Trasowanie przeszło, a następnie następuje nawiązywanie połączenia, które wykracza poza temat.

Jeśli zmienimy adres sieci w ACL, otrzymamy obraz z pierwszego testu, tzn. ACL przepuści połączenie, a trasowanie powie NO_ROUTE_DESTINATION.

To chyba wszystko, co chciałem dodać na temat ACL FusionPBX.

Mam nadzieję, że komuś się przyda.

Źródło: habr.com