Sophos Firewall Napraw problemy VoIP z SIP i RTP
Problemy z VoIP za Sophos Firewall często mają efekt rozproszony: telefony się nie rejestrują, połączenia są zrywane, dzwoni bez dźwięku lub mowa jest słyszalna tylko w jednym kierunku. W praktyce przyczyną rzadko jest pojedynczy przełącznik. Sygnalizacja SIP, strumień multimediów RTP, NAT, reguły zapory sieciowej, limity czasu UDP lub routing zwykle współpracują ze sobą.
W artykule sklasyfikowano rozwiązywanie problemów VoIP na Sophos Firewall jako proces ustrukturyzowany. Znane natychmiastowe środki, takie jak dezaktywacja Pomocnika SIP lub zwiększenie limitu czasu UDP, pozostają ważne. Jednak takich zmian nie należy wprowadzać na ślepo, ale raczej w ramach czystego procesu rozwiązywania problemów.
Co przechodzi przez zaporę sieciową w przypadku VoIP
VoIP składa się z grubsza z dwóch części:
- SIP: kontroluje rejestrację, konfigurowanie połączeń, rozliczanie połączeń i negocjowanie parametrów mediów. Typowe błędy to nieudana rejestracja, nienawiązywanie połączeń lub odrzucanie okien dialogowych SIP przez dostawcę.
- RTP: przesyła dane głosowe podczas rozmowy. Typowe błędy to brak dźwięku, jednostronny dźwięk lub przerwanie dźwięku po krótkim czasie.SIP często działa przez UDP lub TCP
5060, a szyfrowany SIP często przez5061. Ale to nie jest prawo. Wielu dostawców korzysta z własnych portów, własnych serwerów proxy lub dodatkowych wymagań dotyczących utrzymywania aktywności NAT.
RTP zwykle korzysta z zakresów portów UDP określonych przez dostawcę, system telefoniczny lub urządzenia końcowe. Do czystej analizy potrzebne są określone serwery SIP, zakresy portów RTP i protokoły transportowe od dostawcy lub dokumentacja PBX.
Prawidłowo klasyfikuj objawy
Przed wprowadzeniem jakichkolwiek zmian należy możliwie najdokładniej sklasyfikować objaw.
- Rejestracja nie powiodła się: Sprawdź DNS, routing, regułę zapory sieciowej, NAT, dane uwierzytelniające dostawcy lub transport SIP.
- Połączenie nie zostaje nawiązane: Sprawdź sygnalizację SIP, regułę zapory sieciowej, Application Control i możliwe blokady dostawcy.
- Połączenie działa, ale nie ma dźwięku: Sprawdź zakres portów RTP, NAT, trasę powrotną, SD-WAN i SIP Helper.
- Dźwięk jest słyszalny tylko w jednym kierunku: Sprawdź ścieżkę zwrotną RTP, NAT, routing, VPN i SD-WAN.
- Rozmowa zostaje przerwana po 30, 60 lub 120 sekundach: Sprawdź limit czasu UDP, utrzymywanie NAT, odświeżanie sesji i oczekiwania dostawcy.
- Nie działają tylko połączenia przychodzące: Sprawdź DNAT, regułę zapory sieciowej, sieci źródłowe dostawcy i współdzielenie portów PBX.
- Tylko jedna linia WAN powoduje problemy: Sprawdź trasę SD-WAN, ścieżkę odpowiedzi, bramę i powiązanie IP dostawcy.
Ta klasyfikacja uniemożliwia zmianę ustawień SIP, nawet jeśli rzeczywisty problem leży w ścieżce zwrotnej RTP lub trasie SD-WAN.
Sprawdź przed wprowadzeniem zmian
Przed wprowadzeniem zmian w CLI należy udokumentować aktualny stan:
- Których telefonów, PBX lub SBC dotyczy problem?
- Czy urządzenia końcowe rejestrują się bezpośrednio u operatora, czy wszystko odbywa się poprzez wewnętrzny system telefoniczny?
- Jakie serwery SIP i zakresy portów RTP ma nazwa dostawcy?
- Która reguła zapory przetwarza ruch VoIP?
- Czy w tej regule jest włączone Log firewall traffic?
- Która reguła NAT ma zastosowanie do wychodzącego i przychodzącego ruchu VoIP?
- Czy istnieje wiele linii WAN, tras SD-WAN lub sieci VPN opartych na trasach?
- Czy problem stał się widoczny po aktualizacji oprogramowania, zmianie dostawcy lub aktualizacji centrali?
Przetestuj reguły zapory sieciowej na Sophos Firewall pomaga w analizie reguł. W przypadku rzeczywistego przepływu pakietów wartość Packet Capture w WebAdmin jest zwykle bardziej znacząca niż czysty test zasad.
Sprawdź Pomocnika SIP
Pomocnik SIP, często nazywany także SIP ALG, próbuje rozpoznać pakiety SIP i dostosować informacje SIP istotne dla NAT. Może to być pomocne w prostych środowiskach. Jednak może to również powodować zakłócenia w wielu nowoczesnych konfiguracjach VoIP z dostawcą SBC, własną centralą PBX, TLS, utrzymywaniem czystego NAT lub bardziej złożonymi zakresami portów RTP.
Dlatego SIP Helper jest użytecznym punktem testowym, ale nie ogólnym, trwałym rozwiązaniem każdego problemu.Polecenia są wykonywane przez SSH na Sophos Firewall. Aby to zrobić, połącz się z zaporą sieciową i wybierz 4. Device Console. Dostęp SSH powinien być dozwolony tylko z zaufanych sieci. Podstawy są w Połącz się z Sophos Firewall przez SSH.
Pokaż aktualny stan modułu:
system system_modules show
Dezaktywuj moduł SIP:
system system_modules sip unload
Aktywuj ponownie moduł SIP:
system system_modules sip load
⚠️Zmiany tej należy dokonać w oknie serwisowym lub przy jasno określonych testach. Po wyłączeniu lub włączeniu należy sprawdzić rejestrację, połączenia wychodzące, połączenia przychodzące i dźwięk w obu kierunkach.
Jeżeli zmiana nie pomoże, należy ją cofnąć. Ważne jest udokumentowanie stanu przed i po badaniu.
Sprawdź i dostosuj limit czasu UDP
VoIP często korzysta z protokołu UDP. Jeśli wpisy NAT lub sesji wygasną zbyt wcześnie, może się wydawać, że rejestracja działa, ale połączenia są zrywane lub połączenia przychodzące nie docierają niezawodnie do centrali PBX.
Aktualny stan zaawansowanej zapory sieciowej jest wyświetlany w pliku Device Console:
show advanced-firewall
Typową wartością testową są sekundy 180:```shell
set advanced-firewall udp-timeout-stream 180
> ⚠️ `udp-timeout-stream` nie jest opcją sterowania wyłącznie VoIP, ale ma szerszy wpływ na sesje UDP. Wartość nie powinna być dowolnie wysoka. Lepiej mieć zdefiniowany test z dokumentacją starej wartości, wymagań dostawcy i późniejszą kontrolą sesji i jakości głosu.
Jeśli operator lub system telefoniczny obsługuje funkcję utrzymywania NAT, należy również sprawdzić to ustawienie. Czyste utrzymywanie aktywności po stronie centrali PBX lub dostawcy jest często lepsze niż bardzo wysoka globalna wartość limitu czasu.
## Sprawdź reguły zapory sieciowej i NAT
NAT jest często związany z problemami VoIP. Sophos Firewall musi nie tylko umożliwiać SIP, ale także poprawnie tłumaczyć i zwracać powiązane strumienie RTP w obu kierunkach.
Punkty te zazwyczaj dotyczą telefonów wychodzących lub wewnętrznej centrali PBX:
- odpowiednią regułę firewalla ze strefy VoIP lub strefy PBX do sieci WAN
- odpowiednia reguła SNAT lub MASQ
- Logowanie do reguły firewalla
- brak reguły zbyt szerokiej lub nieprawidłowo umieszczonej nad regułą VoIP
- brak nieoczekiwanego filtrowania tego ruchu przez Application Control, IPS lub siećDodatkowe punkty dodawane są za przychodzące łącza SIP trunk lub opublikowane systemy telefoniczne:
- DNAT do wewnętrznej centrali PBX lub SBC
- Reguła zapory sieciowej z odpowiednią strefą docelową i siecią docelową
- Ograniczenie do sieci źródłowych dostawców, jeśli to możliwe
- wymagane tylko porty SIP i RTP
- Rejestrowanie i Packet Capture do testów
Reguła NAT nie zezwala na ruch, a jedynie tłumaczy adresy lub porty. Połączenia opisano w [Poznaj NAT na Sophos Firewall](/pl/kb/sophos-firewall-nat-basics/). Jeśli centrala PBX musi być dostępna z Internetu, [Publikuj serwer poprzez DNAT](/pl/kb/sophos-firewall-dnat-serwer/) jest lepszą podstawą do faktycznej publikacji.
## Analizuj RTP i kierunek językowy
Jeśli połączenie zostanie nawiązane, ale brakuje dźwięku, SIP zwykle nie jest już głównym problemem. Następnie należy sprawdzić, czy RTP przepływa w obu kierunkach.
Typowy proces:
1. Zanotuj zakres portów dostawcy lub PBX RTP.
2. Uruchom Packet Capture ze źródłowym adresem IP centrali PBX lub telefonu i zakresem portów RTP.
3. Wykonaj połączenie testowe.
4. Sprawdź, czy widoczne są pakiety UDP z urządzenia wewnętrznego do dostawcy.
5. Sprawdź, czy pakiety UDP wracają od dostawcy.
6. Porównaj NAT ID, Rule ID, In interface i Out interface.Jeśli protokół RTP jest widoczny tylko na wyjściu, ale nic nie wraca, problem może leżeć po stronie dostawcy, ścieżki zwrotnej, NAT lub zdalnej stacji nadrzędnej. Jeśli protokół RTP wróci, ale nie zostanie przekazany do centrali PBX, bardziej prawdopodobne jest, że reguła zapory sieciowej, DNAT, routing lub mapowanie stref są bardziej prawdopodobne.
W przypadku bardziej precyzyjnych nagrań lub eksportu do PCAP przydatny może być `tcpdump` przez SSH. Proces opisano w [Sophos Firewall Użyj tcpdump do przechowywania dzienników i analiz](/pl/kb/sophos-firewall-zbieranie-logow-tcpdump-do-analizy/).
## SD-WAN, VPN i wiele linii WAN
VoIP jest wrażliwy na ścieżki asymetryczne. Jeśli protokół SIP działa przez linię WAN, ale protokół RTP powraca inną linią lub sieć VPN oparta na trasach jest kierowana inaczej, pojawiają się typowe błędy, takie jak jednostronny dźwięk.
Błąd naprawiony w SFOS 22.0 MR1 pokazuje typowe połączenie: po aktualizacji do SFOS 22.0 GA dźwięk VoIP mógł działać tylko w jedną stronę przez VPN opartą na trasach z routingiem SD-WAN. W praktyce oznacza to: SD-WAN należy zawsze sprawdzać podczas korzystania z VoIP przez VPN lub wiele ścieżek WAN.
Ważne punkty kontrolne:
- Czy trasa SD-WAN umożliwia dostęp do ruchu VoIP?
- Czy protokoły SIP i RTP są kierowane przez tę samą oczekiwaną linię WAN?
- Czy istnieją specyfikacje dostawcy dotyczące źródłowego adresu IP lub publicznego adresu nadawcy?
- Czy używana jest trasa VPN oparta na trasach z interfejsem XFRM?
- Czy trasy powrotne i NAT odpowiadają wybranej ścieżce?
- Czy Packet Capture pokazuje różne bramy lub interfejsy dla kierunków wychodzących i powrotnych?
W przypadku opcji SD-WAN specyficznych dla Sophos pasuje [Pakiet odpowiedzi routingu SD-WAN i ruch systemowy](/pl/kb/sd-wan-routing-dla-reply-packets-i-system-traffic/). [Sophos Firewall Rozwiązywanie problemów z IPsec](/pl/kb/sophos-firewall-ipsec-troubleshooting/) pomaga również w przypadku połączeń IPsec.
## Kształtowanie ruchu dla VoIP
Kształtowanie ruchu może ustabilizować VoIP, gdy linie są ciasne lub przesyłanie dużych ilości danych powoduje wypieranie pakietów głosowych. Nie rozwiązuje to jednak błędnych reguł NAT, brakujących portów RTP i nieprawidłowych tras powrotnych.
Kształtowanie ruchu jest szczególnie przydatne, jeśli:
- VoIP pogarsza się, gdy łącze internetowe jest obciążone,
- Przesyłanie lub kopie zapasowe zakłócają rozmowy,
- wiele aplikacji korzysta z tej samej linii,
- VoIP powinien być traktowany priorytetowo.
Konfiguracja jest opisana w [Kształtowanie ruchu aplikacji na Sophos Firewall](/pl/kb/sophos-firewall-application-traffic-shaping/). W przypadku VoIP należy nie tylko sprawdzić testy prędkości po wdrożeniu, ale także przeprowadzić rzeczywiste połączenia testowe przy jednoczesnym obciążeniu.
## Praktyczny sposób rozwiązywania problemów
1. Objawy dokumentu: rejestracja, konfiguracja połączenia, dźwięk, czas przerwania, kierunek.
2. Zbierz dane dostawcy: serwer SIP, transport, zakres portów RTP, wymagania NAT.
3. Zidentyfikuj regułę zapory sieciowej i regułę NAT.
4. Aktywuj logowanie w regule zapory, której dotyczy problem.
5. Otwórz Log Viewer i Packet Capture podczas połączenia testowego.
6. Sprawdź, czy sygnalizacja SIP działa w obu kierunkach.
7. Sprawdź, czy RTP działa w obu kierunkach.
8. Jeśli istnieje wiele linii WAN, sprawdź SD-WAN i ścieżkę zwrotną.
9. Przetestuj konkretnie SIP Helper i udokumentuj wyniki.
1
0. Dostosuj limit czasu UDP tylko świadomie i udokumentowany starą wartością.
1
1. Po każdej zmianie należy przetestować rejestrację połączeń wychodzących, przychodzących i audio w obu kierunkach.
Jeśli jednocześnie zostanie dokonanych kilka zmian, trudno jest zrozumieć następującą przyczynę. Lepszy jest jeden test na zmianę.
## Zbierz dowody podczas rozmowy testowej
Test VoIP jest pomocny tylko wtedy, gdy czas, kierunek i przepływ pakietów są zgodne. Szczególnie w przypadku dostawców stwierdzenie „Audio nie działa” nie wystarczy. Potrzebujesz małego, powtarzalnego przypadku testowego.
- **Dokładny czas ze strefą czasową:** Log Viewer, Packet Capture i logi dostawców można łatwo porównać później.
- **Kierunek połączenia:** połączenia przychodzące, wychodzące i przekierowania wewnętrzne nie są mieszane.
- **Numery telefonów lub numery wewnętrzne:** Dostawcy i centrale PBX szybciej znajdują określone połączenie.
- **Wewnętrzny adres IP centrali lub telefonu:** Packet Capture można filtrować wąsko.
- **Zakres serwera SIP dostawcy i zakresu portów RTP:** Analiza SIP i RTP pozostaje odrębna.
- **Rule ID, NAT ID, In interface i Out interface:** możesz zobaczyć, która reguła i która ścieżka zostały faktycznie użyte.
- **Wynik testu:** Rejestracja, dzwonienie, konfiguracja połączenia, dźwięk lewy/prawy i czas zakończenia pozostają identyfikowalne.
W przypadku sporadycznych błędów należy także wykonać kopię zapasową odpowiednich logów przed ich nadpisaniem. Do czystego pakietu kłód pasuje [Sophos Firewall Utwórz kopię zapasową dzienników w celu wsparcia i analizy](/pl/kb/logi-sophos-firewall-support-analiza/). Który plik dziennika należy do której usługi opisano w [Sophos Firewall Rozwiązywanie problemów: usługi i dzienniki](/pl/kb/sophos-firewall-uslugi-logi/).
## Typowe błędy
- **Włączony tylko port SIP, zapomniałem zakresu portów RTP:** Połączenie zostaje nawiązane, ale brakuje dźwięku.
- **Reguła NAT istnieje, ale nie ma pasującej reguły zapory sieciowej:** Ruch jest tłumaczony, ale nie jest dozwolony.
- **Reguła zapory sieciowej bez logowania:** Rozwiązywanie problemów w Log Viewer pozostaje ślepe.
- **Pomocnik SIP dezaktywowany lub aktywowany we wszystkich przypadkach:** Problem jest losowo przenoszony, a nie analizowany.
- **Ustawiono bardzo wysoki limit czasu UDP:** Globalne sesje UDP pozostają otwarte niepotrzebnie długo.
- **Wiele ścieżek WAN bez jasnej reguły SD-WAN:** Coraz bardziej prawdopodobne staje się jednokierunkowe przesyłanie dźwięku lub ruch odrzucony przez dostawcę.
- **Sieci źródłowe dostawcy nie są ograniczone:** Usługa SIP jest niepotrzebnie szeroko dostępna z Internetu.
- **Kształtowanie ruchu rozumiane jako zamiennik NAT/routingu:** Jakość głosu pozostaje niska, ponieważ przyczyna leży gdzie indziej.
## Wycofanie zmian i dokumentacja
Dokonując zmian w VoIP, zawsze powinno być jasne, jak wrócić:- udokumentowana stara wartość `udp-timeout-stream`
- Stan modułu SIP udokumentowany przed testowaniem
- Zmieniono reguły zapory sieciowej i NAT z datą i przyczyną
- Połączenia testowe rejestrowane z kierunkiem i czasem
- Packet Capture lub odpowiednie logi zabezpieczone do spraw wsparcia
Jeśli zmiana nie pomoże, nie należy jej pozostawiać jako przypadkowego dziedzictwa. W przeciwnym razie zwłaszcza rozwiązania VoIP będą później trudne do zrozumienia.
## Lista kontrolna
- Dostępne są informacje o protokole SIP i RTP dostawcy.
- Zidentyfikowano regułę zapory sieciowej dla VoIP i aktywne jest rejestrowanie.
- Reguła NAT odpowiada kierunkowi ruchu.
- SIP i RTP zostały sprawdzone oddzielnie.
- Packet Capture pokazuje kierunek tam i z powrotem.
- SIP Helper został specjalnie przetestowany.
- Limit czasu UDP został zmieniony jedynie z udokumentowaną wartością początkową.
- Sprawdzono SD-WAN, VPN i wiele linii WAN.
- Kształtowanie ruchu służy wyłącznie do kontroli jakości, a nie zastępuje routing lub poprawki NAT.
## Często zadawane pytania
Czy zawsze należy dezaktywować pomocnika SIP na Sophos Firewall?
Nie. Pomocnik SIP może pomóc lub przeszkodzić w zależności od operatora i systemu telefonicznego. Należy to specjalnie przetestować. Jeśli dezaktywacja nie przyniesie poprawy, należy przywrócić poprzedni stan.
Dlaczego połączenie działa, ale nic nie słychać?
Wtedy sygnalizacja SIP działa przynajmniej częściowo, ale strumień multimediów RTP nie działa poprawnie. Sprawdzasz zakres portów RTP, NAT, regułę zapory, trasę powrotną i, jeśli istnieje wiele ścieżek WAN, SD-WAN.
Czy wyższy limit czasu UDP pomaga w przypadku problemów z VoIP?
Czasami tak, szczególnie w przypadku zerwanych połączeń lub niestabilnych rejestracji. Wartość ta ma jednak szerszy wpływ na sesje UDP i dlatego powinna być świadoma, udokumentowana i nie ustawiana niepotrzebnie wysoko.
Co jest ważne w przypadku VoIP przez SD-WAN?
SIP i RTP powinny działać oczekiwaną ścieżką. Jeśli podróże w obie strony korzystają z różnych linii WAN lub ścieżek VPN, mogą wystąpić jednostronne połączenia audio lub odrzucone.