🥇FusionPBX un ACL

Mans raksts nav pilnīgs produkta apraksts, bet tikai neliels precizējums par labu publikāciju «FusionPBX, vai atkal sveiki, FreeSWITCH». Man šķiet, ka tajā nav diez ko labi izskaidrota ACL tēma FusionPBX. Mēģināšu aizpildīt šo tukšumu, balstoties uz savu pieredzi ar FreeSWITCH/FusionPBX.

Tātad, mums ir uzstādīts FusionPBX ar reģistrētu iekšējo numuru 1010 domēnā domain.local un izveidotu maršrutu ārējiem zvaniem uz pilsētu. ACL izmantojam, lai aizsargātu mūsu telefonsistēmu no nesankcionētiem zvaniem, kas mūs izmaksās. T.i., tikai no ACL aprakstītajām tīklu atļaut izsūtīt zvanu. Un šeit nepieciešams ļoti skaidrs izpratne par to, kā darbojas ACL FusionPBX, tā iezīmēm, loģiku un tā piesaistes punktu.

Tāpat kā ievērojamais autors iepriekš minētajā rakstā, es arī uzdūros visām grūtībām, kas saistītas ar ACL.

Sāksim ar SipProfiles.
Abi profili (kā es tos saukšu), un internal, un external atrodas Public kontekstā, un tas nav nejauši. Numuru reģistrācija notiek internal profilā, uz kuru arī pievērsīsim uzmanību. Internal profilā ir piesaistīts ACL saraksts domains, kā apply-inbound-acl. Tieši šī rindiņa ir atbildīga par ACL darbību profila līmenī. Kamēr ar profiliem viss.

Context

Konteksts, turklāt, tiek izmantots zvanu maršrutēšanai. Visi iekšējie maršruti ir piesaistīti Public kontekstam.

Izsūtīšanas (uz pilsētu, uz mobilajiem, starptautiskiem, starppilsētu un jebkuriem citiem) maršruti atrodas (pēc noklusējuma) kontekstā ar nosaukumu domēns (saucam to par domain.local).

ACL

Tagad izskatīsim ACL. Pēc noklusējuma, tikko uzstādītā FusionPBX ir divi ACL saraksti:

domains noklusējuma darbība: deny — šis saraksts ir piesaistīts internal profilam
lan noklusējuma darbība: allow

ACL sarakstā domains ierakstām tīklu (piemēram, 192.168.0.0/24), piešķiram šim tīklam atļauju allow un piemērojam reloadacl.

Pēc tam reģistrējam tālruņa numuru no šī tīkla, un šķiet, ka viss ir kārtībā un loģiski saskaņā ar instrukcijām.
Sākam testēt, veicot zvanu uz ārēju numuru un… saņemam nulli jeb precīzāk, caurumu. Negaidīti!

Sākam analizēt žurnālu konsolē vai izmantojot Log Viewer FusioPBX.

Redzam mūsu zvanu:

switch_channel.c:1104 Jaunais kanāls sofia/internal/1010@domain.local

Redzam aktivizēto ACL:

sofia.c:10208 IP 192.168.0.150 Apstiprināts ar acl "domains[]". Piekļuve piešķirta.

Un tālāk:

mod_dialplan_xml.c:637 Apstrāde 1010 ->98343379xxxx kontekstā publiskais
switch_core_state_machine.c:311 Nav maršruta, pārtraucam 
switch_core_state_machine.c:312 Pakaram sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]

Nav maršruta! Lai gan maršruts mums godīgi ir norādīts.

Atbilde patiesībā ir vienkārša.

Zvans ir saņemts. ACL to ir palaidis. Un, tā kā ACL ir piesaistīts iekšējam profilam, un šis profils atrodas publiskā kontekstā, FreeSWITCH godīgi skatās maršrutēšanu publiskajā kontekstā. Bet publiskajā kontekstā ir tikai ienākošā maršrutēšana, un sistēma godīgi saka mums, ka tur nav neviena maršruta uz pilsētu.

No izveidotās situācijas ir vismaz divi risinājumi.

Pieslēgt šo ACL nevis profilam, bet pašam iekšējam numuram. Tas varētu būt pat vispareizākais risinājums, jo ACL labāk piesaistīt tuvāk Extension, lai veiktu precīzāku konfigurāciju. T.i., var norādīt konkrētu adresi/adresi tīklam, no kura viņš var veikt izejošo zvanu. Šī varianta mīnuss ir tas, ka katrā Extension jāveic šī iestatīšana.
Uzlabot ACL tā, lai tas korekti darbotos profila līmenī. Es izvēlējos tieši šo variantu, jo pievienot vienreiz tīklu ACL man šķita vienkāršāk, nekā to norādīt katrā Extension. Bet tas ir konkrēti manam uzdevumam. Citiem uzdevumiem iespējams, ir nepieciešama cita lēmumu pieņemšanas loģika.

Un tā. Uzlabosim ACL domains šādi:

domains noklusējuma darbība: atļaut

ACL sarakstā domains norādām tīklu:

deny 192.168.0.0/24

Pielietojam, reloadacl.
Testējam: atkal zvanām uz numuru 98343379xxxx un… notiek KPI… HELLO. Viss strādā.
Skatāmies, kas notika FreeSWITCH:
sākas zvans:

switch_channel.c:1104 Jaunais kanāls sofia/internal/1010@domain.local

ACL nepatvēra:

[DEBUG] sofia.c:10263 IP 192.168.0.150 Noraidīts, izmantojot acl "domains". Krīt atpakaļ uz Digest autentifikāciju.

un tālāk:

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

Maršrutēšana ir izturējusi, un tālāk notiek savienojuma izveidošana, kas iznāk ārpus tēmas.

Ja mēs mainīsim tīkla adresi ACL, bet iegūsim ainu no pirmā testa, t.i., ACL zvans palaidīs un maršrutēšana teiks NO_ROUTE_DESTINATION.

Lūk, iespējams, arī viss, ko es vēlējos pievienot par ACL FusionPBX.

Ceru, ka kādam tas noderēs.

Avots: habr.com