ProHoster > blog > administrasi > FusionPBX dan ACL

FusionPBX dan ACL

Artikel saya bukanlah deskripsi lengkap tentang produk, tetapi hanya sedikit penyempurnaan dari publikasi bagus "FusionPBX, atau, sekali lagi, FreeSWITCH". Menurut saya topik ACL di FusionPBX tidak diungkapkan dengan baik di dalamnya. Saya akan mencoba mengisi kesenjangan ini berdasarkan pengalaman saya sendiri dengan FreeSWITCH/FusionPBX.

Jadi, kami telah menginstal FusionPBX dengan nomor internal terdaftar 1010 di domain domain.local dan rute yang dikonfigurasi untuk panggilan eksternal ke kota. Kami menggunakan ACL untuk mengamankan sistem telepon kami dari panggilan tidak sah yang akan merampas uang kami. Itu. hanya dari jaringan yang dijelaskan dalam ACL yang mengizinkan panggilan keluar. Dan di sini Anda memerlukan pemahaman yang jelas tentang cara kerja ACL di FusionPBX, fitur-fiturnya, logika, dan titik jangkarnya.

Seperti penulis artikel di atas yang dihormati, saya juga menginjak semua hal yang berhubungan dengan ACL.

Saya akan mulai dengan Profil Sip.
Kedua profil tersebut (saya akan menyebutnya demikian), baik internal maupun eksternal, berada dalam konteks Publik, dan ini bukan suatu kebetulan. Pendaftaran nomor dilakukan di profil internal, dan kami akan memperhatikannya. Di profil internal, domain ACL terikat sebagai apply-inbound-acl. Baris inilah yang bertanggung jawab atas pengoperasian ACL di tingkat profil. Sejauh ini, itu saja dengan profilnya.

Konteks

Konteks digunakan, antara lain, dalam perutean panggilan. Semua rute masuk terikat pada konteks Publik.

Rute keluar (ke kota, ke seluler, jarak jauh, internasional, dan lainnya) (secara default) berada dalam konteks nama domain (sebut saja domain.local).

ACL

Sekarang mari kita berurusan dengan ACL. Secara default, FusionPBX yang baru diinstal memiliki dua ACL:

tindakan default domain: tolak - sheet ini terikat ke profil internal
tindakan default lan: izinkan

Dalam daftar domain ACL, kami meresepkan jaringan (misalnya, 192.168.0.0/24), kami membuat izin izin untuk jaringan ini, kami menggunakan reloadacl.

Selanjutnya, kami mendaftarkan telepon dari jaringan ini, dan semuanya tampak baik-baik saja dan sesuai dengan instruksi dan logis.
Kami memulai pengujian, melakukan panggilan ke nomor eksternal dan ... kami mendapatkan donat, atau lebih tepatnya lubang donat. Tiba-tiba!

Kami mulai menganalisis log di konsol atau melalui Log Viewer FusioPBX.

Kami melihat tantangan kami:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

Kami melihat ACL yang berfungsi:

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

Dan selanjutnya:

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]

Tidak ada rute! Padahal rutenya telah kami daftarkan dengan jujur.

Jawabannya sangat sederhana.

Panggilan telah datang. ACL melewatkannya. Dan karena ACL terikat pada profil internal, dan profil ini berada dalam konteks publik, FreeSWITCH dengan jujur ​​​​melihat perutean dalam konteks publik. Namun dalam konteks publik, hanya rute masuk, dan sistem dengan jujur ​​memberi tahu kita bahwa tidak ada rute ke kota di sana.

Setidaknya ada dua jalan keluar dari situasi ini.

  1. Lampirkan ACL ini bukan ke profil, tapi ke nomor internal itu sendiri. Ini mungkin cara penyelesaian yang paling tepat, karena. Lebih baik mengikat ACL sedekat mungkin dengan Ekstensi untuk penyetelan yang lebih baik. Itu. Anda dapat menentukan alamat/alamat jaringan tertentu dari telepon yang dapat digunakan untuk melakukan panggilan keluar. Kerugian dari opsi ini adalah setiap Ekstensi harus melakukan hal ini.
  2. Perbaiki ACL agar berfungsi dengan benar pada tingkat profil. Saya memilih opsi ini karena menurut saya lebih mudah menambahkan jaringan ke ACL satu kali daripada meresepkannya di setiap Ekstensi. Tapi ini khusus untuk tugas saya. Untuk tugas lain, Anda mungkin memerlukan logika pengambilan keputusan yang berbeda.

Jadi. Mari kita perbaiki domain ACL sebagai berikut:

tindakan default domain: izinkan

Dalam daftar domain ACL, kami mendaftarkan jaringan:

tolak 192.168.0.0/24

Terapkan, muat ulang.
Kami sedang menguji: kami menekan nomor 98343379xxxx lagi dan ... pos pemeriksaan akan datang ... HALO. Semuanya berfungsi.
Mari kita lihat apa yang terjadi di FreeSWITCH:
panggilan dimulai:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

ACL tidak ketinggalan:

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

dan selanjutnya:

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

Perutean telah berlalu, dan kemudian muncullah pembuatan koneksi, yang berada di luar cakupan topik.

Jika kita mengubah alamat jaringan di ACL, tetapi mendapatkan gambaran dari pengujian pertama, mis. ACL akan melewatkan panggilan dan perutean akan mengatakan NO_ROUTE_DESTINATION.

Mungkin itu saja yang ingin saya tambahkan pada ACL FusionPBX.

Saya harap ini bermanfaat bagi seseorang.

Sumber: www.habr.com

Tambah komentar