Dlaczego Firewall Checker nie kłamie

3CX Firewall Checker to niezbędne, wbudowane narzędzie, które automatycznie sprawdza konfigurację zapory sieciowej pod kątem przekierowania i zachowania portów. Niniejszy dokument wyjaśnia podstawowe pojęcia stojące za tymi testami oraz sposób, w jaki narzędzie to zapewnia optymalną komunikację systemu 3CX przez protokół UDP. Aby zweryfikować łączność TCP, można użyć dowolnego z powszechnie dostępnych walidatorów portów TCP.

Przekierowanie portów (Port Forwarding)

3CX weryfikuje, czy funkcja „Full Cone NAT” jest poprawnie skonfigurowana na Twoim firewallu lub bramie sieciowej. Full Cone NAT pozwala dowolnemu podmiotowi zewnętrznemu na połączenie się z 3CX bez konieczności uprzedniego potwierdzenia przez firewall, że pakiet pochodzi z 3CX. Jest to kluczowe dla dostawców VoIP, ponieważ serwer SIP (źródłowy adres IP) obsługujący sygnalizację może nie być tym samym serwerem, który przesyła właściwy dźwięk do Twojego systemu. Bez Full Cone NAT niektóre zapory mogą blokować ruch przychodzący, uniemożliwiając połączenie, nawet jeśli to 3CX zainicjuje komunikację.

Zachowanie portów (Port Preservation)

Zachowanie portów to kolejny krytyczny czynnik sprawdzany przez Firewall Checker. Narzędzie wykrywa, czy zapora sieciowa zmienia numer portu podczas translacji z lokalnego adresu IP sieci LAN na publiczny adres IP sieci WAN. Chociaż standardy RFC definiują, że serwer SIP powinien odpowiadać na adres IP i port „kontaktowy” określony w treści wiadomości SIP, niektórzy dostawcy mogą odpowiadać na port źródłowy transportu 3CX widoczny w nagłówku UDP. Aby zapobiec potencjalnym problemom, Firewall Checker sprawdza, czy wiadomość SIP wygenerowana przez 3CX z konkretnego lokalnego portu źródłowego (np. 5060) pozostaje niezmieniona po translacji na publiczny adres IP.

Narzędzie wykonuje te testy przy użyciu pierwszego skonfigurowanego serwera STUN w systemie, który różni się w zależności od regionu (często jest to stun.3cx.com). Zdecydowanie zaleca się nie zmieniać tego ustawienia. W istocie Firewall Checker programowo wykrywa publiczny adres IP i rozszerza tę funkcjonalność o weryfikację mapowania portów.

Jak uruchomić Firewall Checker

3Serwery STUN 3CX, które należy dodać do białej listy dla pomyślnego testu:

• 34.40.60.101
• 34.40.164.62
• 34.83.212.229
• 34.138.123.132

Aby uruchomić Firewall Checker:

• Przejdź do Konsoli Administracyjnej 3CX.
• Przejdź do sekcji „Dashboard” (Panel).
• Zlokalizuj sekcję „Firewall Checker” i kliknij ją, aby przejść do zakładki testowania.
• Kliknij „Start”, aby rozpocząć testy.
• Podczas tego procesu usługi PBX zostaną zatrzymane i uruchomione ponownie; możesz przerwać test, naciskając „Stop”.

• Wyniki będą wyświetlane i aktualizowane na bieżąco, wskazując, czy dany test zakończył się sukcesem, czy niepowodzeniem.

Zrozumienie wyników Firewall Checker

Poniżej znajduje się przykład nieudanego testu zgłoszonego przez Konsolę Administracyjną 3CX.

Firewall Checker wykonuje serię testów w celu sprawdzenia konfiguracji sieci. Poniżej szczegółowo opisujemy podjęte kroki i oczekiwane rezultaty.

UWAGI:

• Test portów weryfikuje bloki parzystych portów na początku i na końcu prawidłowego zakresu, aby skrócić czas trwania testu. Musisz upewnić się, że cały zakres portów wymagany przez centralę PBX jest w pełni przepuszczony przez firewall, bez żadnych luk.
• W przypadku instalacji na systemie Windows zaleca się wyłączenie zapory systemu Windows na serwerze 3CX podczas testowania. Chociaż 3CX tworzy wyjątki dla swoich aplikacji, może nie utworzyć ich dla samego narzędzia Firewall Checker.

Test 1: Zachowanie portów i łączność wychodząca

W Teście 1 system 3CX tymczasowo zatrzymuje swoje usługi, aby zwolnić lokalne porty wymagane do testów. Procedura jest taka sama dla wszystkich portów, ale skupimy się na domyślnym porcie SIP (5060).

Serwer 3CX wykonuje następujące czynności:

• Wysyła żądanie „classic-stun” ze swojego lokalnego adresu IP (np. 192.168.3.159) do skonfigurowanego serwera STUN (np. stun.3cx.com).
• Żądanie pochodzi z lokalnego portu UDP (np. 5060).
• Jest wysyłane na domyślny port serwera STUN (3478).
• Żądanie wyraźnie instruuje serwer STUN, aby NIE zmieniał adresu IP ani portu podczas odpowiadania.

Każde żądanie zawiera unikalny identyfikator transakcji („transaction ID”), aby zapewnić niezawodne dopasowanie odpowiedzi.

Jeśli serwer wysyła wiele żądań, ale nie otrzymuje odpowiedzi, wskazuje to na:

• zablokowanie ruchu wychodzącego przez firewall, lub
• brak powrotnego ruchu sieciowego do serwera.

W obu przypadkach należy sprawdzić ustawienia zapory sieciowej.

Serwer STUN powinien odpowiedzieć:

• Komunikatem „Binding Response”.
• Określa on publiczny adres IP i port, z którego wysłano żądanie (np. publiczny IP XX.XX.96.162 i port 5060).

Na tej podstawie, jeśli pole „Mapped-Address” w odpowiedzi STUN pokazuje ten sam port (np. 5060), co port źródłowy początkowego żądania, oznacza to, że zachowanie portów działa poprawnie. Jeśli w polu „Mapped-Address” widnieje jakikolwiek inny port, test zakończy się niepowodzeniem. W takim przypadku należy skontaktować się z producentem firewalla w celu uzyskania pomocy.

Test 2: Walidacja Full Cone NAT

W Teście 2 serwer 3CX wysyła kolejne żądanie do tego samego serwera STUN. Jednak tym razem:

• Serwer 3CX oznacza żądanie parametrem „Change IP and Change Port” ustawionym na (1).
• Instruuje to serwer STUN, aby wysłał odpowiedź z adresu IP i portu innego niż ten, na który wysłano początkowe żądanie.
• Ten nowy źródłowy adres IP/port jest nieznany dla firewalla, który zazwyczaj spodziewałby się odpowiedzi od oryginalnego miejsca docelowego.

Jeśli serwer wysyła wiele żądań, nie otrzymując odpowiedzi od serwera STUN, oznacza to, że Full Cone NAT nie działa.

W przeciwieństwie do Testu 1, gdzie 3CX oczekuje odpowiedzi od serwera, z którym nawiązał kontakt, Test 2 symuluje odbieranie danych ze źródła, z którym 3CX nie „rozmawiał” bezpośrednio (podobnie jak serwer audio u dostawcy VoIP). Brak odpowiedzi oznacza, że firewall blokuje tego typu ruch. W takiej sytuacji należy skontaktować się z producentem zapory.

Pomyślna odpowiedź w Teście 2 pokazałaby w polu „Mapped-Address” dokładnie ten sam adres IP i port, co w Teście 1. Jeśli chcesz zbadać sprawę głębiej, sprawdź logi firewalla pod kątem ruchu z adresów IP serwerów STUN 3CX – oczekiwana odpowiedź prawdopodobnie nigdy nie dotarła do interfejsu sieciowego serwera 3CX.

Test SIP ALG

3CX sprawdza również, czy na Twoim firewallu włączona jest funkcja SIP ALG (Application Layer Gateway). Funkcje SIP ALG sprawdzają zawartość pakietów SIP oprócz samych list dostępu IP/port. Dla administratorów 3CX może to być źródłem licznych problemów, ponieważ zmiany wprowadzone w wiadomościach SIP przez węzeł pośredni (firewall) nie będą widoczne w śladach (traces) 3CX, co prowadzi do problemów z kompatybilnością ze zdalnymi telefonami IP lub dostawcami VoIP.

Proces walidacji:

• 3CX generuje generyczną wiadomość INVITE i wysyła ją do usługi online hostowanej przez 3CX. Tylko publiczny adres IP jest specyficzny; wszystkie inne informacje są ogólne.

• 3CX lokalnie oblicza wartość skrótu CRC32 z wysłanej wiadomości i oczekuje, że usługa online zwróci tę samą wartość w odpowiedzi.

• Jeśli wartość zwrotna „X-CSREQ” zgadza się z wartością obliczoną lokalnie, oznacza to, że SIP ALG nie zmodyfikował wiadomości lub nie jest aktywny. Jeśli wartości się różnią, test wykazuje, że węzeł pośredni między 3CX a usługą online zmienił treść, co oznacza aktywną funkcję SIP ALG.

Obliczanie oczekiwanej wartości skrótu (Hash)

Możesz ręcznie zweryfikować oczekiwaną wartość skrótu, przechwytując wychodzące zapytanie INVITE do usługi wykrywania SIP ALG za pomocą Wireshark:

• Kliknij prawym przyciskiem myszy na wiadomość INVITE wysłaną z 3CX w programie Wireshark.
• Wybierz „Copy” > „Bytes” > „Hex Stream”.

• Otwórz kalkulator CRC online (np. http://www.sunshine2k.de/coding/javascript/crc/crc_js.html).
• Wklej skopiowany ciąg hex w pole „CRC Input Data”.

• Obliczony wynik musi zgadzać się z wartością zwróconą w nagłówku „X-CSREQ” odpowiedzi „200 OK”.

Rozwiązywanie typowych problemów z zapaporą sieciową (firewallem)

Jeśli test Firewall Checker zakończy się niepowodzeniem, rozważ następujące kroki:

• Wyłącz SIP ALG: Upewnij się, że SIP ALG lub jakiekolwiek funkcje typu „SIP Helper” są wyłączone na Twoim routerze/firewallu. Jest to najczęstsza przyczyna problemów z protokołem SIP.
• Przekierowanie portów: Sprawdź, czy wszystkie niezbędne porty są poprawnie przekierowane do Twojego systemu 3CX. Kluczowe porty to:

• SIP Trunk / Dostawca VoIP:

• Port 5060 (przychodzący, UDP) oraz 5060-5061 (przychodzący, TCP) dla SIP.
• Porty 9000-10999 (przychodzące, UDP) dla RTP (Audio).

• Zdalne aplikacje 3CX i SBC:

• Port 5090 (przychodzący, UDP i TCP) dla tunelu 3CX.
• Port 443 lub 5001 (przychodzący, TCP) dla HTTPS (Status i autokonfiguracja).
• Port 443 (wychodzący, TCP) dla powiadomień PUSH Google Android.
• Porty 443, 2197 i 5223 (wychodzące, TCP) dla powiadomień PUSH Apple iOS.

• Wideokonferencje 3CX:

• Port 443 (przychodzący, TCP) dla uczestników.
• Port 443 (wychodzący, TCP) z systemu 3CX do chmury 3CX.
• Porty 443 (wychodzący, TCP) oraz 48000-65535 (wychodzący, UDP) od użytkowników do wymiany audio/wideo.

• Logi firewalla: Sprawdź dzienniki zapory pod kątem zablokowanych połączeń związanych z portami używanymi przez 3CX, szczególnie podczas trwania testu Firewall Checker.
• Reguły ACL/Firewall: Zdefiniuj odpowiednie reguły ACL/firewall, aby umożliwić hostowi 3CX dostęp do wymaganych podsieci i punktów końcowych wewnątrz oraz na zewnątrz sieci.

Zobacz również

• Konfiguracja zapory sieciowej i routera 

Ostatnia aktualizacja
Ten dokument został ostatnio zaktualizowany 2 czerwca 2026 r.
https://www.3cx.pl/docs/firewall-checker/