Mijn artikel is geen volledige beschrijving van het product, maar slechts een kleine verduidelijking van de goede publicatie “FusionPBX, of weer geweldig, FreeSWITCH.” Het lijkt mij dat het onderwerp ACL in FusionPBX niet zo goed wordt behandeld. Ik zal proberen deze leemte op te vullen op basis van mijn eigen ervaring met FreeSWITCH/FusionPBX.
En dus hebben we FusionPBX geïnstalleerd met een geregistreerd intern nummer 1010 in het domein domain.local en een geconfigureerde route voor externe oproepen naar de stad. We gebruiken ACL's om ons telefoniesysteem te beschermen tegen ongeautoriseerde oproepen waarmee ons geld wordt gestolen. Die. Sta alleen uitgaande oproepen toe vanaf de netwerken die worden beschreven in de ACL. En hier heeft u een volledig duidelijk begrip nodig van hoe ACL werkt in FusionPBX, de functies, logica en het verbindingspunt ervan.
Net als de gerespecteerde auteur van het bovenstaande artikel stapte ik ook op alle fouten die verband houden met ACL.
Ik zal beginnen met SipProfielen.
Beide profielen (zo zal ik ze noemen), intern en extern, bevinden zich in de publieke context, en dit is niet toevallig. Nummers worden geregistreerd in het interne profiel, dus we zullen er aandacht aan besteden. In het interne profiel zijn de ACL-lijstdomeinen gebonden als apply-inbound-acl. Het is deze lijn die verantwoordelijk is voor de werking van ACL op profielniveau. Dat is alles voor nu met de profielen.
Context
Context wordt onder meer gebruikt bij het routeren van oproepen. Alle inkomende routes zijn gebonden aan de Publieke context.
Uitgaande routes (naar de stad, naar mobiele telefoons, lange afstand, internationaal en alle andere) worden (standaard) in de context van de naam weergegeven. domein (Laten we het domain.local noemen).
ACL
Laten we nu ACL's begrijpen. Standaard heeft een nieuw geïnstalleerde FusionPBX twee ACL's:
domeinen standaardactie: weigeren - dit blad is gebonden aan het interne profiel
standaardactie LAN: toestaan
We registreren een netwerk in de ACL-lijst van domeinen (nou ja, bijvoorbeeld 192.168.0.0/24), geven dit netwerk toestemming, passen reloadacl toe.
Vervolgens registreren we de telefoon vanaf dit netwerk en alles lijkt in orde, zowel volgens de instructies als logisch.
We beginnen met testen, bellen naar een extern nummer en... we krijgen een donut, of liever een donutgat. Plotseling!
We beginnen het logboek te analyseren in de console of via de Log Viewer FusioPBX.
Wij zien onze uitdaging:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.localWe zien de geactiveerde ACL:
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/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION] Geen traject! Al staat onze route eerlijk opgeschreven.
Het antwoord is eigenlijk eenvoudig.
De oproep is gekomen. De ACL heeft het gemist. En aangezien de ACL gekoppeld is aan het interne profiel, en dit profiel zich in de publieke context bevindt, kijkt FreeSWITCH eerlijk naar routering in de publieke context. Maar in de publieke context is er alleen sprake van inkomende routes, en het systeem vertelt ons eerlijk dat er geen routes naar de stad zijn.
Er zijn minstens twee manieren om uit deze situatie te komen.
- Koppel deze ACL niet aan het profiel, maar aan het interne nummer zelf. Dit is misschien wel de meest correcte manier om het op te lossen, omdat... Het is beter om ACL's zo dicht mogelijk bij de extensie te binden voor een nauwkeurigere afstemming. Die. U kunt een specifiek adres/netwerkadres van de telefoon registreren waarmee u een uitgaande oproep kunt plaatsen. Het nadeel van deze optie is dat elke Extensie dit zal moeten doen.
- Corrigeer de ACL zodat deze correct werkt op profielniveau. Ik heb voor deze optie gekozen, omdat het mij gemakkelijker leek om het netwerk één keer aan de ACL toe te voegen dan het in elke extensie te registreren. Maar dit is specifiek voor mijn taak. Voor andere taken kan een andere beslissingslogica nodig zijn.
Dus. Laten we ACL-domeinen als volgt corrigeren:
domeinen standaardactie: toestaan
We registreren het netwerk in de ACL-lijst van domeinen:
ontkennen 192.168.0.0/24
Wij solliciteren, herladen.
Laten we het testen: bel opnieuw het nummer 98343379xxxx en... er is een controlepunt... HALLO. Alles werkt.
Laten we eens kijken wat er gebeurde in FreeSWITCH:
het gesprek begint:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.localACL werd niet gemist:
[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/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]d{6})$/ break=on-false De routering is voltooid en vervolgens wordt de verbinding tot stand gebracht, wat buiten het bestek van dit onderwerp valt.
Als we het netwerkadres in de ACL wijzigen, maar de afbeelding krijgen van de eerste test, d.w.z. De ACL mist de oproep en de routering zegt NO_ROUTE_DESTINATION.
Dat is waarschijnlijk alles wat ik wilde toevoegen aan ACL FusionPBX.
Ik hoop dat het nuttig is voor iemand.
Bron: www.habr.com
