Il mio articolo non è una descrizione completa del prodotto, ma solo un leggero miglioramento della buona pubblicazione "FusionPBX o, ancora una volta, fantastico, FreeSWITCH". Mi sembra che l'argomento ACL in FusionPBX non sia molto ben spiegato in esso. Cercherò di colmare questa lacuna basandomi sulla mia esperienza con FreeSWITCH/FusionPBX.
E così, abbiamo installato un FusionPBX con un numero interno registrato 1010 nel dominio domain.local e un percorso configurato per le chiamate esterne verso la città. Utilizziamo ACL per proteggere il nostro sistema di telefonia da chiamate non autorizzate che ci porteranno via i soldi. Quelli. solo dalle reti descritte nell'ACL consentono le chiamate in uscita. E qui è necessaria una comprensione completamente chiara di come funziona ACL in FusionPBX, delle sue caratteristiche, della logica e del suo punto di ancoraggio.
Come l'autorevole autore dell'articolo di cui sopra, anch'io ho calpestato tutti i rastrelli relativi all'ACL.
Inizierò con SipProfiles.
Entrambi i profili (li chiamerò così), sia quelli interni che quelli esterni, sono nel contesto Pubblico, e questo non è casuale. La registrazione dei numeri avviene nel profilo interno e presteremo attenzione ad esso. Nel profilo interno, l'ACL dei domini è associato come apply-inbound-acl. È questa linea che è responsabile del funzionamento dell'ACL a livello di profilo. Finora è tutto con i profili.
Contesto
Il contesto viene utilizzato, tra le altre cose, nell'instradamento delle chiamate. Tutti i percorsi in entrata sono vincolati al contesto pubblico.
I percorsi in uscita (verso la città, verso il cellulare, a lunga distanza, internazionali e qualsiasi altro) sono (per impostazione predefinita) nel contesto di un nome di dominio (chiamiamolo dominio.local).
ACL
Ora occupiamoci degli ACL. Per impostazione predefinita, un FusionPBX appena installato ha due ACL:
azione predefinita del dominio: nega - questo foglio è associato al profilo interno
azione predefinita lan: consenti
Nell'elenco ACL dei domini, prescriviamo la rete (beh, ad esempio, 192.168.0.0/24), concediamo l'autorizzazione di autorizzazione per questa rete, utilizziamo reloadacl.
Successivamente, registriamo il telefono da questa rete e tutto sembra andare bene, secondo le istruzioni e logicamente.
Iniziamo il test, facciamo una chiamata ad un numero esterno e... otteniamo una ciambella, anzi un buco di ciambella. All'improvviso!
Iniziamo ad analizzare il log in console o tramite il Log Viewer FusioPBX.
Vediamo la nostra sfida:
switch_channel.c:1104 New Channel sofia/internal/[email protected]Vediamo l'ACL che ha funzionato:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.E inoltre:
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] Nessun percorso! Anche se il percorso lo abbiamo onestamente registrato.
La risposta è davvero semplice.
La chiamata è arrivata. ACL l'ha mancato. E poiché l'ACL è vincolato nel profilo interno e questo profilo è nel contesto pubblico, FreeSWITCH esamina onestamente il routing nel contesto pubblico. Ma nel contesto pubblico, solo percorsi in entrata, e il sistema ci dice onestamente che lì non ci sono percorsi per la città.
Ci sono almeno due vie d’uscita da questa situazione.
- Allega questo ACL non al profilo, ma al numero interno stesso. Questo potrebbe essere il modo più corretto per risolvere, perché. È meglio associare l'ACL il più vicino possibile all'estensione per una regolazione più precisa. Quelli. è possibile prescrivere un indirizzo/indirizzo di rete specifico del telefono dal quale può effettuare una chiamata in uscita. Lo svantaggio di questa opzione è che ogni interno dovrà farlo.
- Correggi l'ACL in modo che funzioni correttamente a livello di profilo. Ho scelto questa opzione perché mi sembrava più semplice aggiungere la rete all'ACL una volta piuttosto che prescriverla in ciascuna estensione. Ma questo è specifico per il mio compito. Per altri compiti, potresti aver bisogno di una logica decisionale diversa.
COSÌ. Correggiamo i domini ACL come segue:
azione predefinita dei domini: consenti
Nell'elenco ACL dei domini, registriamo la rete:
negare 192.168.0.0/24
Applica, ricarica.
Stiamo testando: componiamo nuovamente il numero 98343379xxxx e... il posto di blocco sta arrivando... CIAO. Tutto funziona.
Vediamo cosa è successo in FreeSWITCH:
inizia la chiamata:
switch_channel.c:1104 New Channel sofia/internal/[email protected]ACL non ha mancato:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.e inoltre:
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 Il routing è passato e poi arriva la creazione della connessione, che va oltre lo scopo dell'argomento.
Se modifichiamo l'indirizzo di rete nell'ACL, ma otteniamo l'immagine dal primo test, ad es. L'ACL salterà la chiamata e il routing dirà NO_ROUTE_DESTINATION.
Questo è probabilmente tutto ciò che volevo aggiungere su ACL FusionPBX.
Spero che sarà utile a qualcuno.
Fonte: habr.com