Skype для бизнеса звонки после pfSense сбрасывается через пять секунд

У меня проблема с отключением Skype для бизнеса (Lync) за брандмауэром pfSense спустя ровно 5 секунд. Это странная проблема, и я открыл билет в Microsoft, но до сих пор это оказалось бесплодным. Вот информация:

Постановка задачи:

  • Если вызов Lync поступает из нашего офиса удаленному пользователю VPN, он соединяется с двусторонним звуком, но через 5 секунд отключается с "сетевой ошибкой". Если удаленный пользователь звонит офисному пользователю, проблем нет.
  • Если пользователь офиса пытается представить / поделиться своим рабочим столом, презентация начинается, а затем останавливается ровно через 5 секунд с "сетевой ошибкой". Опять же, удаленные пользователи могут делиться с офисными пользователями без проблем.

Информация о Релавенте:

  • Это облачное развертывание Office365. Нет локального сервера.
  • Ранее у нас был межсетевой экран Fortigate. Линк работал нормально.
  • Наши удаленные пользователи подключаются с помощью OpenVPN, работающего на коробке pfSense за шлюзом.
  • Раздельное туннелирование включено, поэтому весь интернет-трафик от удаленного пользователя должен идти напрямую в Интернет.
  • Ни один SIP ALG не включен или никогда не был включен ни на одном брандмауэре.
  • Наш провайдер изменил наше публичное пространство IP-адресов. Примерно в то же время мы заменили Fortigate на UniFi USG Pro, и он работал в течение нескольких месяцев.
  • Без (очевидных) изменений в конфигурации наши удаленные пользователи (подключенные через VPN) начинают испытывать проблемы.
  • По причинам, не связанным с этой проблемой, мы решили, что UniFi недостаточно гибок для наших нужд. Мы установили сервер pfSense в качестве основного шлюза.
  • Теперь пользователи VPN подключаются напрямую к шлюзу, а не к серверу внутри сети.
  • При такой конфигурации все отлично работает в течение нескольких недель. Мы думаем, что проблема была связана с UniFi.
  • Затем, без каких-либо изменений конфигурации, проблема вновь появляется и существует в настоящее время.

Вещи, которые я пробовал:

  • Изменение диапазона внутренних IP-адресов для пользователей VPN - не влияет.
  • Настройте VPN-сервер на другом интерфейсе WAN (и другом интернет-провайдере), и пользователь должен подключиться к нему - без последствий.
  • Протестировано STUN/TURN с внутренней рабочей станции на 52.112.0.75. (Lync TURN server) - успешно
  • Протестировано STUN/TURN с рабочей станции, подключенной к VPN, до 52.112.0.75. (Lync TURN server) - успешно
  • Установите брандмауэр, чтобы разрешить весь исходящий трафик из сети Office - без последствий.
  • Установите брандмауэр, чтобы разрешить весь трафик от интерфейса VPN - не влияет.
  • Настройте брандмауэр на блокировку и запись трафика STUN между корпоративной сетью и сетью VPN - не влияет.

Эта проблема возникает в 100% случаев и легко воспроизводима. Я собрал сетевые снимки с обеих сторон вызова и отправил диагностические журналы в Microsoft. Они дали мне огромный список IP-адресов в белый список на моем брандмауэре, но в данный момент я не блокирую исходящий трафик. Они также показали сообщение журнала запроса STUN на 52.112.0.75 с ошибкой с сообщением "401 (неавторизовано)", однако за этой ошибкой следует успешное связывание STUN с тем же адресом, поэтому я думаю, что это красная сельдь. Я также использовал сценарий PowerShell для тестирования STUN с компьютера с обеих сторон, и оба запроса были успешными. Кроме того, эта ошибка возникает через 3,5 секунды после вызова, и успешный запрос приходит спустя несколько миллисекунд. Я думаю, что это ожидаемый провал.

Примерно во время сбоя вызова я вижу несколько пакетов TCP с установленным флагом RST, поступающих из того же IP-блока, что и другой трафик, связанный с Lync. (52.112.0.0/16) Также примерно в это время я вижу трафик, поступающий непосредственно с IP-адреса удаленного пользователя. В частности, трафик UDP с портом назначения 3478, который является STUN.

Теории:

Каждый клиент подключается непосредственно к серверу Lync в облаке. Через несколько секунд этот сервер пытается установить прямое SIP-соединение между двумя клиентами (следовательно, STUN-трафик) и завершается неудачно. Microsoft не рекомендует прямое подключение через VPN, поэтому я даже не знаю, почему она пытается это сделать, и я бы помешала, если бы знала, как это сделать.

Эта проблема убивала меня в течение нескольких недель, и любая помощь будет принята с благодарностью.

Источник

0 ответов

Другие вопросы по тегам