none
Внешние клиенты, через Edge не могут выполнить Доступ-Рабочий стол RRS feed

  • Вопрос

  • Есть Lync и Edge на разных серверах, за TMG. В локальной сети весь функционал работает отлично. проблема заключается во внешних клиентах, которые не могут выполнить Доступ - Рабочий стол и получают ошибку "Подключение для совместного доступа не удалось установить из-за сетевых проблем. Повторите попытку позже". Доска, опросник, презентации и все остальное (аудио-видео) в варианте внешний-внутренний Lync-клиент работает на ура.

    Подскажите, где можно покопаться, чтобы все работало как надо.

    21 марта 2012 г. 10:37

Ответы

  • Пожалуйста :) .

    А спасибо здесь принято выражать нажатием кнопки "Пометить как ответ" ;) .

    • Помечено в качестве ответа vol4ena 30 марта 2012 г. 8:51
    30 марта 2012 г. 8:15
    Модератор

Все ответы

  • А проблема возникает только в конференциях или при сценарии "один-на-один" тоже?

    Для устранения подозрений на антивирус - разверните голую виртуалку и проверьте работоспособность Sharing'а с неё...

    21 марта 2012 г. 10:43
    Модератор
  • при сценарии "один-на-один" та же проблема. 


    21 марта 2012 г. 11:02
  • В таком случае, проблема либо в антивирусе, либо в отсутствии правил для TCP-портов - Sharing, в отличии от голоса/видео, всегда идёт по TCP.
    21 марта 2012 г. 11:10
    Модератор
  • при подключении внешнего клиента к Доступ-Рабочий стол, лог TMG выкидывает вот какое:

    Закрытое соединение

    TMG 21.03.2012 15:24:09

    Тип журнала:Служба межсетевого экрана
    Состояние: Подключение было закрыто по прерыванию после того, как один из одноранговых узлов отправил пакет RST.
    Правило: Audio Video Edge RTP (TCP 50000-59999)
    Источник: Внешняя (94.ххх.хх.47:28372)
    Назначение: Внутренняя (192.ххх.ххх.250:59790)

    Протокол: RTP Server (TCP 50000-59999)


    • Изменено vol4ena 21 марта 2012 г. 11:28
    21 марта 2012 г. 11:27
  • Порты открыты, правила есть

    Виртуальная чистая машина ведет  себя так же... может мы что-то забыли открыть?


    • Изменено vol4ena 21 марта 2012 г. 11:57
    21 марта 2012 г. 11:52
  • Настройки эджа в топологии:

    21 марта 2012 г. 12:33
  • Судя по картинкам и названиям правил, всё сделано корректно, а вот сообщение об "RST" наводит на размышления. Похоже, это внутренняя проблема самого TMG. У вас Service Pack 2 установлен? Проблема с Sharing'ом возникает независимо от того, кто предоставляет доступ к рабочему столи или сделать это не может только внешний клиент?
    21 марта 2012 г. 21:21
    Модератор
  • Клиенты внутри сети могут все делать без проблем, но как только появляется внешний пользователь, доступ перестает работать в обе стороны, кто бы ни был инициатором.

    TMG Enterprise с сервис паком, да.

    22 марта 2012 г. 9:23
  • А на этих внутренних клиентах антивирус тоже установлен? Можете провести совсем чистый эксперимент с двумя голыми виртуальными машинами, чтоб одна была снаружи, а другая внутри?
    22 марта 2012 г. 9:47
    Модератор
  • В последнем эксперименте антивирус был только на внешней машине и находился в полностью отключенном состоянии.

    Сейчас подниму стенд с чистыми виртуалками и посмотрю как пойдет.


    • Изменено vol4ena 22 марта 2012 г. 9:51
    22 марта 2012 г. 9:50
  • Проблема осталась прежней.

    В логах TMG: 

    Состояние: Подключение было закрыто по прерыванию после того, как один из одноранговых узлов отправил пакет RST.

    На клиенте:

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

    Никаких антивирусов нет. 

    22 марта 2012 г. 12:21
  • Это, конечно, будет звучать смешно и нелепо, но если мне не изменяет память, подобные "необъяснимые" проблемы у людей лечились банальной перезагрузкой TMG :) . Вы пробовали?
    22 марта 2012 г. 13:27
    Модератор
  • Проблема вроде как решилась.

    Проверили свойства протокола HTTPS 443 порта, оказалось отсутствовала галка на фильтре веб-приложений. Поставили, все полетело.

    Спасибо Вам за то, что уделили время решению проблемы.

    З.Ы. Перезагружали сервер неоднократно. Сейчас в логах TMG осталась ошибка по RST, но все работает)) 


    • Изменено vol4ena 22 марта 2012 г. 13:52
    22 марта 2012 г. 13:41
  • Если вас не затруднит, не могли бы вы показать эту настройку здесь в виде картинки? Для потомков, так сказать :) .
    22 марта 2012 г. 15:36
    Модератор
  • Вот картинка и настройка)

    23 марта 2012 г. 11:10
  • Не нужно этого делать.
    Фильтр веб-прокси всёравно не сможет заглянуть внутрь SSL трафика, а проблему может добавить.


    MCITP

    23 марта 2012 г. 17:45
    Модератор
  • Я надеюсь публичный IP адрес 94.ххх.хх.47, который вы используете на внешнем интерфейсе TMG для публикации Lync Edge больше ни в каких других публикациях не используете?

    MCITP

    23 марта 2012 г. 17:51
    Модератор
  • Действительно с фильтром появились проблемы.

    Публичный IP используется для публикаций Exchange и RemoteApp, но ходят они по доменному имени.

    Для того, чтобы не путаться, тот IP, который Вы указали это внешний адрес клиента, зафиксированный в логах TMG при тесте.

    Публичный IP TMG это 91.ххх.хх.26

    И все-таки, как же побороть эту неприятность?

    26 марта 2012 г. 6:17
  • А как такое возможно? Если у вас 443-й порт используется для публикации ресурсов, как он будет ещё и NAT для A/V выполнять?

    Как вариант, измените в топологии номер порта, например, на 442, измените соответствующие правила на TMG и выполните проверку работоспособности...

    26 марта 2012 г. 8:49
    Модератор
  • Дело в том, что когда клиент идет, допустим, по адресу sip.domain.com:443 срабатывает правило публикации веб-сайта, в противном случае срабатывает правило публикации не веб-сайта, которое и отправляет запрос на Edge.

    Порт сейчас поменяю и правила поправлю. Посмотрим, как он себя будет вести)


    • Изменено vol4ena 26 марта 2012 г. 9:51
    26 марта 2012 г. 9:32
  • Изменила порт, поправила правила. Ошибка осталась прежняя:

    Тип журнала:Служба межсетевого экрана
    Состояние: Подключение было закрыто по прерыванию после того, как один из одноранговых узлов отправил пакет RST.
    Правило: Audio Video Edge RTP (TCP 50000-59999)
    Источник: Внешняя (94.ххх.хх.47:28372)
    Назначение: Внутренняя (192.ххх.ххх.250:59790)

    Протокол: RTP Server (TCP 50000-59999)

    26 марта 2012 г. 11:53
  • Не понял :) ! У вас же служба Access Edge работает на порту 5061, а не 443. Или говоря про имя "sip.domain.com" вы не имеете в виду доступ к службам Lync'а?
    27 марта 2012 г. 6:29
    Модератор
  • На TMG есть два вида публикаций.

    1. Первая работает по запросу доменного имени (contoso.com) и пересылает запрос на веб-сервер.

    2. Вторая работает по прямым запросам на ip адреса (92.хх.ххх.127) и переадресовывает все запросы на один порт соответствующего внутреннего сервера, например запрос на адрес 92.хх.ххх.127:443 переадресовывает на внутренний сервер по порту. 

    Во втором случае это запрос приложения, по порту.

    В нашем случае это клиент Lync, при запросе (совместного доступа рабочего стола или приложения) по порту 50000-59999. перенаправление проходит правильно, как мы можем видеть по логам:

    Тип журнала:Служба межсетевого экрана
    Состояние: Подключение было закрыто по прерыванию после того, как один из одноранговых узлов отправил пакет RST.
    Правило: Audio Video Edge RTP (TCP 50000-59999)
    Источник: Внешняя (94.ххх.хх.47:28372)
    Назначение: Внутренняя (192.ххх.ххх.250:59790)

    Протокол: RTP Server (TCP 50000-59999)

    но почему падает такая ошибка непонятно. И более того, не понятно, почему при установке галочки на фильтр веб-прокси 443 порта все работает.

    Готовы предоставить доступ, чтобы все-таки решить проблему.

    27 марта 2012 г. 8:28
  • Я, конечно, в TMG не ноль, а скорее два нуля :) . Так как ваша проблема относится именно к TMG, а не к Lync'у, поэтому, рекомендовал бы обратиться с вашей проблемой в соответствующий раздел.
    27 марта 2012 г. 8:38
    Модератор
  • Спасибо, создала тему в соответствующем разделе. 

    http://social.technet.microsoft.com/Forums/ru-RU/isaru/thread/48c1dae4-b805-47ec-b307-672e7cf4e018

    27 марта 2012 г. 14:09
  • Я, конечно, написала в другой раздел форума, по ссылке.  А скажите, пожалуйста, там вообще кто-то отвечает? :)
    28 марта 2012 г. 8:43
  • Уж чего не знаю, того не знаю - я на той ветке никогда не был и отвечать за её участиков не могу.
    28 марта 2012 г. 9:40
    Модератор
  • Так как движения в решении вопроса не наблюдаю, давайте ещё раз всё проясним...

    У вас на TMG всего один внешний IP-адрес? Что, кроме Edge'а Front-End'а, им ещё публикуется? Из ваших ответов, я понял, что у вас там есть ещё Exchange и Remote Desktop Web Access/Gateway.

    28 марта 2012 г. 21:31
    Модератор
  • Попробуйте проработать вот эту статью - http://support.microsoft.com/kb/934301
    Попробуйте включить\отключить фильтр веб-прокси для созданных вами протоколов, участвующих в правилах.


    MCITP

    29 марта 2012 г. 8:29
    Модератор
  • Да, все верно. Есть и Exchange и  Remote Desktop Web Access/Gateway. Еще есть, отдельно, проброс 443 порта.

    29 марта 2012 г. 9:51
  • А этот проброс, судя по картинке, для Outlook Anywhere (RPC over HTTP) используется?

    В общем, когда вы делаете публикацию ресурсов, то один порт может выступать либо для Reverse Proxy, либо для NAT'а - одновременно два варианта работать не могут. Поэтому, для начала, предлагаю провести "чистый" тест - отключите все правила на TMG (и даже для Web-омпонентов Front-End'а), которые не относятся к Edge-серверу...

    29 марта 2012 г. 9:57
    Модератор
  • После отключения всех правил, не относящихся к Edge, доступ заработал. 
    29 марта 2012 г. 10:09
  • Ну вот вам и повод для размышления ;) ...

    В общем, никогда не используйте один и тот же порт одновременно для Reverse Proxy и NAT'а.

    • Предложено в качестве ответа Peter Koreshkov 30 марта 2012 г. 7:59
    29 марта 2012 г. 10:12
    Модератор
  • Вопрос решили, разнесли по по разным портам. все работает.

    Спасибо за то, что уделили время и помогли в решении проблемы.

    • Предложено в качестве ответа Peter Koreshkov 30 марта 2012 г. 8:00
    30 марта 2012 г. 7:56
  • Пожалуйста :) .

    А спасибо здесь принято выражать нажатием кнопки "Пометить как ответ" ;) .

    • Помечено в качестве ответа vol4ena 30 марта 2012 г. 8:51
    30 марта 2012 г. 8:15
    Модератор