Sophos Firewall Åtgärda VoIP-problem med SIP och RTP
VoIP-problem bakom en Sophos Firewall har ofta en diffus effekt: telefoner registreras inte, samtal avbryts, den ringer utan ljud eller tal kan bara höras i en riktning. I praktiken beror orsaken sällan på en enda switch. SIP-signalering, RTP-mediaström, NAT, brandväggsregler, UDP-timeouts eller routing fungerar vanligtvis tillsammans.
Artikeln klassificerar VoIP-felsökning på Sophos Firewall som en strukturerad process. Kända omedelbara åtgärder som att avaktivera SIP Helper eller öka UDP-timeout är fortfarande viktiga. Sådana ändringar bör dock inte göras blint, utan snarare som en del av en ren felsökningsprocess.
Det som går genom brandväggen med VoIP
VoIP består ungefär av två delar:
- SIP: styr registrering, samtalsinställningar, samtalsrensning och förhandling av mediaparametrar. Typiska fel inkluderar misslyckad registrering, samtal som inte upprättas eller SIP-dialoger som avvisats av leverantören.
- RTP: transporterar röstdata under konversationen. Typiska fel inkluderar saknat ljud, ensidigt ljud eller ljud som avbryts efter en kort tidsperiod.SIP körs ofta över UDP eller TCP
5060, med krypterad SIP ofta över5061. Men det är ingen lag. Många leverantörer använder sina egna portar, sina egna proxyservrar eller ytterligare krav för NAT Keepalives.
RTP använder vanligtvis UDP-portintervall som anges av leverantören, telefonsystemet eller slutenheterna. För en ren analys behöver du specifika SIP-servrar, RTP-portintervall och transportprotokoll från leverantören eller PBX-dokumentationen.
Klassificera symtomen korrekt
Innan du gör några ändringar bör du klassificera symtomen så noggrant som möjligt.
- Registrering misslyckas: Kontrollera DNS, routing, brandväggsregel, NAT, leverantörsuppgifter eller SIP-transport.
- Samtalet ansluter inte: Kontrollera SIP-signalering, brandväggsregel, Application Control och eventuella leverantörsblockeringar.
- Samtalet fungerar men inget ljud: Kontrollera RTP-portintervall, NAT, returväg, SD-WAN och SIP Helper.
- Ljud är bara hörbart i en riktning: Kontrollera RTP-returväg, NAT, routing, VPN och SD-WAN.
- Konversationen avbryts efter 30, 60 eller 120 sekunder: Kontrollera UDP-timeout, NAT Keepalive, sessionsuppdatering och leverantörens förväntningar.
- Endast inkommande samtal fungerar inte: Kontrollera DNAT, brandväggsregel, leverantörens källnät och PBX-portdelning.
- Endast en WAN-linje orsakar problem: Kontrollera SD-WAN-rutt, svarsväg, gateway och leverantörs IP-bindning.
Denna klassificering hindrar dig från att ändra SIP-inställningar även om det faktiska problemet ligger i RTP-returvägen eller en SD-WAN-rutt.
Kontrollera innan du gör ändringar
Innan du gör CLI-ändringar bör du dokumentera aktuell status:
- Vilka telefoner, PBX eller SBC påverkas?
- Registrerar slutenheterna direkt hos leverantören eller går allt via ett internt telefonsystem?
- Vilka SIP-servrar och RTP-portintervall namnger leverantören?
- Vilken brandväggsregel behandlar VoIP-trafiken?
- Är Log firewall traffic aktiverat i den här regeln?
- Vilken NAT-regel gäller för utgående och inkommande VoIP-trafik?
- Finns det flera WAN-linjer, SD-WAN-rutter eller ruttbaserade VPN:er?
- Blev problemet synligt efter en firmwareuppgradering, leverantörsbyte eller PBX-uppdatering?
Testa brandväggsregler på Sophos Firewall hjälper till med regelanalys. För det faktiska paketflödet är Packet Capture i WebAdmin vanligtvis mer meningsfullt än ett rent policytest.
Kontrollera SIP Helper
SIP Helper, ofta även kallad SIP ALG, försöker känna igen SIP-paket och anpassa NAT-relevant SIP-information. Detta kan hjälpa i enkla miljöer. Det kan dock också vara störande i många moderna VoIP-uppställningar med leverantörens SBC, egen PBX, TLS, clean NAT Keepalive eller mer komplexa RTP-portintervall.
Det är därför SIP Helper är en användbar testpunkt, men inte en generell permanent lösning för alla problem.Kommandona exekveras via SSH på Sophos Firewall. För att göra detta, anslut till brandväggen och välj 4. Device Console. SSH-åtkomst bör endast tillåtas från betrodda nätverk. Grunderna finns i Anslut till Sophos Firewall via SSH.
Visa aktuell modulstatus:
system system_modules show
Inaktivera SIP-modul:
system system_modules sip unload
Återaktivera SIP-modulen:
system system_modules sip load
⚠️ Denna ändring bör göras i ett underhållsfönster eller med tydligt definierade tester. Efter inaktivering eller aktivering måste registrering, utgående samtal, inkommande samtal och ljud kontrolleras i båda riktningarna.
Om förändringen inte hjälper bör du ta tillbaka den. Det är viktigt att dokumentera tillståndet före och efter testet.
Kontrollera och justera UDP-timeout
VoIP använder ofta UDP. Om NAT- eller sessionsposter går ut för tidigt kan en registrering tyckas fungera, men samtal tappas eller inkommande samtal når inte växeln på ett tillförlitligt sätt.
Den aktuella avancerade brandväggsstatusen visas i Device Console:
show advanced-firewall
Ett vanligt testvärde är 180 sekunder:```shell
set advanced-firewall udp-timeout-stream 180
> ⚠️ `udp-timeout-stream` är inte ett rent VoIP-kontrollalternativ, men har en bredare effekt på UDP-sessioner. Värdet bör inte sättas godtyckligt högt. Det är bättre att ha ett definierat test med dokumentation av det gamla värdet, leverantörskrav och efterföljande kontroll av sessionen och röstkvaliteten.
Om leverantören eller telefonsystemet stöder NAT Keepalive bör även denna inställning kontrolleras. En ren keepalive på PBX- eller leverantörssidan är ofta bättre än ett mycket högt globalt timeoutvärde.
## Kontrollera brandväggsregler och NAT
NAT är ofta involverad i VoIP-problem. Sophos Firewall måste inte bara tillåta SIP, utan också korrekt översätta och returnera de associerade RTP-strömmarna i båda riktningarna.
Dessa punkter är vanligtvis relevanta för utgående telefoner eller en intern växel:
- lämplig brandväggsregel från VoIP-zonen eller PBX-zonen till WAN
- lämplig SNAT- eller MASQ-regel
- Logga in brandväggsregeln
- ingen regel som är för bred eller felaktigt placerad ovanför VoIP-regeln
- ingen oväntad Application Control, IPS eller webbfiltrering på denna trafikYtterligare punkter läggs till för inkommande SIP-trunkar eller publicerade telefonsystem:
- DNAT till intern PBX eller SBC
- Brandväggsregel med lämplig målzon och målnätverk
- Begränsning till leverantörens källnät, om möjligt
- endast nödvändiga SIP- och RTP-portar
- Loggning och Packet Capture för testning
En NAT-regel tillåter inte trafik, utan översätter endast adresser eller portar. Anslutningarna förklaras i [Förstå NAT på Sophos Firewall](/sv/kb/sophos-firewall-nat-basics/). Om en telefonväxel behöver vara tillgänglig från Internet är [Publicera server via DNAT](/sv/kb/sophos-firewall-server-dnat/) den bättre grunden för själva publiceringen.
## Analysera RTP och språkriktning
Om samtalet upprättas men ljud saknas är SIP vanligtvis inte längre huvudfrågan. Sedan måste du kontrollera om RTP flyter åt båda hållen.
Typisk process:
1. Notera leverantörens eller PBX RTP-portintervall.
2. Starta Packet Capture med käll-IP för telefonväxeln eller telefonen och RTP-portområdet.
3. Ring ett testsamtal.
4. Kontrollera om UDP-paket från den interna enheten till leverantören är synliga.
5. Kontrollera om UDP-paket returneras från leverantören.
6. Jämför NAT ID, Rule ID, In interface och Out interface.Om RTP endast är synlig utgående men ingenting kommer tillbaka, kan problemet ligga hos leverantören, returvägen, NAT eller en uppströms fjärrstation. Om RTP kommer tillbaka men inte vidarebefordras till telefonväxeln är brandväggsregeln, DNAT, routing eller zonmappning mer sannolikt.
För mer exakta inspelningar eller PCAP-export kan `tcpdump` via SSH vara användbart. Processen beskrivs i [Sophos Firewall Använd tcpdump för loggar och analys](/sv/kb/sophos-firewall-samla-loggar-med-tcpdump-for-analys/).
## SD-WAN, VPN och flera WAN-linjer
VoIP är känsligt för asymmetriska vägar. Om SIP körs över en WAN-linje men RTP återvänder över en annan linje eller om ett ruttbaserat VPN dirigeras annorlunda, uppstår typiska fel som ensidigt ljud.
En bugg fixad i SFOS 22.0 MR1 visar den typiska anslutningen: Efter en uppgradering till SFOS 22.0 GA kunde VoIP-ljud bara fungera envägs över ruttbaserad VPN med SD-WAN-routing. I praktiken betyder detta: SD-WAN bör alltid kontrolleras när du använder VoIP över VPN eller flera WAN-vägar.
Viktiga kontrollpunkter:
- Har en SD-WAN-rutt åtkomst till VoIP-trafik?
- Leds SIP och RTP över samma förväntade WAN-linje?
- Finns det leverantörsspecifikationer angående käll-IP eller offentlig avsändaradress?
- Används en ruttbaserad VPN-rutt med ett XFRM-gränssnitt?
- Matchar returrutter och NAT den valda vägen?
- Visar Packet Capture olika gateways eller gränssnitt för ut- och returriktningar?
För Sophos-specifika SD-WAN-alternativ passar [SD-WAN-dirigering av svarspaket och systemtrafik](/sv/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/). [Sophos Firewall IPsec-felsökning](/sv/kb/sophos-firewall-ipsec-troubleshooting/) hjälper också till med IPsec-anslutningar.
## Trafikformning för VoIP
Trafikformning kan stabilisera VoIP när linjerna är trånga eller stora uppladdningar förskjuter röstpaket. Det löser dock inte felaktiga NAT-regler, saknade RTP-portar och felaktiga returvägar.
Trafikformning är särskilt användbar om:
- VoIP blir värre när internetlinjen är under belastning,
- Uppladdningar eller säkerhetskopior stör konversationer,
- flera applikationer använder samma linje,
– VoIP bör prioriteras specifikt.
Konfigurationen beskrivs i [Application Traffic Shaping på Sophos Firewall](/sv/kb/sophos-firewall-application-traffic-shaping/). För VoIP bör du inte bara kontrollera hastighetstester efter implementering, utan också utföra riktiga testsamtal med samtidig belastning.
## Praktiskt felsökningsflöde
1. Dokumentsymptom: registrering, samtalsinställningar, ljud, avbrytningstid, riktning.
2. Samla leverantörsdata: SIP-server, transport, RTP-portintervall, NAT-krav.
3. Identifiera brandväggsregel och NAT-regel.
4. Aktivera inloggning i den berörda brandväggsregeln.
5. Öppna Log Viewer och Packet Capture under ett testsamtal.
6. Kontrollera om SIP-signalering går i båda riktningarna.
7. Kontrollera om RTP körs i båda riktningarna.
8. Om det finns flera WAN-linjer, kontrollera SD-WAN och returväg.
9. Testa SIP Helper specifikt och dokumentera resultaten.
1
0. Justera endast UDP-timeout medvetet och dokumenterat med det gamla värdet.
1
1. Efter varje byte, testregistrering, utgående samtal, inkommande samtal och ljud i båda riktningarna.
Om flera ändringar görs samtidigt är den efterföljande orsaken svår att förstå. Ett test per byte är bättre.
## Samla bevis under ett testsamtal
Ett VoIP-test är bara användbart om tid, riktning och paketflöde matchar. Särskilt i leverantörsfall räcker inte uttalandet "Ljud fungerar inte". Du behöver ett litet, reproducerbart testfall.
- **Exakt tid med tidszon:** Log Viewer, Packet Capture och leverantörsloggar kan enkelt jämföras senare.
- **Samtalsriktning:** Inkommande samtal, utgående samtal och intern vidarekoppling blandas inte.
- **Telefonnummer eller anknytningar:** Leverantörer och PBX:er hittar det specifika samtalet snabbare.
- **Intern IP för PBX eller telefon:** Packet Capture kan filtreras snävt.
- **Leverans SIP-server och RTP-portintervall:** SIP- och RTP-analys förblir separata.
- **Rule ID, NAT ID, In interface och Out interface:** du kan se vilken regel och vilken sökväg som faktiskt användes.
- **Resultat per test:** Registrering, ringsignal, samtalsinställningar, ljud vänster/höger och avslutningstid förblir spårbara.
Vid sporadiska fel bör du även säkerhetskopiera relevanta loggar innan de skrivs över. För ett rent stockpaket passar [Sophos Firewall Säkerhetskopiera loggar för support och analys](/sv/kb/sophos-firewall-loggar-support-analys/). Vilken loggfil som tillhör vilken tjänst beskrivs i [Sophos Firewall Felsökning: tjänster och loggar](/sv/kb/sophos-firewall-tjanster-loggar/).
## Vanliga fel
- **Endast SIP-port aktiverad, glömde RTP-portintervall:** Samtalet ställs in men ljud saknas.
- **NAT-regel finns, men ingen matchande brandväggsregel:** Trafik är översatt men inte tillåten.
- **Brandväggsregel utan loggning:** Felsökning i Log Viewer förblir blind.
- **SIP Helper inaktiverad eller aktiverad över hela linjen:** Problemet flyttas slumpmässigt istället för att analyseras.
- **UDP-timeout satt mycket högt:** Globala UDP-sessioner förblir öppna onödigt länge.
- **Flera WAN-vägar utan en tydlig SD-WAN-regel:** Envägsljud eller trafik avvisad från leverantören blir mer sannolikt.
- **Providerns källnät är inte begränsade:** SIP-tjänsten är onödigt brett tillgänglig från Internet.
- **Trafikformning förstås som en ersättning för NAT/routing:** Röstkvaliteten förblir dålig eftersom orsaken ligger någon annanstans.
## Återställning och dokumentation
När du gör VoIP-ändringar bör det alltid vara tydligt hur du kommer tillbaka:- gammalt `udp-timeout-stream`-värde dokumenterat
- SIP-modulstatus dokumenterad före testning
- Ändrade brandväggs- och NAT-regler noterade med datum och anledning
- Testsamtal loggade med riktning och tid
- Packet Capture eller relevanta loggar säkrade för supportärenden
Om förändringen inte hjälper bör den inte lämnas som ett oavsiktligt arv. Särskilt VoIP-lösningar kommer annars att bli svåra att förstå senare.
## Checklista
- Leverantörs SIP- och RTP-information är tillgänglig.
- Brandväggsregeln för VoIP identifieras och loggning är aktiv.
- NAT-regeln matchar trafikriktningen.
- SIP och RTP kontrollerades separat.
- Packet Capture visar riktning fram och tillbaka.
- SIP Helper testades endast specifikt.
- UDP-timeout ändrades endast med ett dokumenterat initialvärde.
- SD-WAN, VPN och flera WAN-linjer kontrollerades.
- Trafikformning används endast för kvalitetskontroll, inte som ersättning för routing eller NAT-korrigeringar.
## Vanliga frågor
Ska du alltid inaktivera SIP Helper på Sophos Firewall?
Nej. SIP Helper kan hjälpa eller hindra beroende på leverantör och telefonsystem. Det bör testas specifikt. Om avaktiveringen inte leder till någon förbättring bör du återställa den tidigare statusen.
Varför fungerar samtalet men du hör ingenting?
Då fungerar SIP-signaleringen åtminstone delvis, men RTP-medieströmmen körs inte korrekt. Du kontrollerar RTP-portintervallet, NAT, brandväggsregel, returväg och, om det finns flera WAN-vägar, SD-WAN.
Hjälper en högre UDP-timeout med VoIP-problem?
Ibland ja, speciellt vid trasiga samtal eller instabila registreringar. Värdet har dock en bredare inverkan på UDP-sessioner och bör därför vara medveten, dokumenterad och inte sättas onödigt högt.
Vad är viktigt med VoIP över SD-WAN?
SIP och RTP bör köras via den förväntade sökvägen. Om tur och retur använder andra WAN-linjer eller VPN-vägar kan ensidigt ljud eller avvisade anslutningar uppstå.