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.

Questo articolo presenta la risoluzione dei problemi VoIP su Sophos Firewall come un processo strutturato. Le soluzioni rapide comuni, come disattivare SIP Helper o aumentare un timeout UDP, sono soltanto test controllati. Prima si identificano il percorso dei pacchetti, le regole firewall e NAT effettivamente utilizzate, quindi si analizzano SIP e RTP separatamente.

Comprendere SIP, RTP e i sintomi

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 sono audio assente, audio unidirezionale o interruzioni dopo poco tempo.

SIP utilizza spesso UDP o TCP 5060, mentre SIP cifrato usa frequentemente 5061. Questi valori non sono universali. Molti provider utilizzano porte diverse, server proxy o requisiti NAT keepalive aggiuntivi.

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.

Sophos Firewall supporta anche H.323 oltre a SIP. Questo runbook si concentra sulla segnalazione SIP e su RTP. Se il sistema telefonico utilizza effettivamente H.323, il servizio H.323 e l’H.323 Helper devono essere verificati separatamente; le impostazioni del SIP Helper non sono quindi automaticamente il punto di intervento corretto.

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.

Rilevare la situazione iniziale prima delle 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 firewall su Sophos Firewall aiuta nell’analisi delle regole. Per il flusso di pacchetti effettivo, Packet Capture in WebAdmin è in genere più significativo di un semplice Policy Test. I valori CLI globali vanno modificati solo dopo aver raccolto questa baseline e predisposto una chiamata di prova riproducibile.

Controllare il percorso dei pacchetti, il routing e la qualità

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
• nessuna Application Control, IPS o Web Filtering imprevista su questo traffico

La necessità di DNAT per un trunk SIP in entrata dipende dal design del provider. I trunk basati su registrazione possono utilizzare la sessione in uscita esistente. I trunk consegnati direttamente a un indirizzo pubblico o i sistemi telefonici pubblicati richiedono in genere una regola DNAT con ambito ristretto. Fanno fede i requisiti del provider o dell’operatore SBC.

Se DNAT è necessario, verificare anche questi punti:

• 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. Se un centralino deve essere accessibile da Internet, Pubblica il server tramite 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. Confrontare NAT ID, Rule ID, In interface e Out interface.

Se RTP è visibile solo in uscita e non ritorna nulla, il problema può risiedere nel provider, nel percorso di ritorno, nel NAT o in un dispositivo a monte. Se RTP ritorna ma non viene inoltrato al PBX, le cause più probabili sono la regola firewall, DNAT, il routing o l’assegnazione della zona.

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.

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. Sophos Firewall Risoluzione dei problemi IPsec 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. Per il VoIP non dovreste solo controllare i test di velocità dopo l’implementazione, ma anche effettuare chiamate di prova reali con carico simultaneo.

Testare SIP Helper, UDP Timeout e DoS in modo controllato

Le impostazioni seguenti interessano più di una singola regola VoIP. Vanno testate solo dopo aver circoscritto la causa, con una baseline documentata, una finestra di manutenzione e un rollback chiaro.

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.

SIP Helper è quindi un utile punto di prova, ma non una soluzione permanente universale. Sophos documenta il modulo SIP come attivo per impostazione predefinita. Le modifiche eseguite con load o unload persistono dopo un riavvio.

I comandi vengono eseguiti tramite SSH su Sophos Firewall, in 4. Device Console. L’accesso SSH va consentito solo da reti attendibili. Le basi sono descritte in Connettersi a Sophos Firewall tramite SSH.

Visualizzare lo stato attuale prima e dopo ogni modifica con un comando di sola lettura:

system system_modules show

L’output relativo alla voce sip deve essere documentato. In questo modo rimane chiaro se l’Helper era caricato prima del test e quale stato è previsto dopo il rollback.

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.

Se il provider utilizza una porta di segnalazione SIP personalizzata invece di UDP 5060, l’Helper può essere caricato con quella porta precisa:

system system_modules sip load ports <custom_port>

<custom_port> viene sostituito con la porta SIP specificata dal provider o dal produttore del PBX, non con un intero intervallo di porte RTP. Il SIP Helper supporta porte multimediali da 1024 a 65535. Se una porta multimediale si trova al di fuori di questo intervallo, il firewall può scartare il traffico e mostrare Invalid Traffic nel registro eventi.

SIP su TCP presenta un altro limite: l’Helper non supporta messaggi SIP o SDP distribuiti su più pacchetti. Se Packet Capture mostra esattamente questo schema, il trasporto deve essere chiarito con il provider e il produttore del PBX. Il passaggio a SIP su UDP è opportuno solo se entrambi i lati lo supportano.

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.

Sophos distingue due valori globali:

• udp-timeout si applica alle connessioni UDP non ancora riconosciute come flusso bidirezionale.
• udp-timeout-stream si applica ai flussi UDP stabiliti in cui entrambi gli endpoint hanno inviato traffico sulla stessa porta tra segmenti di rete.

In SFOS 22 entrambi i valori accettano da 30 a 3600 secondi. Visualizzare i valori Advanced Firewall correnti in Device Console:

show advanced-firewall

La guida attuale di SFOS 22 indica 60 secondi come valore predefinito di UDP Timeout Stream e consiglia 150 secondi per VoIP. Rimangono tuttavia determinanti il valore effettivamente visualizzato e le specifiche del provider. Se Packet Capture e il momento dell’interruzione indicano un timeout del flusso troppo breve, il valore documentato può essere testato in modo controllato:

set advanced-firewall udp-timeout-stream 150

⚠️ udp-timeout-stream non è un’opzione della singola regola VoIP. Interessa tutti i flussi UDP corrispondenti. Non va aumentato per tentativi o arbitrariamente. Annotare il vecchio valore da show advanced-firewall e ripristinarlo con lo stesso comando set se il test non riesce.

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.

Verificare le soglie UDP flood

Il VoIP genera molti pacchetti UDP. Se le soglie in Intrusion prevention > DoS & spoof protection > DoS settings sono troppo basse, il firewall può scartare traffico SIP o RTP legittimo come UDP flood. Prima di una modifica vanno documentati i valori correnti di Packet rate, Burst rate e Apply flag, oltre ai contatori dei pacchetti scartati.

Sophos indica la rimozione temporanea dell’Apply flag per UDP flood come test diagnostico. Questo riduce la protezione DoS durante il test e deve quindi avvenire in una finestra di manutenzione con un caso di prova ristretto. Se il VoIP migliora, Packet rate e Burst rate vengono adattati al carico legittimo misurato e Apply flag viene nuovamente impostato. Se il problema rimane invariato, lo stato iniziale viene ripristinato immediatamente.

Un’eccezione mirata per host o porte noti può essere più sicura di una disattivazione globale. Spoof Protection e protezione DoS su Sophos Firewall spiega come interagiscono le soglie e le DoS bypass rules. La protezione non deve rimanere disattivata dopo il test.

Risoluzione dei problemi e riscontri

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. Verificare lo stato del SIP Helper, testare le modifiche in modo mirato e documentare i risultati.
10. Modificare un timeout UDP solo deliberatamente e dopo aver documentato il vecchio valore.
11. In caso di scarti UDP o problemi di qualità sotto carico, verificare le soglie UDP flood in modo controllato.
12. 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.
• Registro eventi e contatori DoS: Invalid Traffic o l’aumento degli scarti UDP flood aiutano a delimitare l’intervallo di porte dell’Helper e le soglie DoS.
• 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 è adatto. Quale file di registro appartiene a quale servizio è descritto in Sophos Firewall Risoluzione dei problemi: servizi e registri.

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.
• Porta SIP personalizzata confusa con l’intervallo di porte RTP: L’Helper viene caricato sulla porta di segnalazione errata.
• Timeout UDP impostato molto alto: le sessioni UDP globali rimangono aperte inutilmente a lungo.
• Protezione UDP flood troppo restrittiva o disattivata in modo permanente: I pacchetti vocali legittimi vengono scartati oppure la protezione rimane inutilmente ridotta dopo il test.
• 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.

Ripristinare le modifiche in modo controllato

Per ogni modifica VoIP deve essere chiaro come tornare indietro:

• vecchi valori di udp-timeout e udp-timeout-stream documentati se vengono modificati
• test SIP load, unload o della porta personalizzata e stato finale desiderato documentati
• soglie UDP flood e Apply flags originali documentati e ripristinati dopo il test
• regole firewall e NAT modificate registrate con data e motivo
• chiamate di prova registrate con direzione e ora
• Packet Capture o log pertinenti conservati per i 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.

Checklist operativa

• 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.
• Lo stato del SIP Helper è stato verificato prima e dopo il test mirato.
• Una porta SIP personalizzata corrisponde alle specifiche del provider o del PBX e non viene confusa con l’intervallo di porte RTP.
• Il timeout UDP è stato modificato solo con un valore iniziale documentato.
• Le soglie UDP flood e la protezione DoS sono state riportate a uno stato finale sicuro dopo il test.
• 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.

Domande frequenti