Rozwiązywanie problemów VoIP SIP i RTP na Sophos Firewall

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.

Analiza RTP w obu kierunkach

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. Ogranicz Packet Capture do adresu IP centrali PBX lub telefonu oraz zakresu portów RTP. Uwzględnij oba kierunki, ponieważ urządzenie wewnętrzne jest źródłem albo celem zależnie od kierunku pakietu.
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, Out interface i Gateway ID. Gdy brakuje pakietów, sprawdź również Status i Reason; Violation oznacza odrzucony przepływ.

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.

Sprawdzić SIP Helper

SIP Helper, nazywany też SIP ALG, domyślnie rozpoznaje SIP na porcie UDP 5060, tłumaczy adresy lokalne w nagłówku SIP i dynamicznie otwiera oczekiwany kanał głosowy. Na rzeczywistym przepływie rozmowy trzeba sprawdzić, czy te działania pasują do projektu dostawcy i PBX. Niektórzy producenci PBX wyraźnie wymagają wyłączenia SIP ALG, a inne wdrożenia potrzebują działania Helpera.

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 przywrócić dokładnie poprzedni stan:

• Jeśli sip miał stan unloaded, użyj system system_modules sip unload.
• Jeśli moduł był załadowany na domyślnym porcie UDP 5060, użyj system system_modules sip load.
• Jeśli był załadowany na porcie niestandardowym, użyj system system_modules sip load ports <previous_custom_port>. <previous_custom_port> musi być portem zapisanym przed zmianą.

Nie rozpoczynaj testu, jeśli wcześniejszy port niestandardowy nie jest pewny. Zwykłe load nie jest wtedy dokładnym wycofaniem, ponieważ ładuje Helper na porcie domyślnym.

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

Następnie od razu ponownie uruchom show advanced-firewall. Wykonaj tę samą rozmowę testową dopiero wtedy, gdy pojawi się UDP Timeout Stream : 150. Po wycofaniu ta sama kontrola musi pokazać wcześniej zapisaną wartość.

⚠️ 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 linia bazowa pokazała na przykład UDP Timeout Stream : 60, dokładne wycofanie ma postać:

set advanced-firewall udp-timeout-stream 60

Wartość 60 jest prawidłowa tylko dla takiej linii bazowej. Jeżeli zapora pokazała inną wartość, należy bez zmian wstawić ją do polecenia wycofania.

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.

H.323, VPN i conntrack jako przypadki szczególne

Poniższe wskazówki Sophos mają zastosowanie tylko do ściśle potwierdzonego problemu. Zmieniają globalne ustawienia helpera, IPS lub VPN albo aktywną sesję i nie są ogólnym dostrajaniem VoIP.

W przypadku H.323 za zrywanie dźwięku lub obrazu albo działanie tylko w jednym kierunku mimo prawidłowych reguł zapory i DNAT może odpowiadać załadowany Helper. Najpierw udokumentuj stan początkowy poleceniem system system_modules show. Sophos zaleca następujący kontrolowany test:

system system_modules h323 unload

Ponownie odczytaj stan modułu, a następnie powtórz tę samą rozmowę testową z dźwiękiem lub obrazem w obu kierunkach. Jeśli h323 był już wyładowany, polecenie nie utworzyło nowego stanu testowego.

Jeśli moduł był wcześniej załadowany, a problem pozostał, wycofaj test poleceniem:

system system_modules h323 load

Wspomniany również przez Sophos projekt przezroczystej bramy podsieci z proxy ARP jest zmianą architektury, a nie uniwersalnym kolejnym krokiem. Dopiero potwierdzona ścieżka ARP i routingu wskazuje, czy Proxy ARP na Sophos Firewall pasuje do tej topologii.

W przypadku problemów VoIP przez VPN site-to-site lub z IPS Sophos wskazuje dwa ustawienia globalne. sip_preproc skanuje sesje SIP pod kątem ataków sieciowych i jest domyślnie włączony. conn-remove-tunnel-up określa, czy połączenia są usuwane podczas zestawiania tunelu IPsec.

Przed testem skoreluj zerwanie rozmowy ze zdarzeniem tunelu. Odczytaj początkową wartość IPS w Device Console:

show ips-settings

Jeśli sip_preproc ma jednoznacznie wartość enable, można przeprowadzić udokumentowany przez Sophos test w oknie serwisowym:

set ips sip_preproc disable

Ponownie uruchom show ips-settings i powtórz tę samą rozmowę testową. Wyłączenie ogranicza globalnie kontrolę ataków SIP. Jeśli test nie pomoże, dokładne wycofanie dla odczytanej wcześniej wartości enable to set ips sip_preproc enable; następnie show ips-settings musi ponownie pokazać enable. Jeśli wartość początkowa wynosi już disable albo nie można jej jednoznacznie odczytać, nie należy jej zmieniać.

Dla tego samego problemu Sophos wskazuje też set vpn conn-remove-tunnel-up disable. Aktualna pomoc CLI dla SFOS 22 nie dokumentuje jednak odpowiadającego polecenia odczytu ani uniwersalnej wartości początkowej. Nie należy zmieniać tego ustawienia wyłącznie na podstawie artykułu. Sophos Support musi najpierw potwierdzić rzeczywistą wartość i dokładny sposób wycofania dla zainstalowanego buildu. Bezpieczne używanie globalnych ustawień VPN wyjaśnia działanie ustawienia.

Jeśli telefon rejestruje się w PBX z adresem IP zapory zamiast z własnym adresem, najpierw należy porównać Log Viewer, Firewall Rule ID, NAT Rule ID i stan helpera dla działającego i problematycznego telefonu. Utworzenie zwykłej nowej sesji telefonu lub PBX jest bezpieczniejsze niż ingerencja w conntrack. Jeśli utrzymuje się jednoznacznie nieprawidłowy wpis TCP, Sophos wskazuje jako ostatni ukierunkowany krok w Advanced Shell:

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

Symbole zastępcze należy zastąpić wyłącznie potwierdzonymi adresami. Polecenie usuwa odpowiadającą aktywną sesję TCP i natychmiast ją przerywa; nie należy rozszerzać jego zakresu ani dostosowywać go do UDP. Live Connections na Sophos Firewall wyjaśnia, jak najpierw zawęzić przepływ w Diagnostics > Connection list.

Następnie telefon musi zarejestrować się ponownie. Sukces oznacza, że Log Viewer pokazuje własny adres IP telefonu, a kolejne połączenie testowe działa. Jeśli ponownie pojawi się adres IP zapory, nie powtarzaj usuwania; zbadaj NAT i działanie Helpera z Sophos Support.

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
• stan początkowy H.323 i sip_preproc udokumentowany i przywrócony po nieudanym teście szczególnym; conn-remove-tunnel-up pozostawione bez zmian bez potwierdzonej wartości początkowej
• 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