FusionPBX eta ACL

Nire artikulua ez da produktuaren deskribapen osoa, baizik eta "FusionPBX, edo berriro bikaina, FreeSWITCH" argitalpen onaren hobekuntza apur bat. Iruditzen zait FusionPBX-en ACLren gaia ez dagoela oso ondo ezagutarazi bertan. Hutsune hori betetzen saiatuko naiz FreeSWITCH/FusionPBX-ekin dudan esperientzian oinarrituta.

Beraz, FusionPBX bat dugu instalatuta domeinua.local domeinuan 1010 barne-zenbaki erregistratua eta hirira kanpoko deietarako bide konfiguratua duena. ACL erabiltzen dugu gure telefono-sistema gure dirua kenduko duten baimenik gabeko deietatik babesteko. Horiek. ACL-n deskribatutako sareetatik soilik onartzen dituzte irteerako deiak. Eta hemen ACL-k FusionPBX-en nola funtzionatzen duen, bere ezaugarriak, logika eta bere aingura-puntua guztiz argi ulertu behar duzu.

Goiko artikuluaren egile errespetatua bezala, ACLrekin lotutako arrasto guztiak ere zapaldu ditut.

hasiko naiz SipProfiles.
Bi profilak (horrela deituko ditut), barnekoak zein kanpokoak, Publikoaren testuinguruan daude, eta hori ez da halabeharrezkoa. Zenbakien erregistroa barne profilean egiten da, eta horri erreparatuko diogu. Barneko profilean, ACL domeinuak apply-inbound-acl gisa lotzen dira. Lerro hau da profil mailan ACLren funtzionamenduaz arduratzen dena. Orain arte, hori da profilekin.

Context

Testuingurua erabiltzen da, besteak beste, deien bideratzean. Sarrerako ibilbide guztiak testuinguru publikora lotuta daude.

Irteerako (hirirako, mugikorrerako, distantzia luzerako, nazioartekorako eta beste edozein) ibilbideak (lehenespenez) domeinu-izen baten testuinguruan daude (dei dezagun domeinua.local).

ACL

Orain jorratu ditzagun ACLekin. Lehenespenez, instalatu berri den FusionPBX batek bi ACL ditu:

domeinuen ekintza lehenetsia: ukatu - orri hau barne profilera lotuta dago
lan lehenetsitako ekintza: baimendu

Domeinuen ACL zerrendan, sarea agintzen dugu (beno, adibidez, 192.168.0.0/24), sare honetarako baimena ematen dugu, reloadacl erabiltzen dugu.

Jarraian, sare honetatik telefono bat erregistratzen dugu, eta dena ondo dagoela dirudi eta argibideen arabera eta logikoki.
Proba egiten hasten gara, kanpoko zenbaki batera deitzen dugu eta... donut bat lortzen dugu, edo hobeto esanda, donut zulo bat. Bat-batean!

Erregistroa aztertzen hasiko gara kontsolan edo Log Viewer FusioPBX bidez.

Gure erronka ikusten dugu:

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

Lan egin zuen ACL ikusten dugu:

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

Eta aurrerago:

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] 

Ibilbiderik ez! Ibilbidea zintzoki erregistratu dugun arren.

Erantzuna oso erraza da.

Deia heldu da. ACLk galdu egin zuen. Eta ACL barne profilean lotuta dagoenez eta profil hau testuinguru publikoan dagoenez, FreeSWITCH-ek zintzotasunez begiratzen du bideratzea testuinguru publikoan. Baina testuinguru publikoan, sarrerako bideratzea bakarrik, eta sistemak zintzotasunez esaten digu han hirirako biderik ez dagoela.

Egoera horretatik irteteko bi bide daude gutxienez.

  1. Erantsi ACL hau ez profilari, barneko zenbakiari berari baizik. Hau izan daiteke konpontzeko modurik zuzenena, izan ere. Hobe da ACL ahalik eta hurbilen lotzea Hedapenera sintonizazio finagoetarako. Horiek. telefonoaren helbide/sare-helbide zehatz bat agindu dezakezu, eta bertatik irteerako deiak egin ditzake. Aukera honen desabantaila Luzapen bakoitzak hau egin beharko duela da.
  2. Konpondu ACL profil mailan behar bezala funtziona dezan. Aukera hau aukeratu nuen, errazago iruditu zitzaidalako sarea behin ACLra gehitzea Luzapen bakoitzean preskribatzea baino. Baina hau bereziki nire zereginerako da. Beste zeregin batzuetarako, baliteke erabakiak hartzeko beste logika bat behar izatea.

Beraz. Konpon ditzagun ACL domeinuak honela:

domeinuen ekintza lehenetsia: baimendu

Domeinuen ACL zerrendan, sarea erregistratzen dugu:

ukatu 192.168.0.0/24

Aplikatu, birkargatu.
Proba egiten ari gara: berriro 98343379xxxx zenbakia markatzen dugu eta... kontrol-puntua dator... KAIXO. Dena dabil.
Ikus dezagun zer gertatu den FreeSWITCH-en:
deia hasten da:

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

ACL ez zen galdu:

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

eta aurrerago:

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 

Bideraketa pasatu da, eta, ondoren, konexioaren ezarpena dator, gaiaren esparrutik kanpo dagoena.

ACL-n sareko helbidea aldatzen badugu, baina lehenengo probako argazkia lortzen badugu, hau da. ACL-k deia saltatuko du eta bideratzeak NO_ROUTE_DESTINATION esango du.

Hori da ziurrenik ACL FusionPBX-en gehitu nahi nuen guztia.

Norbaiti erabilgarria izatea espero dut.

Iturria: www.habr.com

Gehitu iruzkin berria