Vai al contenuto
Avanet

Sophos Firewall Risolvi i problemi VoIP con SIP e RTP

I problemi VoIP dietro un Sophos Firewall hanno spesso un effetto diffuso: i telefoni non si registrano, le chiamate cadono, squilla senza audio o la voce si sente solo in una direzione. In pratica, la causa è raramente dovuta ad un singolo interruttore. La segnalazione SIP, il flusso multimediale RTP, il NAT, le regole del firewall, i timeout UDP o il routing di solito lavorano insieme.

L’articolo classifica la risoluzione dei problemi VoIP su Sophos Firewall come un processo strutturato. Restano importanti le misure immediate note come la disattivazione del SIP Helper o l’aumento del timeout UDP. Tuttavia, tali modifiche non dovrebbero essere apportate alla cieca, ma piuttosto come parte di un processo pulito di risoluzione dei problemi.

Cosa attraversa il firewall con VoIP

Il VoIP è composto grosso modo da due parti:

  • SIP: controlla la registrazione, l’impostazione delle chiamate, la cancellazione delle chiamate e la negoziazione dei parametri multimediali. Errori tipici includono la registrazione non riuscita, le chiamate non stabilite o i dialoghi SIP rifiutati dal provider.
  • RTP: trasporta i dati vocali durante la conversazione. Gli errori tipici includono audio mancante, audio unilaterale o interruzione dell’audio dopo un breve periodo di tempo.SIP viene spesso eseguito su UDP o TCP 5060, con SIP crittografato spesso su 5061. Ma questa non è una legge. Molti provider utilizzano porte proprie, server proxy propri o requisiti aggiuntivi per i keepalive NAT.

RTP utilizza normalmente gli intervalli di porte UDP specificati dal provider, dal sistema telefonico o dai dispositivi finali. Per un’analisi pulita sono necessari i server SIP specifici, gli intervalli di porte RTP e i protocolli di trasporto del provider o la documentazione del PBX.

Classificare correttamente i sintomi

Prima di apportare qualsiasi modifica, è necessario classificare il sintomo nel modo più accurato possibile.

  • La registrazione non riesce: controlla DNS, routing, regola firewall, NAT, credenziali del provider o trasporto SIP.
  • La chiamata non si connette: Controllare la segnalazione SIP, la regola del firewall, Application Control ed eventuali blocchi del provider.
  • La chiamata funziona ma non c’è audio: Controlla l’intervallo di porte RTP, NAT, percorso di ritorno, SD-WAN e SIP Helper.
  • L’audio è udibile solo in una direzione: Controlla il percorso di ritorno RTP, NAT, routing, VPN e SD-WAN.
  • La conversazione si interrompe dopo 30, 60 o 120 secondi: Controlla il timeout UDP, il keepalive NAT, l’aggiornamento della sessione e le aspettative del provider.
  • Solo le chiamate in entrata non funzionano: Controlla DNAT, regola firewall, reti di origine del provider e condivisione porta PBX.
  • Solo una linea WAN causa problemi: Controlla il percorso SD-WAN, il percorso di risposta, il gateway e il collegamento IP del provider.

Questa classificazione impedisce di modificare le impostazioni SIP anche se il problema reale risiede nel percorso di ritorno RTP o in un percorso SD-WAN.

Controlla prima di apportare modifiche

Prima di apportare modifiche alla CLI, dovresti documentare lo stato attuale:

  • Quali telefoni, PBX o SBC sono interessati?
  • I dispositivi finali si registrano direttamente presso il provider o tutto funziona tramite un sistema telefonico interno?
  • Quali server SIP e intervalli di porte RTP nomina il provider?
  • Quale regola del firewall elabora il traffico VoIP?
  • Log firewall traffic è abilitato in questa regola?
  • Quale regola NAT si applica al traffico VoIP in uscita e in entrata?
  • Sono presenti più linee WAN, percorsi SD-WAN o VPN basate su percorsi?
  • Il problema è diventato visibile dopo un aggiornamento del firmware, un cambio di provider o un aggiornamento del PBX?

Testare le regole del firewall su Sophos Firewall aiuta nell’analisi delle regole. Per il flusso di pacchetti effettivo, Packet Capture in WebAdmin è solitamente più significativo di un puro test di policy.

Controlla l’Assistente SIP

Il SIP Helper, spesso chiamato anche SIP ALG, tenta di riconoscere i pacchetti SIP e di adattare le informazioni SIP rilevanti per NAT. Questo può aiutare in ambienti semplici. Tuttavia, può anche essere dannoso in molte moderne configurazioni VoIP con provider SBC, proprio PBX, TLS, clean NAT keepalive o intervalli di porte RTP più complessi.

Ecco perché SIP Helper è un utile punto di prova, ma non una soluzione generale permanente per ogni problema.I comandi vengono eseguiti tramite SSH sul Sophos Firewall. Per fare ciò, connettersi al firewall e selezionare 4. Device Console. L’accesso SSH dovrebbe essere consentito solo da reti attendibili. Le basi sono in Connettersi a Sophos Firewall tramite SSH.

Mostra lo stato attuale del modulo:

system system_modules show

Disattiva il modulo SIP:

system system_modules sip unload

Riattivare il modulo SIP:

system system_modules sip load

⚠️ Questa modifica dovrebbe essere apportata in una finestra di manutenzione o con test chiaramente definiti. Dopo aver disabilitato o abilitato, la registrazione, le chiamate in uscita, le chiamate in entrata e l’audio devono essere controllati in entrambe le direzioni.

Se il cambiamento non aiuta, dovresti riprenderlo. È importante documentare la condizione prima e dopo il test.

Controlla e regola il timeout UDP

Il VoIP utilizza spesso UDP. Se le voci NAT o di sessione scadono troppo presto, la registrazione potrebbe sembrare funzionare, ma le chiamate si interrompono o le chiamate in entrata non raggiungono il PBX in modo affidabile.

Lo stato attuale del firewall avanzato viene visualizzato in Device Console:

show advanced-firewall
Valore del flusso di timeout UDP su Sophos Firewall
Il valore del flusso di timeout UDP deve essere documentato prima di qualsiasi modifica.

Un valore di test comune è 180 secondi:```shell set advanced-firewall udp-timeout-stream 180


> ⚠️ `udp-timeout-stream` non è un'opzione di puro controllo VoIP, ma ha un effetto più ampio sulle sessioni UDP. Il valore non deve essere impostato arbitrariamente alto. È meglio avere un test definito con la documentazione del vecchio valore, i requisiti del fornitore e il successivo controllo della sessione e della qualità della voce.

Se il provider o l'impianto telefonico supporta NAT Keepalive, è opportuno verificare anche questa impostazione. Un keepalive pulito sul PBX o sul lato del provider è spesso migliore di un valore di timeout globale molto elevato.

## Controlla le regole del firewall e il NAT

NAT è spesso coinvolto nei problemi VoIP. Sophos Firewall non deve solo consentire SIP, ma anche tradurre e restituire correttamente i flussi RTP associati in entrambe le direzioni.

Questi punti sono generalmente rilevanti per i telefoni in uscita o un PBX interno:

- regola firewall appropriata dalla zona VoIP o zona PBX alla WAN
- regola SNAT o MASQ appropriata
- Accesso alla regola del firewall
- nessuna regola troppo larga o posizionata erroneamente sopra la regola VoIP
- nessun filtraggio imprevisto Application Control, IPS o web su questo trafficoVengono aggiunti ulteriori punti per i trunk SIP in entrata o i sistemi telefonici pubblicati:

- DNAT al PBX interno o SBC
- Regola firewall con zona di destinazione e rete di destinazione appropriate
- Limitazione alle reti di origine del provider, se possibile
- richieste solo porte SIP e RTP
- Registrazione e Packet Capture per test

Una regola NAT non consente il traffico, ma traduce solo indirizzi o porte. I collegamenti sono spiegati in [Comprendere il NAT su Sophos Firewall](/it/kb/sophos-firewall-nat-basics/). Se un centralino deve essere accessibile da Internet, [Pubblica il server tramite DNAT](/it/kb/sophos-firewall-server-dnat/) è la base migliore per la pubblicazione vera e propria.

## Analizza l'RTP e la direzione del linguaggio

Se la chiamata viene stabilita ma manca l'audio, SIP solitamente non è più il problema principale. Quindi devi verificare se l'RTP scorre in entrambe le direzioni.

Processo tipico:

1. Prendere nota dell'intervallo di porte RTP del provider o del PBX.
2. Avviare Packet Capture con l'IP di origine del PBX o del telefono e l'intervallo di porte RTP.
3. Effettuare una chiamata di prova.
4. Verificare se i pacchetti UDP dal dispositivo interno al provider sono visibili.
5. Controllare se i pacchetti UDP ritornano dal provider.
6. Confronta NAT ID, Rule ID, In interface e Out interface.Se RTP è visibile solo in uscita ma non ritorna nulla, il problema potrebbe risiedere nel provider, nel percorso di ritorno, nel NAT o in una stazione remota a monte. Se RTP ritorna ma non viene inoltrato al PBX, è più probabile che siano presenti regole firewall, DNAT, routing o mappatura delle zone.

Per registrazioni più precise o esportazioni PCAP può essere utile `tcpdump` via SSH. Il processo è descritto in [Sophos Firewall Utilizza tcpdump per log e analisi](/it/kb/sophos-firewall-raccogliere-i-log-dello-strumento-tcpdump/).

## SD-WAN, VPN e linee WAN multiple

Il VoIP è sensibile ai percorsi asimmetrici. Se SIP viene eseguito su una linea WAN ma RTP ritorna su una linea diversa o una VPN basata su route viene instradata in modo diverso, si verificano errori tipici come l'audio unilaterale.

Un bug risolto in SFOS 22.0 MR1 mostra la connessione tipica: dopo un aggiornamento a SFOS 22.0 GA, l'audio VoIP poteva funzionare solo unidirezionale su VPN basata su percorso con routing SD-WAN. In pratica ciò significa: la SD-WAN dovrebbe essere sempre controllata quando si utilizza VoIP su VPN o più percorsi WAN.

Punti di controllo importanti:

- Un percorso SD-WAN accede al traffico VoIP?
- SIP e RTP vengono instradati sulla stessa linea WAN prevista?
- Esistono specifiche del provider relative all'IP di origine o all'indirizzo pubblico del mittente?
- Viene utilizzata una route VPN basata su route con un'interfaccia XFRM?
- I percorsi di ritorno e il NAT corrispondono al percorso scelto?
- Packet Capture presenta gateway o interfacce diverse per l'andata e il ritorno?

Per le opzioni SD-WAN specifiche di Sophos, è adatto [Pacchetto di risposta instradamento SD-WAN e traffico di sistema](/it/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/). [Sophos Firewall Risoluzione dei problemi IPsec](/it/kb/sophos-firewall-ipsec-troubleshooting/) aiuta anche con le connessioni IPsec.

## Modellazione del traffico per VoIP

Il modellamento del traffico può stabilizzare il VoIP quando le linee sono strette o quando caricamenti di grandi dimensioni sostituiscono i pacchetti vocali. Tuttavia, non risolve le regole NAT errate, le porte RTP mancanti e i percorsi di ritorno errati.

Il modellamento del traffico è particolarmente utile se:

- Il VoIP peggiora quando la linea Internet è sotto carico,
- Caricamenti o backup interrompono le conversazioni,
- più applicazioni utilizzano la stessa linea,
- Il VoIP dovrebbe avere una priorità specifica.

La configurazione è descritta in [Applicazione Traffic Shaping su Sophos Firewall](/it/kb/sophos-firewall-application-traffic-shaping/). Per il VoIP non dovreste solo controllare i test di velocità dopo l'implementazione, ma anche effettuare chiamate di prova reali con carico simultaneo.

## Flusso pratico di risoluzione dei problemi

1. Sintomo del documento: registrazione, impostazione della chiamata, audio, ora di interruzione, direzione.
2. Raccogli i dati del provider: server SIP, trasporto, intervallo di porte RTP, requisiti NAT.
3. Identificare la regola firewall e la regola NAT.
4. Attivare la registrazione nella regola firewall interessata.
5. Aprire Log Viewer e Packet Capture durante una chiamata di prova.
6. Verificare se la segnalazione SIP funziona in entrambe le direzioni.
7. Controlla se RTP funziona in entrambe le direzioni.
8. Se sono presenti più linee WAN, controllare SD-WAN e il percorso di ritorno.
9. Testare SIP Helper in modo specifico e documentare i risultati.
1
0. Adattare il timeout UDP solo in modo consapevole e documentato con il vecchio valore.
1
1. Dopo ogni modifica, testare la registrazione, le chiamate in uscita, le chiamate in entrata e l'audio in entrambe le direzioni.

Se vengono apportate più modifiche contemporaneamente, la causa successiva è difficile da comprendere. È meglio un test per modifica.

## Raccogli prove durante una chiamata di prova

Un test VoIP è utile solo se l'ora, la direzione e il flusso dei pacchetti corrispondono. Soprattutto nei casi dei provider l’affermazione “L’audio non funziona” non è sufficiente. Hai bisogno di un caso di test piccolo e riproducibile.
- **Ora esatta con fuso orario:** Log Viewer, Packet Capture e i registri del provider possono essere facilmente confrontati in seguito.
- **Direzione della chiamata:** le chiamate in entrata, le chiamate in uscita e l'inoltro interno non vengono combinati.
- **Numeri di telefono o interni:** I provider e i PBX trovano la chiamata specifica più rapidamente.
- **IP interno del PBX o del telefono:** Packet Capture può essere filtrato in modo ristretto.
- **Server SIP del provider e intervallo di porte RTP:** L'analisi SIP e RTP rimangono separate.
- **Rule ID, NAT ID, In interface e Out interface:** puoi vedere quale regola e quale percorso sono stati effettivamente utilizzati.
- **Risultato per test:** La registrazione, lo squillo, l'impostazione della chiamata, l'audio sinistro/destro e il tempo di terminazione rimangono tracciabili.

In caso di errori sporadici è opportuno eseguire il backup anche dei relativi protocolli prima che vengano sovrascritti. Per un pacchetto di tronchi pulito, [Sophos Firewall Backup dei registri per supporto e analisi](/it/kb/log-sophos-firewall-supporto-analisi/) è adatto. Quale file di registro appartiene a quale servizio è descritto in [Sophos Firewall Risoluzione dei problemi: servizi e registri](/it/kb/sophos-firewall-servizi-log/).

## Errori comuni
- **Solo la porta SIP abilitata, ho dimenticato l'intervallo di porte RTP:** La chiamata viene avviata ma manca l'audio.
- **Esiste una regola NAT, ma nessuna regola firewall corrispondente:** Il traffico viene tradotto ma non consentito.
- **Regola firewall senza registrazione:** La risoluzione dei problemi in Log Viewer rimane cieca.
- **SIP Helper disattivato o attivato a livello generale:** il problema viene spostato in modo casuale anziché analizzato.
- **Timeout UDP impostato molto alto:** le sessioni UDP globali rimangono aperte inutilmente a lungo.
- **Percorsi WAN multipli senza una regola SD-WAN chiara:** diventa più probabile che l'audio unidirezionale o il traffico rifiutato dal provider diventino più probabili.
- **Reti di origine del provider non limitate:** Il servizio SIP è inutilmente ampiamente accessibile da Internet.
- **Traffic shaping inteso come sostituto di NAT/routing:** La qualità della voce rimane scarsa perché la causa è altrove.

## Rollback e documentazione

Quando si apportano modifiche VoIP, dovrebbe essere sempre chiaro come tornare indietro:- vecchio valore `udp-timeout-stream` documentato
- Stato del modulo SIP documentato prima del test
- Modificate le regole firewall e NAT annotate con data e motivo
- Prova le chiamate registrate con direzione e ora
- Packet Capture o relativi log protetti per casi di supporto

Se il cambiamento non aiuta, non dovrebbe essere lasciato come un'eredità accidentale. In caso contrario, in particolare le soluzioni VoIP diventerebbero difficili da comprendere in seguito.

## Lista di controllo

- Sono disponibili informazioni SIP e RTP del provider.
- La regola firewall per VoIP è identificata e la registrazione è attiva.
- La regola NAT corrisponde alla direzione del traffico.
- SIP e RTP sono stati controllati separatamente.
- Packet Capture mostra la direzione avanti e indietro.
- SIP Helper è stato testato solo specificatamente.
- Il timeout UDP è stato modificato solo con un valore iniziale documentato.
- Sono state controllate SD-WAN, VPN e più linee WAN.
- Il modellamento del traffico viene utilizzato solo per il controllo della qualità, non in sostituzione del routing o delle correzioni NAT.

## DDomande frequenti







  

Conviene sempre disattivare il SIP Helper su Sophos Firewall?

No. Il SIP Helper può aiutare o ostacolare a seconda del provider e del sistema telefonico. Dovrebbe essere testato specificatamente. Se la disattivazione non apporta alcun miglioramento è opportuno ripristinare lo stato precedente.

Perché la chiamata funziona ma non si sente nulla?

Quindi la segnalazione SIP funziona almeno parzialmente, ma il flusso multimediale RTP non viene eseguito correttamente. Controlla l’intervallo di porte RTP, NAT, regola firewall, percorso di ritorno e, se sono presenti più percorsi WAN, SD-WAN.

Un timeout UDP più elevato aiuta con i problemi VoIP?

A volte sì, soprattutto in caso di chiamate interrotte o registrazioni instabili. Tuttavia, il valore ha un impatto più ampio sulle sessioni UDP e dovrebbe quindi essere consapevole, documentato e non impostato inutilmente alto.

Cosa è importante nel VoIP su SD-WAN?

SIP e RTP dovrebbero essere eseguiti tramite il percorso previsto. Se i viaggi di andata e ritorno utilizzano linee WAN o percorsi VPN diversi, potrebbero verificarsi connessioni audio unilaterali o rifiutate.