Что может привести к тому, что трафик SIP будет входить в коммутатор, но не будет выходить?

Фон

Я изо всех сил пытался заставить свои SIP-телефоны зарегистрироваться за совершенно новым маршрутизатором и переключиться в наш новый офис. Наша АТС размещена вне офиса. Я работал с нашим провайдером, чтобы попробовать несколько разных подходов. Мы попытались подключить обычный NAT к их пограничному контроллеру сеанса с поддержкой NAT. Мы попытались использовать siproxd (пакет pfSense) для перехвата запросов регистрации SIP и регистрации от имени телефона. Наконец, мы попытались настроить телефоны вручную для регистрации с помощью демона siproxd в моей локальной сети.

В ходе тестирования мы видели, что телефоны успешно выполняют все следующие действия:

Связаться с размещенным FTP-сервером по IP-адресу
Загрузите конфигурацию с указанного сервера
Выполните DNS-запросы для разрешения IP-адреса NTP-сервера.
Запросите NTP-сервер, чтобы установить время
Выполните DNS-запросы для разрешения IP-адреса SIP-серверов.

симптомы

После того, как телефоны успешно выполнили все задачи предварительной регистрации, мы никогда не увидим, как попытка регистрации попала в поле pfSense или в АТС провайдера. Я включил наивысший уровень отладки в siproxd на моем конце и не видел ни TCP-соединения, ни UDP-пакета. Однако простой telnet к порту 5060 с рабочей станции будет генерировать ожидаемые сообщения журнала. Выполнение захвата пакета на коробке pfSense не показало абсолютно никаких попыток трафика SIP.

Какого черта?

Мой последний шаг по устранению неполадок, который полностью озадачил меня и заставил меня задать этот вопрос, заключался в следующем. Сначала я отразил порт коммутатора, к которому подключен телефон, к порту коммутатора моей рабочей станции. Я выполнил захват всего трафика на интерфейсе. К своему удивлению я увидел пакеты регистрации SIP, приходящие с телефона. Вот пример:

Захват телефонного пакета

Очевидно, что телефон пытается зарегистрироваться в УАТС (это также правильные IP-адреса).

Следующим моим шагом было отражение порта коммутатора, который подключается к локальной сети маршрутизатора pfSense. Я видел весь трафик FTP, NTP и DNS с телефона 172.200.22.102, выходящий из коммутатора, но не обнаружил следов пакетов SIP. Это совершенно сбивает с толку меня! Что вызывает исчезновение только трафика SIP внутри коммутатора?

Окружающая обстановка

аппаратные средства
- Маршрутизатор / межсетевой экран: Netgate m1n1wall 2D2
- Переключатель: HP 1810G-24
- Телефоны: Polycom SoundPoint IP 501
Программное обеспечение: pfSense 2.0-RC3

Конфигурация коммутатора

Телефон с IP-адресом 172.22.200.102 находится в порту 4 этого коммутатора, а соединение с маршрутизатором LAN - в порту 22.

Конфигурация VLAN

Участие VLAN 200

Я могу поделиться еще настройками, которые могут понадобиться.

pfsense sip switch

— hobodave
источник

Я знаю, что здравый смысл заключается в том, что пакеты должны направляться к интерфейсу локальной сети маршрутизатора, но давайте не будем принимать что-либо как должное. Не могли бы вы получить Wireshark, чтобы показать вам MAC-адреса назначения на этих пакетах, выходящих из телефона, и подтвердить, что они на самом деле являются MAC-адресами маршрутизатора? Если бы по какой-то причине их не было, это объяснило бы, почему вы не видите их на зеркальном порту.

— MadHatter

@Mad: подтвердил правильный MAC-адрес назначения маршрутизатора

— hobodave

Черт. Ну, это стоило проверить. Извините, что не имею лучших идей.

— MadHatter

Я нашел решение, потратив примерно 40 часов на эту проблему.

В переключателе есть настройка, которая включает защиту «Auto DoS». Очевидно, он рассматривает трафик TCP или UDP, который имеет соответствующие порты источника или назначения, как явную атаку и отбрасывает пакет. Это смехотворно недальновидно, так как трафик SIP часто (всегда?) Зависит от порта источника и получателя, равного 5060.

В случае, если текстовое описание было недостаточно:

введите описание изображения здесь

— hobodave
источник

вау, это жестоко Хорошая работа в поиске этого. Могу поспорить, это не отображается в журналах, верно?

— gravyface

@gravyface: правильно, ничего не вошло. Все журналы показывают основные ссылки вверх / вниз и попытки аутентификации

— hobodave

Whaaaaaaaaaaaaaaaat? Отличная работа HP!

— voretaq7

Это отстой; это будет винт (например) NTP и сервер-сервер DNS, а также. По словам voretaq, "отличная работа. HP". Хорошо диагностированный, однако, hobodave; ты заслуживаешь пива!

— MadHatter

+1 - Я столкнулся с этим сегодня с одним и тем же переключателем в другом приложении. Протокол SonicWALL «Single Sign-On» использует UDP-дейтаграммы с одинаковыми портами источника и назначения. Я хотел бы посмотреть здесь, прежде чем выследить его с помощью крана Ethernet. Интересно отметить, что «нарушающие» фреймы даже удаляются при зеркалировании порта входного порта. Полный провал, HP. Я могу подтвердить, что прошивка PK 1.15, выпущенная в январе, все еще имеет эту ошибку.

— Эван Андерсон