none
Не работает мобильный клиент RRS feed

  • Вопрос

  • Здравствуйте! направьте пожалуйста в нужное русло для решения проблемы.

    Развернут SfB 2015, в конфигурации: 1 skype сервер, 1 EDGE и 1 RP. В качестве реверс прокси используется Kemp LoadMaster в free версии. Отовсюду Skype доступен (как внутри домена, так и снаружи.) Проблема в подключении мобильным клиентом.

    Тestconnectivity выдает ошибку:

    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server lyncdiscover.domen.ru on port 443.
     	The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.
     	
    	Additional Details
     	
    The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
    Elapsed Time: 322 ms.

    Когда проверяю SSL для lyncdiscover.domen.ru на сторонних сайтах - проверка проходит, показывает сертификат и все данные. С такой же ошибкой ругается и на sip.domen.ru. Хотя и он на сторонних сайтах проходит проверку сертификата.

    При подключении с мобильного клиента есть ошибка: Не удается выполнить вход. Проверьте адрес для входа и повторите попытку.

    Я так понимаю, что это из за проблем с сертификатом. Хотя когда с мобильного пытаюсь подключиться, он запрашивает доверие к моему сертификату.

    23 октября 2017 г. 11:35

Ответы

  • Попробуйте выполнить проверку с помощью testconnectivity:

    https://testconnectivity.microsoft.com/

    Так же там можно скачать "Microsoft Connectivity Analyzer Tool" - он поможет протестировать подключениен мобильных клиентов.

    Ну и если хотите сделать Reverse Proxy на бесплатном ПО, посмотрите этот вариант:

    http://www.lin.by/2015/11/reverse-proxy-lync-2013-sfb-nginx-1.html#more

    Так же по логам вижу, что lyncdiscover у вас работает на 443 порту. Смысла в этом ноль, а вот проблем может добавить. Лучше делать его на HTTP (порт 80). Дело в том, что он никакой секретной информации не отдает. Вот вам пример:

    http://lyncdiscover.activecloud.com/

    25 октября 2017 г. 7:24
  • 1. Необходимо поправить в топологии и переопубликовать ее.

    2. В /var/log есть логи nginx. Часто их достаточно чтобы понять, что пошло не так. Ну и выше я давал ссылку на средства диагностики.

    25 октября 2017 г. 8:05
  • Опытным путем установил.

    У вас адрес web.<вашДомен.ru> резолвится по адресу 77.105.144.3

    А lyncdiscover.<вашДомен.ru> по адресу 77.105.144.4

    Мне это показалось немного странным - обычно все публикуют с одного ReverseProxy. Забил себе в hosts для web.<вашДомен.ru> адрес 77.105.144.4 - и всё зашуршало)) Разбирайтесь с этим.

    • Предложено в качестве ответа Tema_BYMVP 2 ноября 2017 г. 9:22
    • Помечено в качестве ответа Dshumov 2 ноября 2017 г. 13:01
    2 ноября 2017 г. 8:55
  • Как вам сказал Александр, вы, вероятно, намудрили с DNS. Раз мы публикуем web сервис на reverse proxy то логично, что туда и должно приходить соединение. В вашем случае конфигурация может быть корректной, если адрес 77.105.144.3 принадлежит реверспрокси. Но похоже, что это не так, ведь на нем же работает поддомен sip.
    • Помечено в качестве ответа Dshumov 2 ноября 2017 г. 13:01
    2 ноября 2017 г. 9:00
  • Нет, не правильно. Вот тут описание портов и зачем нужны:

    https://technet.microsoft.com/ru-ru/library/gg425891(v=ocs.15).aspx

    А голосовой трафик с мобильных клиентов идет через реверс прокси. Надо смотреть на нем логи (Kemp, в вашем случае), что происходит. Ну или собирать логи на мобильном клиенте, но не факт, что там будет необходимая информация.

    • Помечено в качестве ответа Dshumov 2 ноября 2017 г. 13:01
    2 ноября 2017 г. 12:18
  • Нет, не правильно. Вот тут описание портов и зачем нужны:

    https://technet.microsoft.com/ru-ru/library/gg425891(v=ocs.15).aspx

    А голосовой трафик с мобильных клиентов идет через реверс прокси. Надо смотреть на нем логи (Kemp, в вашем случае), что происходит. Ну или собирать логи на мобильном клиенте, но не факт, что там будет необходимая информация.

    медиа-трафик с мобильных идет через эдж, а не реверс-прокси, смотрите, как у вас опубликован AV-интерфейс наружу.
    • Изменено Artem S. Smirnov 2 ноября 2017 г. 12:24
    • Помечено в качестве ответа Dshumov 2 ноября 2017 г. 13:01
    2 ноября 2017 г. 12:20

Все ответы

  • P.S. Установил, в качестве реверс прокси WAP - та же картина :(
    23 октября 2017 г. 12:33
  • Попробуйте выполнить проверку с помощью testconnectivity:

    https://testconnectivity.microsoft.com/

    Так же там можно скачать "Microsoft Connectivity Analyzer Tool" - он поможет протестировать подключениен мобильных клиентов.

    Ну и если хотите сделать Reverse Proxy на бесплатном ПО, посмотрите этот вариант:

    http://www.lin.by/2015/11/reverse-proxy-lync-2013-sfb-nginx-1.html#more

    Так же по логам вижу, что lyncdiscover у вас работает на 443 порту. Смысла в этом ноль, а вот проблем может добавить. Лучше делать его на HTTP (порт 80). Дело в том, что он никакой секретной информации не отдает. Вот вам пример:

    http://lyncdiscover.activecloud.com/

    25 октября 2017 г. 7:24
  • Артем, спасибо за ответ. Есть два вопроса:

    1) Где переделать lyncdiscover на порт 80? На фронтэнде?

    2) Только что сделал по вашей инструкции на Nginx, но что-то не взлетело :( хотя скорее всего я мог где-то что-то напутать я в nix полный 0.

    25 октября 2017 г. 7:58
  • 1. Необходимо поправить в топологии и переопубликовать ее.

    2. В /var/log есть логи nginx. Часто их достаточно чтобы понять, что пошло не так. Ну и выше я давал ссылку на средства диагностики.

    25 октября 2017 г. 8:05
  • Использовать HTTPS для автообнаружения - в этом нет ничего криминального)) Тем более от шифрованного трафика всё равно никуда не деться при использовании S4B - так что лучше решать проблему, а не обходить её)

    Вы проделали тесты с помощью утилит, о которых вам выше писали? Я бы ещё посоветовал протестировать с помощью "Microsoft Lync Connectivity Analyzer Tool" - т.к. тут более богатые логи выдаются. Но вот только Microsoft убрали эту тулзу из загрузок - но если поискать, то на просторах интернета - всё легко находится))
    И уточните - не работает только S4B, установленный на мобильных устройствах? Пробовали с нескольких устройств подключаться? (или может проблема только в одном - с каким-нибудь древним андроидом). И на всех ли мобильниках выдаётся запрос доверия к сертификату? Обычные Windows-клиенты подключаются извне нормально?

    Сертификат куплен, или использовали какой-то бесплатный? Вообще - есть ли возможность показать сертификат, или поделиться именем sip-домена и сами всё увидим))

    PS: по-моему проблема автора ни разу не решена. К чему пометки о решении.

    30 октября 2017 г. 4:49
  • Да, я проделал все тесты. 
    Testconnectivity выдает ответ:
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server sip.домен.ru on port 443
    Хотя если смотреть через сторонний SSL Checker сертификат нормально видиться и распознается.
    Microsoft Lync Connectivity Analyzer Tool:
    lyncdiscover.домен.ru can't be resolved by the DNS server. Skipping external discovery.
    Хотя через сторонний Online DNS lookup имя распонаеться.
    Да, на всех мобильниках выдаётся запрос доверия к сертификату. Обычные Windows-клиенты подключаются извне нормально.

    Сертификат куплен. Адрес sip.vth-invest.ru

    P.S. При обращении к https://lyncdiscover.домен.ru/ XML файл показывается. Т.е. Autodiscover тест проходит. И Testconnectivity в части (Skype for Business Autodiscover Web Service) тесты проходит.

     
    • Изменено Dshumov 2 ноября 2017 г. 8:06
    2 ноября 2017 г. 7:47
  • У вас что-то не то с публикацией веб сервисов. Откройте в браузере:

    https://lyncdiscover.ВАШДОМЕН.ru

    Там есть ссылки. Попробуйте по ним перейти - будет ошибка 404. Выше я давал для примера свой домен. Можете попробовать сравнить результат. 

    2 ноября 2017 г. 8:08
  • Публикацию веб сервисов исправил. Но ситуация не изменилась.
    2 ноября 2017 г. 8:26
  • Нет, публикация работает так-же, как раньше (некорректно). Пример для xframe:

    Not found
    Document "/Autodiscover/XFrame/XFrame.html" is not accessible.
    mini-http/1.0 (unix)
    2 ноября 2017 г. 8:30
  • ReverseProxy внешний запрос web.<sipdomain.ru> пробрасывает на внутренний ресурс с таким же именем - так? Внутри создана DNS-запись web.<sipdomain.ru>, которая указывает на ваш FE-сервер? На FE-сервере в сертификате это имя в поле SAN присутствует?
    2 ноября 2017 г. 8:35
  • И это исправил :)
    2 ноября 2017 г. 8:37
  • Без понятия, что вы исправили. 

    https://web.ВАШДОМЕН.ru/Autodiscover/XFrame/XFrame.html выдает ту же ошибку, что и в предыдущем моем сообщении.

    2 ноября 2017 г. 8:40
  • Да на FE-сервере в сертификате в полу SAN имя присутствует.
    2 ноября 2017 г. 8:40
  • И это исправил :)

    Вы откройте извне, как вам пишут выше, страничку https://web.ВашДомен.ru/Autodiscover/AutodiscoverService.svc/root?originalDomain=ВашДомен.ru

    И убедитесь, что ничего не исправлено) Ошибка 404.

    2 ноября 2017 г. 8:42
  • С сертификатом у вас все хорошо. А вот с настройкой Reverse Proxy все плохо :) У вас есть пример для сравнения, используйте его.
    2 ноября 2017 г. 8:43
  • По ссылке https://web.ВашДомен.ru/Autodiscover/AutodiscoverService.svc/root?originalDomain=ВашДомен.ru

    открывается XML документ

    2 ноября 2017 г. 8:46
  • Из вне показывает надпись: Hide Me!

    Так же как и у вас.

    2 ноября 2017 г. 8:47
  • По ссылке https://web.ВашДомен.ru/Autodiscover/AutodiscoverService.svc/root?originalDomain=ВашДомен.ru

    открывается XML документ

    Вы это делаете извне организации?? С мобильника или домашнего компьютера..
    2 ноября 2017 г. 8:48
  • Reverse Proxy (КKemp LoadMaster) настраивал строго по инструкции, там ошибиться очень сложно. Инструкция от Ильи Рудь, и там шаблон используется.
    2 ноября 2017 г. 8:50
  • Естественно извне. Поднят по тимвьюверу подключаюсь к домашнему компу и с него пробую

    И с мобильного так же.

    • Изменено Dshumov 2 ноября 2017 г. 8:56
    2 ноября 2017 г. 8:51
  • Попробуйте найти еще какой-либо внешний ПК для тестов. Пока что видно, что не все работает корректно.

    2 ноября 2017 г. 8:54
  • Опытным путем установил.

    У вас адрес web.<вашДомен.ru> резолвится по адресу 77.105.144.3

    А lyncdiscover.<вашДомен.ru> по адресу 77.105.144.4

    Мне это показалось немного странным - обычно все публикуют с одного ReverseProxy. Забил себе в hosts для web.<вашДомен.ru> адрес 77.105.144.4 - и всё зашуршало)) Разбирайтесь с этим.

    • Предложено в качестве ответа Tema_BYMVP 2 ноября 2017 г. 9:22
    • Помечено в качестве ответа Dshumov 2 ноября 2017 г. 13:01
    2 ноября 2017 г. 8:55
  • С мобильного телефона показывает надпись: Hide Me!

    Что я не так делаю? :(

    Предвосхищаю вопрос, корпоративный WIFI на телефоне выключен.


    • Изменено Dshumov 2 ноября 2017 г. 8:57
    2 ноября 2017 г. 8:56
  • Как вам сказал Александр, вы, вероятно, намудрили с DNS. Раз мы публикуем web сервис на reverse proxy то логично, что туда и должно приходить соединение. В вашем случае конфигурация может быть корректной, если адрес 77.105.144.3 принадлежит реверспрокси. Но похоже, что это не так, ведь на нем же работает поддомен sip.
    • Помечено в качестве ответа Dshumov 2 ноября 2017 г. 13:01
    2 ноября 2017 г. 9:00
  • Нет, все 77.105.144.4 резолвится в ДНС все через него публикуется. Спецом полез на внешний ДНС и проверил. И из вне через nslookup online проверил - все через 77.105.144.4
    2 ноября 2017 г. 9:04
  • Нет, reverse proxy смотрит на адрес 77.105.144.4.
    2 ноября 2017 г. 9:05
  • Такое ощущение, что вы недавно меняли DNS записи - и репликация по миру ещё не успела пролететь)) Не было такого?

    Проверил - гугл показывает 77.105.144.4, а DNS провайдера выдаёт 77.105.144.3


    2 ноября 2017 г. 9:09
  • Да, теперь у меня тоже все заработало.

    Следующий шаг - проведите диагностику подключения мобильных устройств и покажите полный лог.

    2 ноября 2017 г. 9:12
  • Да, точно недавно, часа 2 назад.
    2 ноября 2017 г. 9:14
  • И вроде ка с мобильников тоже заработало.
    2 ноября 2017 г. 9:15
  • Я прошу прощения, но возникла другая проблема :) Внутри голос есть, а при звонке с мобильного телефона, голоса нет. Я правильно понимаю, что за это отвечает порт 5061, но ни как не могу понять/разобраться, где его открывать, на Edge или на FE.
    2 ноября 2017 г. 12:06
  • Нет, не правильно. Вот тут описание портов и зачем нужны:

    https://technet.microsoft.com/ru-ru/library/gg425891(v=ocs.15).aspx

    А голосовой трафик с мобильных клиентов идет через реверс прокси. Надо смотреть на нем логи (Kemp, в вашем случае), что происходит. Ну или собирать логи на мобильном клиенте, но не факт, что там будет необходимая информация.

    • Помечено в качестве ответа Dshumov 2 ноября 2017 г. 13:01
    2 ноября 2017 г. 12:18
  • Нет, не правильно. Вот тут описание портов и зачем нужны:

    https://technet.microsoft.com/ru-ru/library/gg425891(v=ocs.15).aspx

    А голосовой трафик с мобильных клиентов идет через реверс прокси. Надо смотреть на нем логи (Kemp, в вашем случае), что происходит. Ну или собирать логи на мобильном клиенте, но не факт, что там будет необходимая информация.

    медиа-трафик с мобильных идет через эдж, а не реверс-прокси, смотрите, как у вас опубликован AV-интерфейс наружу.
    • Изменено Artem S. Smirnov 2 ноября 2017 г. 12:24
    • Помечено в качестве ответа Dshumov 2 ноября 2017 г. 13:01
    2 ноября 2017 г. 12:20
  • Через реверс прокси заворачивается только HTTP/HTTPS трафик (веб службы, шаринг и тд). Голос, видео, состояние присутствия - всё это через EDGE (все эти вещи используют SIP-протокол).

    Судя по всему - у вас опять какая-то путаница с внешними именами. Осмелюсь предположить - что на EDGE-сервере у вас только один белый IP-адрес, а скорее всего даже не белый - а проброс через NAT. Если проброс через NAT - то в топологии это надо явно указывать.

    Что у вас с DNS-записями:

    A-запись sip.<вашДомен.ru> = 77.105.144.3

    A-запись av.<вашДомен.ru> = 77.105.144.3

    A-запись webconf.<вашДомен.ru> = 77.105.144.4 - НЕ ВЕРНО. Это IP-адрес вашего обратного прокси, а тут должен быть EDGE.

    В SRV-записях у вас скорее всего тоже путаница с портами. Чтоб внести ясность сделайте следующее:

    1. Покажите скриншот конфига EDGE-сервера в своей топологии.

    2. Расскажите как у вас опубликован наружу EDGE-сервер. Имеет ли он белые IP-адреса на внешнем интерфейсе, либо опубликован через NAT? И сколько белых IP-адресов выделено под EDGE.


    2 ноября 2017 г. 13:04
  • Александр, Артём!

    Огромное спасибо за помощь и терпение. Вроде бы со всем разобрался. A-запись webconf.<вашДомен.ru>поправил. С голосом так же разобрался, на эдже не был разрешен порт для голоса - остатки от первой попытки развертывания, не на тот адрес  было правило.

    2 ноября 2017 г. 13:08