Il mio articolo non è una descrizione completa del prodotto, ma solo un piccolo chiarimento su una buona pubblicazione "FusionPBX, ovvero eccoci di nuovo, FreeSWITCH". Mi sembra che non venga approfondito in modo adeguato il tema dell'ACL in FusionPBX. Proverò a colmare questa lacuna basandomi sulla mia esperienza con FreeSWITCH/FusionPBX.
Abbiamo dunque installato FusionPBX con il numero interno registrato 1010 nel dominio domain.local e un percorso configurato per le chiamate esterne in città. Utilizziamo l'ACL per proteggere il nostro sistema telefonico da chiamate non autorizzate che potrebbero farci perdere denaro. In altre parole, consentiamo uscite solo dalle reti descritte nell'ACL. È fondamentale avere una chiara comprensione di come funziona l'ACL in FusionPBX, le sue caratteristiche, la logica e il punto di collegamento.
Come il rispettabile autore dell'articolo sopra citato, sono anch'io incappato in tutte le difficoltà legate all'ACL.
Inizierò con 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 cui ci concentreremo. Nel profilo internal è collegata una lista ACL domains come apply-inbound-acl. Questa riga è responsabile del funzionamento dell'ACL a livello di profilo. Per ora, tutto chiaro sui profili.
Contesto
Il contesto, oltre ad altre funzioni, è utilizzato per il routing delle chiamate. Tutti i percorsi in entrata sono legati al contesto Public.
I percorsi in uscita (per città, cellulari, interurbani, internazionali e qualsiasi altro) si trovano (di default) nel contesto del nome di dominio (chiameremo questo domain.local).
ACL
Ora analizziamo l'ACL. Di default, nella FusionPBX appena installata, ci sono due liste ACL:
domains azione predefinita: deny — questa lista è collegata al profilo internal
lan azione predefinita: allow
Nella lista ACL domains indichiamo la rete (per esempio, 192.168.0.0/24), concediamo a questa rete il permesso allow e applichiamo reloadacl.
Poi registriamo un telefono da questa rete, e sembra tutto a posto secondo le istruzioni e logico.
Iniziamo a testare, facciamo una chiamata a un numero esterno e... otteniamo un bublik, o meglio, un buco nel bublik. Inaspettatamente!
Iniziamo ad analizzare il log nella console o attraverso il Log Viewer di FusioPBX.
Possiamo vedere la nostra chiamata:
switch_channel.c:1104 Nuovo canale sofia/internal/1010@domain.localPossiamo osservare 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 rotta, annullamento
switch_core_state_machine.c:312 Chiusura sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION] Nessuna rotta! Anche se la rotta è correttamente configurata.
La risposta è in realtà semplice.
La chiamata è arrivata. L'ACL l'ha consentita. E poiché l'ACL è legato al profilo interno, e questo profilo si trova nel contesto pubblico, FreeSWITCH controlla la routing nel contesto pubblico. Ma nel contesto pubblico esiste solo la routing in entrata, e il sistema ci informa correttamente che non ci sono rotte verso la città.
Dalla situazione attuale ci sono almeno due uscite.
- Collegare questo ACL non al profilo, ma al numero interno stesso. Questo può essere il modo più appropriato per risolvere, poiché è meglio collegare l'ACL il più vicino possibile all'Extension per una configurazione più dettagliata. Ovvero, è possibile specificare un indirizzo specifico/rete del telefono da cui potrà effettuare chiamate in uscita. Il contro di questa opzione è che bisognerà farlo in ogni Extension.
- Correggere l'ACL in modo che funzioni correttamente a livello di profilo. Ho scelto questa opzione perché mi sembrava più semplice aggiungere una volta la rete nell'ACL piuttosto che scriverla in ogni Extension. Ma questo è specifico per il mio obiettivo. Per altri compiti, potrebbe essere necessaria una logica decisionale diversa.
Quindi, correggeremo l'ACL dei domini nel seguente modo:
azione di default dell'ACL dei domini: allow
Nell'elenco ACL dei domini scriviamo la rete:
deny 192.168.0.0/24
Applichiamo, reloadacl.
Testiamo: digitiamo di nuovo il numero 98343379xxxx e… sta arrivando la chiamata… PRONTO. Funziona tutto.
Vediamo cosa è successo in FreeSWITCH:
la chiamata inizia:
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 dall'ACL "domini". 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 La routazione è avvenuta, e poi inizia l'instaurazione della connessione, che esula dall'argomento.
Se cambiamo l'indirizzo della rete nell'ACL, ma otteniamo il risultato della prima prova, cioè l'ACL permetterà la chiamata e la routazione dirà NO_ROUTE_DESTINATION.
Probabilmente è tutto ciò che volevo aggiungere riguardo l'ACL di FusionPBX.
Spero che possa essere utile a qualcuno.
Fonte: habr.com
