Назад |
Перейти на главную страницу
Звонки Skype для бизнеса за pfSense прекращаются через пять секунд
У меня проблема с отключением Skype для бизнеса (Lync) за брандмауэром pfSense ровно через 5 секунд. Это странная проблема, и я открыл заявку в Microsoft, но до сих пор это оказалось бесплодным. Вот информация:
Постановка задачи:
- Если вызов Lync исходит из нашего офиса удаленному пользователю VPN, вызов соединяется с двусторонним звуком, но отключается ровно через 5 секунд с "сетевой ошибкой". Если удаленный пользователь звонит офисному пользователю, проблем нет.
- Если офисный пользователь пытается представить свой рабочий стол или предоставить к нему общий доступ, презентация запускается, а затем останавливается ровно через 5 секунд с появлением «сетевой ошибки». Опять же, удаленные пользователи могут без проблем делиться информацией с офисными пользователями.
Соответствующая информация:
- Это облачное развертывание Office365. Локального сервера нет.
- Раньше у нас был межсетевой экран Fortigate. Lync работал нормально.
- Наши удаленные пользователи подключаются с помощью OpenVPN, запущенного на ящике pfSense за шлюзом.
- Раздельное туннелирование включено, поэтому весь интернет-трафик от удаленного пользователя должен идти прямо в Интернет.
- SIP ALG не включен и никогда не был включен ни на одном брандмауэре.
- Наш интернет-провайдер изменил наше публичное пространство IP-адресов. Примерно в то же время мы заменили Fortigate на UniFi USG Pro, и он проработал несколько месяцев.
- Без (очевидных) изменений конфигурации у наших удаленных пользователей (подключенных через VPN) возникают проблемы.
- По причинам, не связанным с этой проблемой, мы решили, что UniFi недостаточно гибок для наших нужд. Мы установили сервер pfSense в качестве основного шлюза.
- Теперь пользователи VPN подключаются непосредственно к шлюзу, а не к серверу внутри сети.
- В этой конфигурации все работает нормально несколько недель. Мы думаем, что проблема должна быть связана с UniFi.
- Затем, без каких-либо изменений конфигурации, проблема снова появляется и существует сейчас.
Вещи, которые я пробовал:
- Изменение диапазона внутренних IP-адресов для пользователей VPN - без последствий.
- Настройте VPN-сервер на другом WAN-интерфейсе (и другом ISP) и попросите пользователя подключиться к нему - никакого влияния.
- Протестировано STUN / TURN с внутренней рабочей станции на 52.112.0.75. (Сервер Lync TURN) - успешно
- Протестировано STUN / TURN с рабочей станции, подключенной к VPN, на 52.112.0.75. (Сервер Lync TURN) - успешно
- Настройте брандмауэр, чтобы разрешить весь исходящий трафик из сети Office - без последствий.
- Настройте брандмауэр, чтобы разрешить весь трафик из интерфейса VPN - без влияния.
- Настройте брандмауэр на блокировку и регистрацию трафика STUN между корпоративной сетью и сетью VPN - никакого влияния.
Эта проблема возникает в 100% случаев и легко воспроизводима. Я собрал сетевые записи с обеих сторон вызова и отправил журналы диагностики в Microsoft. Они предоставили мне огромный список IP-адресов для внесения в белый список на моем брандмауэре, но на данный момент я не блокирую исходящий трафик. Они также показали сообщение журнала о сбое запроса STUN на 52.112.0.75 с сообщением «401 (Unauthorized)», однако за этой ошибкой следует успешная привязка STUN к тому же адресу, так что я думаю, что это отвлекающий маневр. Я также использовал сценарий PowerShell для тестирования STUN с компьютера с обеих сторон, и оба запроса были успешными. Кроме того, эта ошибка возникает через 3,5 секунды после вызова, а успешный запрос приходит через несколько миллисекунд. Я думаю, это ожидаемый провал.
Примерно в момент сбоя вызова я действительно вижу несколько пакетов TCP с установленным флагом RST, исходящих из того же IP-блока, что и другой трафик, связанный с Lync. (52.112.0.0/16) Также примерно в это время я вижу трафик, идущий напрямую с IP-адреса удаленного пользователя. В частности, трафик UDP с портом назначения 3478, который является STUN.
Теории:
Каждый клиент подключается напрямую к серверу Lync в облаке. Через несколько секунд этот сервер пытается согласовать прямое SIP-соединение между двумя клиентами (следовательно, трафик STUN) и терпит неудачу. Microsoft особо не рекомендует прямое соединение через VPN, поэтому я даже не знаю, почему он пытается это сделать, и я бы предотвратил это, если бы знал, как это сделать.
Эта проблема убивала меня в течение нескольких недель, и я буду благодарен за любой вклад.