Åtgärda VoIP-problem med SIP och RTP på Sophos Firewall

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 beskriver VoIP-felsökning på Sophos Firewall som en strukturerad process. Vanliga snabbåtgärder som att inaktivera SIP Helper eller öka UDP-timeout är endast kontrollerade tester. Börja med att kontrollera den berörda paketvägen, de brandväggs- och NAT-regler som faktiskt används samt SIP och RTP var för sig.

Förstå SIP, RTP och symtomen

Det som går genom brandväggen med VoIP

VoIP består ungefär av två delar:

• SIP: styr registrering, uppkoppling och avslutning av samtal samt förhandling av medieparametrar. Typiska fel är misslyckad registrering, samtal som inte kopplas upp eller SIP-dialoger som leverantören avvisar.
• RTP: transporterar röstdata under samtalet. Typiska fel är att ljud saknas, bara hörs i en riktning eller bryts efter en kort stund.

SIP körs ofta över UDP eller TCP 5060, och krypterad SIP ofta över 5061. Det är dock ingen fast regel. Många leverantörer använder egna portar, proxyservrar eller ytterligare krav på NAT Keepalive.

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.

Sophos Firewall stöder även H.323 utöver SIP. Detta runbook fokuserar på SIP-signalering och RTP. Om telefonsystemet faktiskt använder H.323 måste H.323-tjänsten och H.323 Helper kontrolleras separat; inställningar för SIP Helper är då inte automatiskt rätt åtgärdspunkt.

SIP och H.323 förhandlar IP-adresser och portar i signaleringen: värden från lager 3 och 4 finns alltså även i applikationsinnehållet på lager 7. Att översätta paketadresser med NAT korrigerar inte automatiskt dessa värden. Connection-tracking-helpers hjälper till att koppla ihop de förhandlade medieanslutningarna; kontrollera därför signaleringsinnehåll, NAT och den verkliga medievägen tillsammans.

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.

Dokumentera utgångsläget före ä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 informativt än ett rent policytest. Ändra globala CLI-värden först när det finns ett reproducerbart testsamtal och denna baslinje är dokumenterad.

Kontrollera paketflöde, routing och kvalitet

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
• Loggning av trafik i brandväggsregeln med Log firewall traffic
• ingen regel som är för bred eller felaktigt placerad ovanför VoIP-regeln
• ingen oväntad Application Control, IPS eller webbfiltrering på denna trafik

Om en inkommande SIP-trunk verkligen behöver DNAT beror på leverantörens utformning. Registreringsbaserade trunkar kan använda den befintliga utgående sessionen. Trunkar som levereras direkt till en offentlig adress eller publicerade telefonsystem behöver däremot oftast en riktad DNAT-publicering. Leverantörens eller SBC-operatörens krav är avgörande.

Om DNAT behövs tillkommer följande punkter:

• 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. Om en telefonväxel behöver vara tillgänglig från Internet är Publicera server via DNAT den bättre grunden för själva publiceringen.

Analysera RTP i båda riktningarna

Vid ett samtal via VPN eller Sophos Connect-klienten kan telefonen ringa trots att RTP-vägen saknas. Kontrollera den regel som faktiskt används under Rules and policies > Firewall rules: den måste tillåta SIP och innehålla nätverket för den uppringda telefonen eller PBX under Destination networks. Bredda inte destinationen generellt till Any; tillåt bara de mottagarnätverk som behövs. Upprepa samma samtal och kontrollera RTP i båda riktningarna. En ringsignal ensam bevisar inte att allt fungerar.

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. Begränsa Packet Capture till växelns eller telefonens IP-adress och RTP-portintervallet. Ta med båda riktningarna, eftersom den interna enheten är källa eller destination beroende på paketets riktning.
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, Out interface och Gateway ID. Kontrollera även Status och Reason när paket saknas; Violation anger ett tappat paketflöde.

Om RTP endast är synlig utgående men ingenting kommer tillbaka, kan problemet ligga hos leverantören, returvägen, NAT eller en uppströms motpart. Om RTP kommer tillbaka men inte vidarebefordras till telefonväxeln är brandväggsregeln, DNAT, routing eller zontilldelningen mer sannolik.

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.

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:

• Matchar en SD-WAN-rutt VoIP-trafiken?
• 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. Sophos Firewall IPsec-felsökning 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. För VoIP bör du inte bara kontrollera hastighetstester efter implementering, utan också utföra riktiga testsamtal med samtidig belastning.

Testa SIP Helper, UDP Timeout och DoS kontrollerat

Ändringarna och återställningsprocedurerna som beskrivs har inte körts på en Sophos Firewall för denna artikel. Kontrollera installerad SFOS-version och tillgängliga kommandon före en ändring. Avbryt och kontakta Sophos Support om utdata avviker eller utgångsläget är oklart.

Följande inställningar påverkar inte bara en enskild VoIP-regel. Testa dem därför först efter en avgränsad analys och med dokumenterat utgångsvärde, underhållsfönster och tydlig återställningsplan.

Kontrollera SIP Helper

SIP Helper, även kallad SIP ALG, identifierar som standard SIP på UDP 5060, översätter lokala adresser i SIP-headern och öppnar dynamiskt den förväntade röstkanalen. Kontrollera i det verkliga samtalsflödet om dessa ingrepp passar leverantörens och växelns design. Vissa PBX-tillverkare kräver uttryckligen att SIP ALG är avstängd, medan andra installationer behöver Helper-funktionen.

SIP Helper är därför en relevant testpunkt, men ingen generell permanent lösning för alla problem. Sophos dokumenterar SIP-modulen som aktiverad som standard. Ändringar med load eller unload kvarstår efter en omstart.

Kommandona körs via SSH på Sophos Firewall. 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.

CLI kan även öppnas via admin > Console uppe till höger i WebAdmin; välj därefter också 4. Device Console. Använd endast en redan tillåten, betrodd administrationsanslutning; öppna inte hanteringsåtkomst mot internet.

Visa aktuell status före och efter varje ändring med ett skrivskyddat kommando:

system system_modules show

Dokumentera utdata för posten sip. Då förblir det tydligt om Helper var inläst före testet och vilket tillstånd som förväntas efter rollback.

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 ändringen inte hjälper ska exakt föregående tillstånd återställas:

• Om sip var unloaded, använd system system_modules sip unload.
• Om modulen var inläst på standardporten UDP 5060, använd system system_modules sip load.
• Om den var inläst på en egen port, använd system system_modules sip load ports <previous_custom_port>. <previous_custom_port> måste vara porten som dokumenterades före ändringen.

Starta inte testet om en tidigare egen port inte är säkert känd. En vanlig load är då ingen exakt återställning, eftersom den läser in Helper på standardporten.

Om leverantören använder en egen SIP-signaleringsport i stället för UDP 5060 kan Helper läsas in med exakt den porten:

system system_modules sip load ports <custom_port>

Ersätt <custom_port> med SIP-porten som leverantören eller PBX-tillverkaren anger, inte med ett helt RTP-portintervall. SIP Helper stöder mediaportar från 1024 till 65535. Om en använd mediaport ligger utanför detta intervall kan brandväggen kasta trafiken och visa Invalid Traffic i händelseloggen.

SIP över TCP har ytterligare en begränsning: Helper stöder inte SIP- eller SDP-meddelanden som sträcker sig över flera paket. Om Packet Capture visar just detta mönster bör transporttypen klargöras med leverantören och PBX-tillverkaren. En övergång till SIP över UDP är bara lämplig om båda sidor stöder det.

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.

Sophos skiljer mellan två globala värden:

• udp-timeout gäller UDP-anslutningar som ännu inte har identifierats som en dubbelriktad ström.
• udp-timeout-stream gäller etablerade UDP-strömmar där båda ändpunkterna har skickat trafik på samma port mellan nätverkssegment.

Båda värdena stöder intervallet 30 till 3600 sekunder i SFOS 22. Den aktuella avancerade brandväggsstatusen visas i Device Console:

show advanced-firewall

Den aktuella SFOS 22-hjälpen anger 60 sekunder som standardvärde för UDP Timeout Stream och rekommenderar 150 sekunder för VoIP. Det faktiskt visade värdet och leverantörens krav är dock fortfarande avgörande. Om Packet Capture och avbrottstiden tyder på en för kort stream-timeout kan det dokumenterade värdet testas kontrollerat:

set advanced-firewall udp-timeout-stream 150

Kör omedelbart show advanced-firewall igen. Gör samma testsamtal först när UDP Timeout Stream : 150 visas. Efter återställningen måste samma kontroll visa det tidigare dokumenterade värdet.

⚠️ udp-timeout-stream är inte en ren VoIP-regelinställning utan påverkar alla matchande UDP-strömmar. Sätt inte värdet på misstanke eller godtyckligt högt. Notera det gamla värdet från show advanced-firewall före testet och återställ det med samma set-kommando om testet inte hjälper.

Om baslinjen exempelvis visade UDP Timeout Stream : 60 är den exakta återställningen:

set advanced-firewall udp-timeout-stream 60

Värdet 60 är endast rätt för den baslinjen. Om brandväggen visade ett annat värde ska det kopieras oförändrat till återställningskommandot.

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 tröskelvärden för UDP flood

Sophos sida för VoIP-felsökning rekommenderar lägre skyddsvärden, medan DoS-referensen varnar för att för låga trösklar kan blockera legitima förfrågningar. Denna motsägelse om ändringens riktning är fortfarande olöst. Sänk eller höj inte trösklarna blint: bedöm dem utifrån den uppmätta legitima belastningen och återställ skyddet direkt efter det avgränsade testet.

VoIP genererar många UDP-paket. Om tröskelvärdena under Intrusion prevention > DoS & spoof protection > DoS settings är för låga kan brandväggen kasta legitim SIP- eller RTP-trafik som UDP flood. Dokumentera före en ändring de aktuella värdena för Packet rate, Burst rate och Apply flag samt droppräknarna.

Sophos anger att Apply flag tillfälligt kan tas bort för UDP flood som ett diagnostiskt test. Det minskar DoS-skyddet under testet och hör därför hemma i ett underhållsfönster med ett snävt definierat testfall. Om VoIP förbättras justeras Packet rate och Burst rate efter den uppmätta legitima belastningen och Apply flag ställs in igen. Om problemet är oförändrat återställs utgångsläget omedelbart.

Ett riktat undantag för kända värdar eller portar kan vara säkrare än en global avaktivering. Spoof Protection och DoS-skydd på Sophos Firewall förklarar hur tröskelvärden och DoS bypass rules samverkar. Skyddet får inte förbli avaktiverat efter testet.

H.323, VPN och conntrack som specialfall

VoIP-felsökningens formulering kopplar avaktivering av SIP-IPS-mönster till att anslutningar inte rensas, medan CLI dokumenterar separata IPS- och VPN-inställningar. Sambandet är fortfarande oklart. Denna instruktion utgår inte från att avaktivering av sip_preproc också ändrar borttagningen av anslutningar när en tunnel etableras. Beteendet har inte testats på en appliance här; VPN-inställningen kräver fortfarande ett av Support bekräftat utgångsvärde och en exakt återställning.

För H.323 kan adressöversättning på applikationsnivå saknas trots korrekta brandväggs- och DNAT-regler. Adresser och portar som skickas i signaleringen måste också stämma med den verkliga medievägen. En inläst H.323-modul och korrekta paketadresser bevisar därför inte i sig att ljud eller video fungerar.

Följande Sophos-anvisningar gäller endast ett tydligt bekräftat problem. De ändrar globala helper-, IPS- eller VPN-inställningar eller en aktiv session och är inte generell VoIP-optimering.

För H.323 kan den inlästa Helper-modulen vara orsaken om ljud eller video bryts eller bara fungerar i en riktning trots korrekta brandväggs- och DNAT-regler. Dokumentera först utgångsläget med system system_modules show. Sophos anger detta kontrollerade test:

system system_modules h323 unload

Läs sedan modulstatus igen och upprepa samma testsamtal med ljud eller video i båda riktningarna. Om h323 redan var urladdad skapade kommandot inget nytt testläge.

Om modulen var inläst före testet och problemet kvarstår, återställ med:

system system_modules h323 load

Den transparenta subnätsgateway med proxy ARP som Sophos också nämner är en designändring, inte ett allmänt nästa steg. Endast den verifierade ARP- och routningsvägen avgör om Proxy ARP på Sophos Firewall passar topologin.

För VoIP-problem via site-to-site-VPN eller med IPS anger Sophos två globala inställningar. sip_preproc skannar SIP-sessioner efter nätverksattacker och är aktiverad som standard. conn-remove-tunnel-up styr om anslutningar tas bort när en IPsec-tunnel etableras.

Korrelera före testet det avbrutna samtalet med en tunnelhändelse. Läs det ursprungliga IPS-värdet i Device Console:

show ips-settings

Om sip_preproc tydligt visas som enable kan det Sophos-dokumenterade testet utföras i ett underhållsfönster:

set ips sip_preproc disable

Kör show ips-settings igen och upprepa samma testsamtal. Att avaktivera inställningen minskar inspektionen av SIP-attacker globalt. Om testet inte hjälper är den exakta återställningen för det tidigare avlästa värdet enable: set ips sip_preproc enable; därefter måste show ips-settings åter visa enable. Ändra inget om utgångsvärdet redan är disable eller inte kan läsas entydigt.

För samma felbild anger Sophos även set vpn conn-remove-tunnel-up disable. Den aktuella CLI-hjälpen för SFOS 22 dokumenterar dock varken ett motsvarande läskommando eller ett generellt utgångsvärde. Ändra därför inte inställningen enbart med stöd av den här artikeln. Sophos Support måste först bekräfta det faktiska värdet och den exakta återställningen för installerad build. Använd globala VPN-inställningar säkert förklarar inställningens effekt.

Om en telefon registreras hos PBX med brandväggens IP-adress i stället för sin egen adress jämförs först Log Viewer, Firewall Rule ID, NAT Rule ID och helperstatus mellan en fungerande och en berörd telefon. Att skapa en vanlig ny telefon- eller PBX-session är säkrare än att ändra conntrack. Om en tydligt felaktig TCP-post kvarstår anger Sophos följande som ett sista riktat steg i Advanced Shell:

Öppna Log viewer > Add filter före detta sista steg, ange Field: Dst IP, Condition: Is och Value: PBX-systemets IP-adress, och tillämpa filtret med Add filter. Kontrollera att både en fungerande och en berörd telefon använder rätt brandväggsregel, att SIP eller H.323 tillåts och att NAT-reglerna inte står i konflikt. Om SIP-modulen är inläst ska den bara laddas ur som ett kontrollerat test med utgångsläget och återställningen som beskrivs ovan; återställ avsett modultillstånd efter testet.

⚠️ Borttagningen avbryter anslutningen och saknar ett direkt ångrakommando: en ny anslutning måste återskapa posten. Kontrollera först telefonens och PBX-systemets exakta adresser samt TCP under Diagnostics > Connection list, och kom överens om ett underhållsfönster. Ta inte bort något utan ett entydigt matchande TCP-flöde. Effekten och återhämtningen genom omregistrering har inte testats på en enhet för denna artikel. Kommandot begränsar inte TCP-portarna och kan ta bort flera matchande anslutningar mellan dessa adresser. Avbryt och kontakta Sophos Support om andra nödvändiga sessioner ingår.

Ange exit i 4. Device Console för att gå tillbaka till huvudmenyn i CLI och välj sedan 5. Device management > 3. Advanced Shell. Kör det snävt avgränsade kommandot endast där:

conntrack -D --src <IP_ADDRESS_OF_PHONE> --dst <IP_ADDRESS_OF_PBX> -p tcp

Platshållarna ersätts endast med de verifierade adresserna. Kommandot tar bort den matchande aktiva TCP-sessionen och avbryter den omedelbart; det får varken breddas eller anpassas till UDP. Live Connections på Sophos Firewall förklarar hur flödet först avgränsas under Diagnostics > Connection list.

Låt därefter den berörda telefonen registrera sig igen. Testet är godkänt först när Log Viewer visar telefonens egen IP-adress och ett nytt testsamtal fungerar. Om brandväggens IP-adress visas igen ska borttagningskommandot inte upprepas; utred NAT- och Helper-beteendet med Sophos Support.

Felsökning och underlag

Praktiskt felsökningsflöde

1. Dokumentera symtomen: registrering, samtalsuppkoppling, ljud, tidpunkt för avbrottet och riktning.
2. Samla leverantörsdata: SIP-server, transport, RTP-portintervall, NAT-krav.
3. Identifiera brandväggsregel och NAT-regel.
4. Aktivera Log firewall traffic i den berörda brandväggsregeln för att logga trafiken.
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. Kontrollera status för SIP Helper, testa ändringar specifikt och dokumentera resultaten.
10. Justera endast UDP-timeout medvetet och med det gamla värdet dokumenterat.
11. Kontrollera tröskelvärdena för UDP flood på ett kontrollerat sätt vid UDP-drops eller kvalitetsproblem under belastning.
12. Testa registrering, utgående samtal, inkommande samtal och ljud i båda riktningarna efter varje ändring.

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.
• Leverantörens SIP-server och RTP-portintervall: Analysera SIP och RTP separat.
• Rule ID, NAT ID, In interface och Out interface: du kan se vilken regel och vilken sökväg som faktiskt användes.
• Händelselogg och DoS-räknare: Invalid Traffic eller ökande UDP-flood-drops hjälper till att avgränsa Helperns portintervall och DoS-tröskelvärden.
• 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 användbart paket med loggfiler passar Sophos Firewall Säkerhetskopiera loggar för support och analys. Vilken loggfil som tillhör vilken tjänst beskrivs i Sophos Firewall Felsökning: tjänster och 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.
• Egen SIP-port förväxlad med RTP-portintervallet: Helper läses in på fel signaleringsport.
• UDP-timeout satt mycket högt: Globala UDP-sessioner förblir öppna onödigt länge.
• UDP-flood-skyddet är för strikt eller permanent avaktiverat: Legitima röstpaket kastas eller skyddet förblir onödigt reducerat efter testet.
• 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äll ändringar kontrollerat

När du gör VoIP-ändringar bör det alltid vara tydligt hur du återgår till utgångsläget:

• gamla värden för udp-timeout och udp-timeout-stream dokumenterade om de ändras
• utfört SIP-load-, unload- eller custom-port-test och önskat sluttillstånd dokumenterade
• utgångsläget för H.323 och sip_preproc dokumenterat och återställt efter ett misslyckat specialtest; conn-remove-tunnel-up lämnat oförändrat utan bekräftat utgångsvärde
• ursprungliga tröskelvärden för UDP flood och Apply flags dokumenterade och återställda efter testet
• Ä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.
• Status för SIP Helper kontrollerades före och efter det riktade testet.
• En egen SIP-port motsvarar leverantörens eller PBX:ens specifikation och förväxlas inte med RTP-portintervallet.
• UDP-timeout ändrades endast med ett dokumenterat initialvärde.
• Tröskelvärden för UDP flood och DoS-skyddet återfördes till ett säkert sluttillstånd efter testet.
• 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