Elastix 5.0 не проходит тест сетевого экрана

This topic contains 22 replies, has 4 voices, and was last updated by  1sy1 6 days, 10 hours ago.

Viewing 15 posts - 1 through 15 (of 23 total)
  • Author
    Posts
  • #41944
    leikocid
    Participant

    поставил Elastix 5.0 на виртуальную машину в proxmox 4.2 , ставил образом, все встало и настроилось,пробросил порты на шлюзе, по FQDN и по внешнему ip web интерфейс доступен, но……не проходит тест “Проверка сетевого экрана” по всем пунктам ктоме первых трех, порты проброшены и в том что сетевой экран на шлюзе порты открыл уверен,так как проброс портов работает с множеством сервисов на других ip, утилитой 3CXFirewallCheckerClientApplication тоже не может подключится к транку , соответственно из за этого не получается подключить VoIP FXO шлюз который на другом провайдере, в чем может быть дело кто знает?

    #41945

    Нарисуйте схему сети, со шлюзами и IP адресами.

    #41947
    leikocid
    Participant

    VoIP шлюз -> роутер -> провайдер(95.xx.xx.xx) = интернет = провайдер(92.xx.xx.xx) -> роутер -> Elastix 5.0(192.168.0.xx)

    #41948

    Вы опубликовали порты 5060 TCP и UDP, 5001 TCP, 5090 TCP, 9000-9500 UDP?

    #41949
    leikocid
    Participant

    да, на 5001 TCP попадаю на веб интерфейс нормально, остальные тест показывает что закрыты, хотя обуюлекованы

    #41950
    leikocid
    Participant

    из локальной сети где находится Elastix 5 тоже не получается подключится при помощи 3CXFirewallCheckerClientApplication

    #41951

    Подключайтесь обычными клиентами 3cx через автонастройку. Firewall checker сделана для диагностики проблем, только если они есть. У вас есть проблемы в работе системы? Оставьте firewall checker и просто настраивайте систему.

    #41952
    3cxoleg
    Participant

    leikocid добрый день,

    firewall checker проверяет только UDP порты,
    подробнее по портам : http://www.3cx.com/docs/3cx-phone-system-v14-ports/
    подробнее по проверке сетевого экрана: http://www.3cx.com/blog/docs/firewall-voip-rules-check/

    #41953
    leikocid
    Participant

    Игорь Снежко, FXO шлюз не видит sip север, в этом основная проблема(
    3cxoleg, спасибо изучаю вопрос, вроде из локалки мимо всех фаерволов должны быть доступны транки для подключения из 3CXFirewallCheckerClientApplication чего не происходит

    #41954
    3cxoleg
    Participant

    захватите пакеты через wireshark и по примеру (подробнее по проверке сетевого экрана: http://www.3cx.com/blog/docs/firewall-voip-rules-check/ ) будет видно что не так.

    #41955
    leikocid
    Participant

    а у Elastix 5.0 есть свой сетевой экран?, получается что на
    resolving ‘stun.3cx.com’… done
    resolving ‘stun2.3cx.com’… done
    resolving ‘stun3.3cx.com’… done
    тесты проходят а на свои внутренние порты нет

    #41956
    3cxoleg
    Participant

    для проверки корректной настройки портов, АТС делает тест на STUN сервер 3CX.
    По умолчанию порты сетевого экрана (iptables) на Elastix 5.0 (если вы скачали iso) открыты.

    #41958

    Я вам советую на удаленной точке, где вы подключаете VoIP шлюз, сделать проброс портов 5060 UDP и RTP портов (посмотрите в параметрах этого шлюза). В самом шлюзе в качестве STUN сервера указывайте FQDN вашего сервера 3CX и порт 5060. 3CX сама предоставляет STUN сервис для внешних подключений.

    #41964
    leikocid
    Participant

    Игорь, спасибо попробую отпишусь

    #41965
    1sy1
    Participant

    >а у Elastix 5.0 есть свой сетевой экран?, получается что на
    >resolving ‘stun.3cx.com’… done
    >resolving ‘stun2.3cx.com’… done
    >resolving ‘stun3.3cx.com’… done
    >тесты проходят а на свои внутренние порты нет

    Firewall checker работает не совсем так. Проверяются не “внутренние порты”, а то, как они транслируются NAT устройством при отправке UDP сообщений на внешние адреса.
    три первые строчки – это получение адреса внешних STUN серверов, с помощью которых и будет проводиться тестирование.
    Судя по тому, что у Вас TCP работает (web консоль открывается снаружи), а ни один UDP порт не проходит проверки на “статическую привязку” портов (кстати, какое сообщение выдается в логе checker’а?), то
    1. либо вообще весь UDP трафик заблокирован и ничего не проходит через шлюз наружу.
    2. либо NAT не сконфигурирован для UDP (порт транслируется но в какой-то случайный, что совсем не подходит для сервера, к которому нужно обращаться клиентам, в том числе и упомянутому FXO шлюзу)
    3. либо (есть вероятность и такой проблемы) шлюз вообще не реализует “Full cone NAT” (статическая привязка внешнего порта к порту локального хоста) для UDP.
    Будем надеяться, что проблема 1. или 2., поскольку 3. никак не лечится и общение с внешним шлюзом будет проблематичным вплоть до принципиальной невозможности.

Viewing 15 posts - 1 through 15 (of 23 total)

You must be logged in to reply to this topic.