Perché il Firewall Checker non mente
Il 3CX dispone di un controllo automatico del firewall che convalida la configurazione del firewall in termini di "Inoltro delle porte" e di "Conservazione della porta".
Inoltro delle porte
Il 3CX controllerà se il "Full Cone NAT" è impostato correttamente sul dispositivo firewall/gateway. Il Full Cone NAT permette a qualsiasi entità esterna di connettersi al 3CX senza che il firewall debba confermare che il pacchetto provenga dal 3CX prima di permettere la connessione. Questo è molto importante soprattutto per i Provider VoIP, in quanto il server SIP non è lo stesso server (indirizzo IP di origine) che fornirà l'audio finale al sistema. In alcuni casi, l'implementazione del firewall imposta il traffico in entrata "non consentito" in una lista di negazione, che impedisce la connessione alla destinazione anche se il 3CX inizia a inviare dati (audio) alla sua destinazione.
Conservazione della porta
La conservazione delle porte è un altro fattore chiave che viene controllato dal firewall checker. Rileva se il firewall altera la porta durante la traduzione da IP LAN a IP WAN. Tecnicamente non dovrebbe essere importante, ma dipende dall'implementazione del provider se risponde alla porta di trasporto del 3CX vista nell'intestazione UDP piuttosto che a quella definita dalla RFC. La RFC definisce che un server SIP DEVE rispondere all'IP e alla porta del "contatto" definiti nel contenuto del messaggio SIP. Per eliminare eventuali "forse", il firewall checker convalida anche questa mappatura. È necessario che se un messaggio SIP è generato localmente dal 3CX dalla porta sorgente 5060 (porta SIP predefinita) e poi tradotto all'indirizzo IP pubblico (IP WAN) la porta, in questo caso 5060, rimanga invariata.
Per fare questo, il controllore del firewall eseguirà due test indipendenti con il primo server STUN configurato nel sistema. Per impostazione predefinita, questo è impostato su stun.3cx.com. Si raccomanda vivamente di non modificarlo. In generale, il verificatore del firewall è un modo programmatico per rilevare l'indirizzo IP pubblico, simile all'utilizzo di un sito web come "qual è il mio IP", ma è esteso per controllare anche la porta.
Esempi
Di seguito è riportato un controllo firewall fallito segnalato dalla console di gestione 3CX e una corrispondente cattura wireshark del flusso. In questa guida elaboreremo i passi compiuti dal controllore del firewall e mostreremo i risultati. La cattura wireshark è limitata a mostrare solo la "porta 3378 o 3379", su cui si è basato questo test. Per il firewall checker è importante che il firewall di Windows sia disattivato. L'installazione di 3CX crea eccezioni per alcune applicazioni 3CX, ma non per il firewall checker stesso!
Test 1
Il 3CX arresta i servizi per liberare la porta locale e collegarla al firewall checker. Questo documento si concentra solo sulla prima porta testata (5060), ma la procedura è la stessa per tutte le altre porte.
L'immagine qui sopra mostra i seguenti passi:
- Il server 3CX locale con indirizzo IP 192.168.3.159, invia una richiesta classica di stun a stun.3cx.com con IP 198.50.247.220.
- Dalla porta locale 5060 UDP.
- Alla 3478, che è la porta predefinita del server stun.
- Dichiarando che il server STUN NON deve cambiare il suo IP o la porta per rispondere a questa richiesta.
Ogni richiesta ha un "ID transazione" unico per garantire in modo affidabile che i dati ricevuti appartengano alla richiesta iniziale. In rari casi si può notare che il server invia più richieste ma non riceve mai una risposta, come mostrato di seguito. Ciò implica che:
a) il traffico in uscita è stato bloccato dal firewall o b) non è stata inviata alcuna risposta al server. In entrambi i casi, controllare le impostazioni del firewall!
Il server Stun risponde quindi con:
- Una risposta vincolante alle richieste
- Definisce quindi che l'IP pubblico e la porta da cui è stata inviata la richiesta sono uguali alla porta 5060 e l'indirizzo IP è XX.XX.96.162.
In base alla definizione precedente, la conservazione della porta funziona in quanto il server STUN può vedere il PBX sulla porta definita. Se nel campo "Mapped-Address" viene visualizzata un'altra porta, il controllo del firewall fallirà e la conservazione delle porte NON funzionerà correttamente.
Test 2
Nel test 2 il server invierà una richiesta allo stesso server di stordimento di prima.
Tuttavia,
- Il server 3CX contrassegna la richiesta come diversa da quella precedente e imposta "Cambia IP e Cambia porta" su (1). Questo significa che il server stun dovrebbe inviare la sua risposta al 3CX da un indirizzo IP e da una porta che ora sono sconosciuti al firewall che si aspetta una risposta alla richiesta.
- È chiaro che il server ha inviato la stessa richiesta 3 volte senza ottenere una risposta dal server stun. Ciò indica che il full cone NAT non funziona.
Rispetto al test 1, dove il server 3CX invia attivamente i dati allo stun server e riceve una risposta, il test 2 mostra che i dati ritornano da una fonte con cui il 3CX non ha mai parlato (cioè il server audio di un provider VoIP) e non è stato in grado di ricevere alcuna risposta. In questo caso, contattare il produttore del firewall per risolvere il problema.
La risposta corretta sarebbe quella di ricevere i dati nel secondo test in cui il "Mapped-Address" è esattamente lo stesso del test 1 per IP e Porta.
Se volete vedere da dove dovrebbe provenire il traffico, controlla i log del tuo firewall per gli indirizzi IP dei server 3CX stun. Ci si aspettava che la risposta provenisse dai server stun 3CX, ma non è mai arrivata al NIC di 3CX.
Test SIP ALG (dalla V15.5 SP1)
Oltre al test NAT esistente, il 3CX valuta se il firewall ha abilitato il SIP ALG. Il SIP ALG, in breve, è una funzione presente in alcuni dispositivi firewall che ispeziona, oltre alla lista di accesso IP/Porte da e verso, il contenuto dei pacchetti. In questo caso SIP. Per l'amministratore del 3CX questo può causare numerosi problemi e, a causa del fatto che le modifiche ai messaggi SIP sono apportate da un hop intermedio, le tracce effettuate sul 3CX non mostreranno tali modifiche. Tuttavia, possono causare problemi di incompatibilità con i telefoni IP o i provider VoIP remoti.
Convalida: Il 3CX genera un messaggio INVITE generico e lo invia a un servizio online ospitato dal 3CX. A parte l'indirizzo IP pubblico, tutte le altre informazioni sono rese generiche.
Il 3CX locale genera un valore di hash CRC32 dal messaggio inviato e si aspetta in cambio una risposta dal servizio cloud che l'hash abbia lo stesso valore.
Se il valore di ritorno di "X-CSREQ" corrisponde al valore calcolato localmente, si prevede che SIP ALG non abbia manomesso il messaggio o che non sia presente. Se i valori non corrispondono, il test mostra che un passaggio tra il 3CX e il servizio online ha alterato il contenuto = SIP ALG.
Su base di convalida, è possibile calcolare il valore di hash previsto, dato che wireshark ha catturato l'INVITE in uscita verso il servizio di rilevamento SIP ALG.
Fare clic con il pulsante destro del mouse sull'invito inviato da 3CX, Copia, Bytes, Hex Stream. Aprire: http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
E incollare il flusso esadecimale copiato nei dati di ingresso CRC.
Il risultato dato deve corrispondere al valore restituito.
Ultimo aggiornamento
Questo documento è stato aggiornato l'ultima volta il 25 gennaio 2019
Sistema Telefonico 
