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ą.

Ten artykuł przedstawia rozwiązywanie problemów VoIP na Sophos Firewall jako uporządkowany proces. Typowe szybkie rozwiązania, takie jak wyłączenie SIP Helper lub zwiększenie limitu czasu UDP, są jedynie kontrolowanymi testami. Najpierw należy ustalić ścieżkę pakietów, faktycznie używane reguły zapory i NAT oraz przeanalizować SIP i RTP oddzielnie.

Zrozumieć SIP, RTP i objawy

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, dźwięk jednokierunkowy lub przerwanie po krótkim czasie.

SIP często korzysta z UDP lub TCP 5060, a szyfrowany SIP często z 5061. Nie są to wartości uniwersalne. Wielu dostawców używa innych portów, serwerów proxy lub dodatkowych wymagań dotyczących NAT keepalive.

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.

Zarejestrować stan wyjściowy przed zmianami

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?

Testowanie reguł zapory na Sophos Firewall pomaga w analizie reguł. Dla rzeczywistego przepływu pakietów Packet Capture w WebAdmin jest zwykle bardziej miarodajny niż sam Policy Test. Globalne wartości CLI należy zmieniać dopiero po zebraniu tej linii bazowej i przygotowaniu powtarzalnego połączenia testowego.

Sprawdzić ścieżkę pakietów, routing i jakość

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 Application Control, IPS lub Web Filtering dla tego ruchu

To, czy przychodzący trunk SIP wymaga DNAT, zależy od projektu dostawcy. Trunki oparte na rejestracji mogą korzystać z istniejącej sesji wychodzącej. Trunki dostarczane bezpośrednio na adres publiczny lub opublikowane systemy telefoniczne zwykle wymagają precyzyjnie ograniczonej reguły DNAT. Wiążące są wymagania dostawcy lub operatora SBC.

Jeżeli DNAT jest wymagany, należy również sprawdzić:

• 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. Jeśli centrala PBX musi być dostępna z Internetu, Publikuj serwer poprzez DNAT 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żeli RTP jest widoczny tylko w kierunku wychodzącym i nic nie wraca, problem może leżeć po stronie dostawcy, ścieżki zwrotnej, NAT lub urządzenia nadrzędnego. Jeżeli RTP wraca, ale nie jest przekazywany do PBX, bardziej prawdopodobne są problemy z regułą zapory, DNAT, routingiem lub przypisaniem strefy.

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.

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. Sophos Firewall Rozwiązywanie problemów z IPsec 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. 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.

Kontrolowane testowanie SIP Helper i UDP Timeout

Poniższe ustawienia wpływają na więcej niż jedną regułę VoIP. Należy je testować dopiero po zawężeniu przyczyny, z udokumentowaną linią bazową, oknem serwisowym i jasnym planem wycofania.

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.

SIP Helper jest więc użytecznym punktem testowym, ale nie uniwersalnym rozwiązaniem stałym. Sophos dokumentuje, że moduły systemowe są domyślnie załadowane.

Polecenia wykonuje się przez SSH na Sophos Firewall w 4. Device Console. Dostęp SSH powinien być dozwolony tylko z zaufanych sieci. Podstawy opisano w Połączenie z Sophos Firewall przez SSH.

Pomoc CLI SFOS 22 dokumentuje load i unload dla modułu SIP, ale nie ogólne polecenie system system_modules show. Dlatego w dzienniku prac należy zapisać znany stan początkowy i każde wykonane polecenie, zamiast polegać na domniemanym poleceniu statusu.

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.

Sophos rozróżnia dwie wartości globalne:

• udp-timeout dotyczy połączeń UDP, które nie zostały jeszcze rozpoznane jako strumień dwukierunkowy.
• udp-timeout-stream dotyczy ustanowionych strumieni UDP, w których oba punkty końcowe wysłały ruch przez ten sam port między segmentami sieci.

W SFOS 22 obie wartości przyjmują od 30 do 3600 sekund. Bieżące wartości Advanced Firewall wyświetla się w Device Console:

show advanced-firewall

180 sekund jest częstym przykładem diagnostycznym, a nie ogólnym zaleceniem Sophos. Jeżeli Packet Capture i czas przerwania wskazują na zbyt krótki timeout strumienia, wartość można przetestować w kontrolowany sposób:

set advanced-firewall udp-timeout-stream 180

⚠️ udp-timeout-stream nie jest opcją pojedynczej reguły VoIP. Wpływa na wszystkie pasujące strumienie UDP. Nie należy zwiększać go na próbę ani arbitralnie. Przed testem trzeba zapisać starą wartość z show advanced-firewall i przywrócić ją tym samym poleceniem set, jeżeli test nie pomoże.

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.

Rozwiązywanie problemów i materiały diagnostyczne

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.
10. Zmień timeout UDP tylko świadomie i po udokumentowaniu starej wartości.
11. Po każdej zmianie przetestuj rejestrację, połączenia wychodzące, połączenia przychodzące i dźwięk 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. Który plik dziennika należy do której usługi opisano w Sophos Firewall Rozwiązywanie problemów: usługi i dzienniki.

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.

Bezpiecznie wycofać zmiany

Przy każdej zmianie VoIP musi być jasne, jak ją wycofać:

• stare wartości udp-timeout i udp-timeout-stream udokumentowane, jeżeli są zmieniane
• test SIP load lub unload oraz docelowy stan końcowy udokumentowane
• zmienione reguły zapory i NAT zapisane z datą i powodem
• połączenia testowe zapisane z kierunkiem i czasem
• Packet Capture lub odpowiednie logi zachowane dla zgłoszeń do 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.

Operacyjna 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