Il mio articolo non è una descrizione completa del prodotto, ma solo un piccolo chiarimento su una buona pubblicazione intitolata "FusionPBX, o di nuovo in forma, FreeSWITCH". Credo che in essa il tema ACL in FusionPBX non sia molto ben delineato. Proverò a colmare questa lacuna, basandomi sulla mia esperienza lavorativa con FreeSWITCH/FusionPBX.
Quindi, abbiamo installato FusionPBX con il numero interno registrato 1010 nel dominio domain.local e un percorso impostato per le chiamate esterne in città. Utilizziamo l'ACL per proteggere il nostro sistema telefonico dalle chiamate non autorizzate che potrebbero portare via i nostri soldi. Cioè, consentire le chiamate in uscita solo dalle reti descritte nell'ACL. Qui è necessario avere una comprensione chiara di come funziona l'ACL in FusionPBX, le sue caratteristiche, la logica e il punto di attacco.
Come l'autore rispettato dell'articolo sopra citato, anch'io ho incontrato tutte le difficoltà legate all'ACL.
Comincerò da SipProfiles.
Entrambi i profili (li chiamerò così), sia internal che external, si trovano nel contesto Public, e non è un caso. La registrazione dei numeri avviene nel profilo internal, su di esso ci concentreremo. Nel profilo internal è collegata la lista ACL domains come apply-inbound-acl. Proprio questa riga è responsabile del funzionamento dell'ACL a livello di profilo. Finora per i profili è tutto.
Context
Il contesto, tra le altre cose, è utilizzato per la routizzazione delle chiamate. Tutti i percorsi in ingresso sono vincolati al contesto Public.
I percorsi in uscita (verso la città, cellulari, lunghe distanze, internazionali e altri) si trovano (per impostazione predefinita) nel contesto nome di dominio (chiamiamolo domain.local).
ACL
Ora approfondiamo l'ACL. Per impostazione predefinita, in FusionPBX appena installato ci sono due liste ACL:
domains azione predefinita: deny — questa lista è legata al profilo internal
lan azione predefinita: allow
Nella lista ACL domains inseriamo la rete (per esempio 192.168.0.0/24), diamo a questa rete un permesso allow, applichiamo reloadacl.
Poi registriamo un telefono da questa rete, e sembrerebbe che vada tutto bene e sia logico.
Iniziamo a testare, facciamo una chiamata a un numero esterno e… riceviamo un segnale vuoto, o meglio, un buco. Inaspettato!
Iniziamo ad analizzare i log nella console o tramite Log Viewer FusioPBX.
Vediamo la nostra chiamata:
switch_channel.c:1104 Nuovo Canale sofia/internal/1010@domain.localVediamo l'ACL attivato:
sofia.c:10208 IP 192.168.0.150 Approvato da acl "domains[]". Accesso Consentito.E poi:
mod_dialplan_xml.c:637 Elaborazione 1010 ->98343379xxxx nel contesto pubblico
switch_core_state_machine.c:311 Nessuna Route, Aborting
switch_core_state_machine.c:312 Hangup sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION] Nessuna route! Anche se la route è correttamente definita.
La risposta è in realtà semplice.
La chiamata è arrivata. L'ACL l'ha permessa. E dato che l'ACL è legato al profilo interno, e questo profilo si trova nel contesto pubblico, FreeSWITCH controlla onestamente il routing nel contesto pubblico. Ma nel contesto pubblico esiste solo il routing in entrata, e il sistema ci dice che non ci sono rotte in città.
Dalla situazione attuale ci sono almeno due uscite.
- Collegare questo ACL non al profilo, ma al numero interno stesso. Questo potrebbe essere il modo più giusto per risolvere, poiché è meglio legare gli ACL il più vicino possibile all'Extension per una configurazione più fine. Cioè, è possibile specificare un indirizzo specifico/rete telefonica da cui sarà possibile effettuare una chiamata. Il problema di questa opzione è che sarà necessario farlo per ogni Extension.
- Correggere l'ACL in modo che funzioni correttamente a livello di profilo. Ho scelto proprio questa opzione, poiché aggiungere una rete all'ACL mi è sembrato più semplice che scriverla in ogni Extension. Ma questo è specifico per il mio compito. Per altri compiti, potrebbe essere necessaria una logica decisionale diversa.
Quindi. Correggiamo l'ACL domains nel seguente modo:
domini azione predefinita: consentire
Nell'elenco ACL domains scriviamo la rete:
deny 192.168.0.0/24
Applichiamo, reloadacl.
Testiamo: componiamo di nuovo il numero 98343379xxxx e… c'è un feedback… PRONTO. Funziona tutto.
Vediamo cosa è successo in FreeSWITCH:
inizia la chiamata:
switch_channel.c:1104 Nuovo Canale sofia/internal/1010@domain.localL'ACL non ha permesso:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rifiutato da acl "domains". Passando all'autenticazione Digest.e poi:
mod_dialplan_xml.c:637 Elaborazione 1010 ->98343379xxxx nel contesto domain.local
sofia/internal/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]d{6})$/ break=on-false Il routing è avvenuto, e poi inizia l'instaurazione della connessione, che esula dall'argomento.
Se cambiamo l'indirizzo di rete nell'ACL, otterremo lo scenario del primo test, ovvero l'ACL permetterà la chiamata e il routing dirà NO_ROUTE_DESTINATION.
Ecco probabilmente tutto ciò che volevo aggiungere riguardo l'ACL FusionPBX.
Spero sia utile a qualcuno.
Fonte: habr.com
