Mijn artikel is geen volledige productbeschrijving, maar slechts een kleine aanvulling op de goede publicatie 'FusionPBX, of opnieuw, FreeSWITCH'. Ik denk dat het onderwerp ACL in FusionPBX daar niet goed wordt belicht. Ik zal proberen deze leemte op te vullen, gebaseerd op mijn eigen ervaring met FreeSWITCH/FusionPBX.
Dus, we hebben FusionPBX geïnstalleerd met een geregistreerd intern nummer 1010 in het domein domain.local en een route ingesteld voor externe oproepen naar het vastennet. We gebruiken ACL om ons telefoniesysteem te beschermen tegen ongeoorloofde oproepen die onze portemonnee doen lijden. Dat wil zeggen, alleen uit de netwerken beschreven in de ACL zijn uitgaande oproepen toegestaan. En hier is een duidelijke begrip nodig van hoe ACL in FusionPBX werkt, zijn kenmerken, logica en het punt waarop het is verbonden.
Net als de gerespecteerde auteur van het bovengenoemde artikel ben ik ook in alle valkuilen gestapt die met ACL te maken hebben.
Laten we beginnen met SipProfiles.
Beide profielen (ik zal ze zo noemen), zowel internal als external, bevinden zich in de context Public, en dat is geen toeval. Registratie van nummers gebeurt in het profiel internal, daar zullen we onze aandacht op richten. In het profiel internal is de ACL-lijst domains als apply-inbound-acl gekoppeld. Deze regel is verantwoordelijk voor de werking van ACL op profielniveau. Tot nu toe is alles goed met de profielen.
Context
De context wordt, naast alles, gebruikt voor het routeren van oproepen. Alle inkomende routes zijn gekoppeld aan de context Public.
Uitgaande (naar het vastenet, naar mobiele telefoons, interlokale, internationale en andere) routes bevinden zich (standaard) in de context van de naam domein (laten we het domain.local noemen).
ACL
Laten we nu eens kijken naar de ACL. Standaard is er in de net zojuist geïnstalleerde FusionPBX twee ACL-lijsten:
domains standaardactie: deny — deze lijst is gekoppeld aan het profiel internal
lan standaardactie: allow
In de ACL-lijst domains schrijven we het netwerk (bijvoorbeeld 192.168.0.0/24), geven we dit netwerk de permissie allow, en passen we reloadacl toe.
Daarna registreren we de telefoon uit dit netwerk, en lijkt alles goed te gaan volgens de instructies en logisch.
We beginnen met testen, doen een oproep naar een extern nummer en… we krijgen een zak, of beter gezegd een gat in de zak. Verrassend!
We beginnen de log in de console of via de Log Viewer van FusioPBX te analyseren.
We zien onze oproep:
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 Verwerkt 1010 ->98343379xxxx in context public
switch_core_state_machine.c:311 Geen Route, Afgebroken
switch_core_state_machine.c:312 Hangup sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION] Geen route! Hoewel de route eerlijk is opgegeven.
Het antwoord is eigenlijk eenvoudig.
De oproep kwam binnen. ACL heeft deze doorgelaten. Aangezien de ACL is gekoppeld aan het profiel internal, en dit profiel zich in de context public bevindt, kijkt FreeSWITCH eerlijk naar de routering in de context public. Maar in de context public is er alleen inkomende routering, en het systeem zegt eerlijk dat er daar geen routes naar de stad zijn.
Er zijn in deze situatie minstens twee oplossingen.
- Koppel deze ACL niet aan het profiel, maar aan het interne nummer zelf. Dit kan de beste oplossing zijn, aangezien ACL's beter zo dicht mogelijk bij de Extension kunnen worden gekoppeld voor fijnere afstemming. Dat wil zeggen, je kunt een specifiek adres/netwerk van de telefoon opgeven dat de uitgaande oproep kan doen. Het nadeel van deze optie is dat dit in elke Extension gedaan moet worden.
- Pas de ACL aan zodat deze correct werkt op profielniveau. Ik heb deze optie gekozen omdat het me eenvoudiger leek om een netwerk één keer aan de ACL toe te voegen dan het in elke Extension op te nemen. Maar dat is specifiek voor mijn taak. Voor andere taken kan er misschien andere besluitvorming nodig zijn.
Zo. Laten we de ACL domains als volgt aanpassen:
domänen standaardactie: toestaan
In de ACL-lijst domains voegen we het netwerk toe:
deny 192.168.0.0/24
Toepassen, reloadacl.
Testen: bel opnieuw het nummer 98343379xxxx en… er komt een antwoord… HALLO. Alles werkt.
Laten we zien wat er gebeurde in FreeSWITCH:
de oproep begint:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.localACL heeft niet doorgelaten:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Weigert door acl "domains". Terugvallen op Digest-authenticatie.en verder:
mod_dialplan_xml.c:637 Verwerkt 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 geslaagd, en vervolgens begint de verbinding die buiten het onderwerp valt.
Als we het netwerkadres in de ACL wijzigen, zullen we echter dezelfde situatie krijgen als bij de eerste test, dat wil zeggen dat de ACL de oproep doorlaat en de routering zegt NO_ROUTE_DESTINATION.
Dat is waarschijnlijk alles wat ik wilde toevoegen aan de ACL FusionPBX.
Ik hoop dat iemand er iets aan heeft.
Bron: habr.com
