Принцип работы 3CX Firewall Checker

3CX имеет встроенный сервис автоматической проверки сетевого экрана 3CX Firewall Checker. Он проверяет корректность переадресации (port forwarding) и резервирования портов (port preservation).

Переадресация портов Port Forwarding

3CX может проверить, правильно ли настроен "Full Cone NAT" на вашем сетевом экране или маршрутизаторе. Технология Full Cone NAT позволяет любому внешнему устройству подключаться к серверу 3CX без предварительного встречного трафика от сервера 3CX. Т.е. входящее соединение разрешается автоматически. Это важно для VoIP-провайдеров, поскольку SIP-сервер провайдера может не совпадать с медиасервером (который доставляет аудиотрафик на вашу систему 3CX). Некоторые сетевые экраны активно "запрещают" входящий трафик, что не позволяет установить соединение, даже если 3CX будет отправлять аудиотрафик на медиасервер провайдера.

Резервирование портов Port Reservation

Резервирование портов - еще один фактор, который проверяет Firewall Checker. Сервис определяет, не изменяет ли сетевой экран порт при трансляции трафика из LAN в WAN. С технической точки зрения это не должно иметь значения. Однако сервер провайдера, в зависимости от реализации, может отвечать на порт источника, указанный в заголовке UDP, или же следовать рекомендациям RFC. RFC определяет, что SIP-сервер ДОЛЖЕН отвечать на IP и порт, указанные в заголовке "Contact" SIP-сообщения. Для того чтобы исключить случайности, Firewall Checker также проверяет маппинг портов. При генерации SIP-сообщения на сервере 3CX с исходного порта 5060 (порт SIP по умолчанию) и последующей трансляции на публичный IP-адрес (WAN порт), исходный порт также должен сохраняться (5060 в этом примере).

Во время проверки Firewall Checker выполняет два независимых теста, используя первый настроенный сервер STUN в вашей системе. По умолчанию это stun.3cx.com - настоятельно рекомендуем не изменять эту настройку. В целом, Firewall Checker - это программный механизм определения вашего публичного IP-адреса, аналогичный сайтам "what is my IP", но дополненный проверкой портов.

Примеры

Ниже показана неуспешная проверка сетевого экрана. Результат отображается в интерфейсе управления 3CX. Также показан соответствующий захват трафика в программе Wireshark. В этом руководстве мы подробно рассмотрим проверки, выполняемые Firewall Checker, и покажем результаты этих проверок. Захват Wireshark ограничен портами 3378 или 3379, на которых основан данный тест. Важно, чтобы сетевой экран Windows был отключен. Инсталлятор 3CX создает исключения для некоторых сервисов 3CX, но не для Firewall Checker!

Тест 1

3CX останавливает работу сервисов, чтобы освободить локальный порт и связать его с Firewall Checker. В данном примере рассматривается только первый тестируемый порт (5060), а для остальных портов процедура аналогична.

На скриншоте выше показано:

1. Локальный сервер 3CX с IP-адресом 192.168.3.159 посылает классический запрос stun на stun.3cx.com с IP 198.50.247.220.
2. С локального порта 5060 UDP.
3. На порт 3478, который является портом stun-сервера по умолчанию.
4. Объявляется, что STUN-сервер НЕ должен менять свои IP или порт при ответе на этот запрос.

Каждый запрос имеет уникальный "ID транзакции", который позволяет надежно сопоставить принадлежность полученных данных первоначальному запросу. В редких случаях можно наблюдать, что сервер посылает несколько запросов, но так и не получает ответа (как показано ниже). Это означает, что:

a) Исходящий трафик был заблокирован сетевым экраном или b) Обратный трафик не был передан на сервер. В обоих случаях проверьте настройки сетевого экрана.

Сервер STUN отвечает с такими данными:

1. Binding Response на запрос.
2. Затем определяется, что публичный IP и порт, с которого был отправлен запрос, равен порту 5060, а IP-адрес - XX.XX.96.162.

Исходя из ранее приведенного определения, резервирование портов работает, поскольку stun-сервер видит АТС по заданному порту. Если в поле "Mapped-Address" указан любой другой порт, то проверка сетевого экрана будет неудачной, и резервирование портов НЕ будет работать корректно. В этом случае для решения проблемы следует обратиться к производителю сетевого экрана.

Тест 2

В Тесте 2 сервер посылает запрос на тот же самый stun-сервер, что и в предыдущем примере.

Следующий запрос:

1. Сервер 3CX отмечает, что запрос отличается от предыдущего, и устанавливает значение "Change IP and Change Port" в (1). Это означает, что stun должен отправить свой ответ обратно на 3CX, однако с IP-адреса и порта, которые теперь неизвестны сетевому экрану, ожидающему ответ.
2. Мы видим, что сервер отправил один и тот же запрос 3 раза, не получив ответ от сервера STUN. Это указывает на то, что Full Cone NAT в сетевом экране не работает.
   

По сравнению с тестом 1, где сервер 3CX посылает данные на сервер stun и получает ответы, тест 2 показывает, что данные возвращаются от источника, с которым 3CX никогда не общался (т.е. медиасервер VoIP-провайдера). И во втором случае ответы не доходят. Для решения этой проблемы следует обратиться к производителю сетевого экрана.

Правильным результатом будет получение ответа во втором тесте, причем "Mapped-Address" будет точно такой же, как в тесте 1 для IP-адреса и порта.

Если вы хотите узнать, откуда должен был прийти трафик, проверьте в журналах сетевого экрана IP-адреса серверов 3CX STUN. Ожидалось, что ответ придет с серверов 3CX STUN, но он так и не поступил на сетевую карту 3CX.

Тест SIP ALG (начиная с V15.5 SP1)

В дополнение к существующему тесту NAT, 3CX проверяет, включен ли в сетевом экране SIP ALG. SIP ALG - это сервис сетевого экрана, проверяющий, помимо правил доступа (from и to IP/Ports), внутреннее содержимое пакетов. В данном случае сканируются пакеты SIP. Для сервера 3CX такое сканирование содержимого SIP пакетов может создавать проблемы. Поскольку изменения в SIP-сообщения вносятся промежуточным сетевым узлом, сервер 3CX “не видит” этих вмешательств. Однако они могут создать проблемы в работу удаленных IP-телефонов и VoIP-провайдеров.

Проверка: 3CX генерирует сообщение INVITE и отправляет его на онлайн-сервис, размещенный в инфраструктуре 3CX. За исключением публичного IP-адреса, остальная информация является стандартной.

Одновременно сервер 3CX генерирует хэш-значение CRC32 из отправленного сообщения и ожидает, что ответ от облачного сервиса будет иметь такой же хэш.

Если возвращаемое значение "X-CSREQ" совпадает с локально вычисленным значением, предполагается, что SIP ALG отсутствует или не вмешивался в сообщение. Если значения не совпадают - при прохождении между 3CX и онлайн-сервисом содержимое пакета было изменено вмешательством SIP ALG.

Кстати, можно вычислить ожидаемое хэш-значение, если с помощью Wireshark перехватить пакет INVITE от 3CX.

• Нажмите правой кнопкой мыши на сообщении INVITE, отправленном из 3CX > Copy > Bytes > Hex Stream.
• Откройте http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
• Вставьте скопированный шестнадцатеричный блок в CRC Input Data

Результат (Result) должен совпадать с возвращаемым значением CRC32.

Версия документа

Последнее обновление документа 25 января 2019

https://www.3cx.ru/docs/firewall-checker/