My artikel is nie 'n volledige beskrywing van die produk nie, maar slegs 'n effense verfyning van die goeie publikasie "FusionPBX, of weer-groot, FreeSWITCH". Dit lyk vir my of die onderwerp van ACL in FusionPBX nie baie goed daarin geopenbaar word nie. Ek sal probeer om hierdie gaping te vul op grond van my eie ervaring met FreeSWITCH/FusionPBX.
En so, ons het 'n geïnstalleerde FusionPBX met 'n geregistreerde interne nommer 1010 in die domain.local-domein en 'n gekonfigureerde roete vir eksterne oproepe na die stad. Ons gebruik ACL om ons telefoniestelsel te beveilig teen ongemagtigde oproepe wat ons geld sal wegneem. Dié. slegs vanaf die netwerke wat in die ACL beskryf word, laat uitgaande oproepe toe. En hier het jy 'n heeltemal duidelike begrip nodig van hoe ACL in FusionPBX werk, sy kenmerke, logika en sy ankerpunt.
Soos die gerespekteerde skrywer van bogenoemde artikel, het ek ook al die harke wat met ACL verband hou, getrap.
Ek sal begin met SipProfile.
Beide profiele (ek sal hulle so noem), beide intern en ekstern, is in die Publieke konteks, en dit is nie toevallig nie. Registrasie van nommers vind plaas in die interne profiel, en ons sal aandag daaraan gee. In die interne profiel is die domeine ACL gebind as toepassing-inkomende-acl. Dit is hierdie lyn wat verantwoordelik is vir die werking van die ACL op profielvlak. Tot dusver is dit dit met die profiele.
Konteks
Konteks word onder andere gebruik in oproeproetering. Alle inkomende roetes is gebonde aan die publieke konteks.
Uitgaande (na die stad, na sellulêre, langafstand, internasionaal en enige ander) roetes is (by verstek) in die konteks van 'n domeinnaam (kom ons noem dit domein.local).
ACL
Kom ons gaan nou oor ACL's. By verstek het 'n nuut geïnstalleerde FusionPBX twee ACL's:
domeine verstek aksie: weier - hierdie blad is gebind aan die interne profiel
lan verstek aksie: toelaat
In die domeine ACL lys, skryf ons die netwerk voor (wel, byvoorbeeld, 192.168.0.0/24), ons maak die toelaat toestemming vir hierdie netwerk, ons gebruik reloadacl.
Vervolgens registreer ons 'n foon vanaf hierdie netwerk, en dit lyk asof alles in orde is en volgens die instruksies en logies.
Ons begin toets, maak 'n oproep na 'n eksterne nommer en ... ons kry 'n doughnut, of liewer 'n doughnut-gat. Skielik!
Ons begin om die log in die konsole of deur die Log Viewer FusioPBX te ontleed.
Ons sien ons uitdaging:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Ons sien die ACL wat gewerk het:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.En verder:
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] Geen roete nie! Alhoewel die roete het ons eerlik geregistreer.
Die antwoord is regtig eenvoudig.
Die oproep het gekom. ACL het dit gemis. En aangesien die ACL in die interne profiel gebind is, en hierdie profiel in die publieke konteks is, kyk FreeSWITCH eerlik na roetering in die publieke konteks. Maar in die openbare konteks, slegs inkomende roetes, en die stelsel sê eerlik vir ons dat daar geen roetes na die stad daar is nie.
Daar is ten minste twee maniere uit hierdie situasie.
- Heg hierdie ACL nie aan die profiel nie, maar aan die interne nommer self. Dit is dalk die mees korrekte manier om op te los, want. Dit is beter om ACL so na as moontlik aan Extension te bind vir fyner stemming. Dié. jy kan 'n spesifieke adres / netwerkadres van die foon voorskryf waarvandaan dit 'n uitgaande oproep kan maak. Die nadeel van hierdie opsie is dat elke Uitbreiding dit sal moet doen.
- Maak die ACL reg sodat dit korrek op profielvlak werk. Ek het hierdie opsie gekies, want dit het vir my makliker gelyk om die netwerk een keer by die ACL te voeg as om dit in elke Uitbreiding voor te skryf. Maar dit is spesifiek vir my taak. Vir ander take het jy dalk 'n ander besluitnemingslogika nodig.
Dus. Kom ons maak die ACL-domeine soos volg reg:
domeine verstek aksie: toelaat
In die domeine ACL-lys registreer ons die netwerk:
ontken 192.168.0.0/24
Pas toe, herlaaiacl.
Ons toets: ons skakel weer die nommer 98343379xxxx en ... die kontrolepunt kom ... HALLO. Alles werk.
Kom ons kyk wat gebeur het in FreeSWITCH:
oproep begin:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL het nie gemis nie:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.en verder:
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 Roetering is geslaag, en dan kom die verbinding tot stand, wat buite die bestek van die onderwerp is.
As ons die netwerkadres in die ACL verander, maar die prentjie van die eerste toets kry, m.a.w. Die ACL sal die oproep oorslaan en die roetering sal NO_ROUTE_DESTINATION sê.
Dit is waarskynlik al wat ek op ACL FusionPBX wou byvoeg.
Ek hoop dit sal nuttig wees vir iemand.
Bron: will.com