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.

Sophos Firewall obsługuje również H.323 obok SIP. Ten runbook koncentruje się na sygnalizacji SIP i RTP. Jeśli system telefoniczny faktycznie korzysta z H.323, usługę H.323 i H.323 Helper trzeba sprawdzić oddzielnie; ustawienia SIP Helper nie są wtedy automatycznie właściwym miejscem do interwencji.

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, UDP Timeout i DoS

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ł SIP jest domyślnie włączony. Zmiany wykonane za pomocą load lub unload pozostają aktywne po ponownym uruchomieniu.

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.

Bieżący stan należy wyświetlić przed każdą zmianą i po niej za pomocą polecenia tylko do odczytu:

system system_modules show

Trzeba udokumentować wynik dla wpisu sip. Dzięki temu wiadomo, czy Helper był załadowany przed testem i jaki stan jest oczekiwany po rollbacku.

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.

Jeśli dostawca używa niestandardowego portu sygnalizacji SIP zamiast UDP 5060, Helper można załadować dokładnie z tym portem:

system system_modules sip load ports <custom_port>

<custom_port> należy zastąpić portem SIP wskazanym przez dostawcę lub producenta PBX, a nie całym zakresem portów RTP. SIP Helper obsługuje porty mediów od 1024 do 65535. Jeśli używany port mediów leży poza tym zakresem, zapora może odrzucić ruch, a w dzienniku zdarzeń pojawi się Invalid Traffic.

SIP przez TCP ma jeszcze jedno ograniczenie: Helper nie obsługuje wiadomości SIP lub SDP rozłożonej na wiele pakietów. Jeśli Packet Capture pokazuje dokładnie taki wzorzec, rodzaj transportu trzeba wyjaśnić z dostawcą i producentem PBX. Przejście na SIP przez UDP ma sens tylko wtedy, gdy obsługują je obie strony.

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

Aktualna pomoc SFOS 22 podaje 60 sekund jako wartość domyślną UDP Timeout Stream i zaleca 150 sekund dla VoIP. Decydujące pozostają jednak faktycznie wyświetlana wartość i wymagania dostawcy. Jeżeli Packet Capture i czas przerwania wskazują na zbyt krótki timeout strumienia, udokumentowaną wartość można przetestować w kontrolowany sposób:

set advanced-firewall udp-timeout-stream 150

⚠️ 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.

Sprawdzić progi UDP flood

VoIP generuje wiele pakietów UDP. Jeśli progi w Intrusion prevention > DoS & spoof protection > DoS settings są zbyt niskie, zapora może odrzucać prawidłowy ruch SIP lub RTP jako UDP flood. Przed zmianą należy udokumentować aktualne wartości Packet rate, Burst rate i Apply flag oraz liczniki odrzuceń.

Sophos wskazuje tymczasowe usunięcie Apply flag dla UDP flood jako test diagnostyczny. Zmniejsza to ochronę DoS podczas testu, dlatego wymaga okna serwisowego i ściśle określonego przypadku testowego. Jeśli jakość VoIP się poprawi, należy dostosować Packet rate i Burst rate do zmierzonego prawidłowego obciążenia i ponownie ustawić Apply flag. Jeśli problem się nie zmieni, trzeba natychmiast przywrócić stan początkowy.

Ukierunkowany wyjątek dla znanych hostów lub portów może być bezpieczniejszy niż globalne wyłączenie. Spoof Protection i ochrona DoS na Sophos Firewall wyjaśnia współdziałanie progów i DoS bypass rules. Po teście ochrona nie może pozostać wyłączona.

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. Sprawdź stan SIP Helper, przetestuj konkretną zmianę i udokumentuj wynik.
10. Zmień timeout UDP tylko świadomie i po udokumentowaniu starej wartości.
11. W przypadku odrzuceń UDP lub problemów z jakością pod obciążeniem sprawdź progi UDP flood w kontrolowany sposób.
12. 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.
• Dziennik zdarzeń i liczniki DoS: Invalid Traffic lub rosnąca liczba odrzuceń UDP flood pomagają zawęzić problem do zakresu portów Helpera albo progów DoS.
• 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.
• Niestandardowy port SIP pomylony z zakresem portów RTP: Helper zostaje załadowany na niewłaściwym porcie sygnalizacyjnym.
• Ustawiono bardzo wysoki limit czasu UDP: Globalne sesje UDP pozostają otwarte niepotrzebnie długo.
• Ochrona UDP flood jest zbyt restrykcyjna lub trwale wyłączona: Prawidłowe pakiety głosowe są odrzucane albo ochrona pozostaje niepotrzebnie ograniczona po teście.
• 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, unload lub niestandardowego portu oraz docelowy stan końcowy udokumentowane
• pierwotne progi UDP flood i Apply flags udokumentowane i przywrócone po teście
• 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.
• Stan SIP Helper został sprawdzony przed ukierunkowanym testem i po nim.
• Niestandardowy port SIP odpowiada specyfikacji dostawcy lub PBX i nie jest mylony z zakresem portów RTP.
• Limit czasu UDP został zmieniony jedynie z udokumentowaną wartością początkową.
• Po teście progi UDP flood i ochrona DoS zostały przywrócone do bezpiecznego stanu docelowego.
• 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