none
Внешний доступ к Lync Server без Edge Server RRS feed

  • Вопрос

  • Здравствуйте

    Задался вопросом доступом из Internet для небольшой компании. Хотелось бы сэкономить на серверах и лицензиях, т.е. предоставить доступ и внутренних и мобильных клиентов только на одном сервере. Блокирование доступа осуществляется по filrewall.

    На основе инструмента Lync Planing tool и сниффера были определены необходимые для подключения порты и они были открыты на firewall. SRV записи и NAT настроены на External Lync Web Server.Функционально почти все заработало, кроме одного - "НЕ работает обновление адресной книги" (вернее список контактов присутствует, но выдается ошибка внизу "Невозможно выполнить синхронизацию адресной книги" и иконки контактов отсутствуют). Это было замечено только на Windows клиенте Lync.
    При этом мобильные клиенты (например, на iphone/ipad) получают адресную книгу успешно (возможно только они работают по другой схеме - через MCX сервис).

    Проблема выяснилась просто - Lync 2010 обращаяется за адресной книгой на внутренний адрес сервера вместо внешнего адреса (т.е. на lync-srv01.ad-domain.local вместо lync.e-mail-domain.com). Так как используется Lync Server 2010 Standart Edition, то lync-srv01.ad-domain.local - это как раз имя пула в топологии Lync.

    В связи с этим возникли вопросы:

    1. В чем функционально различаются внутрений и внешний Web Server на Lync Server? Пытался настраивать NAT и на внутренний и на внешний Web сервер - результат один.
    2. В топологии имя lync-srv01.ad-domain.local фигурирует только как пул (ну и соответственно как сервер регисрации клиентов), других упоминаний этого адреса нигде нет (ни в SRV записях, ни в внешнем DNS, ни в топологии). Почему клиенты лезут на этот внутрений сервер за адресной книгой? Не уж то только Edge Server может правильно "публиковать" адресную книгу для внешних клиентов?

    PS: Можно конечно прописать в hosts запись для lync-srv01.ad-domain.local на внешний IP Lync, но это как-то "топорно".


    • Изменено R. Dmitriy 20 февраля 2012 г. 4:05
    20 февраля 2012 г. 4:02

Ответы

  • 1. Да, можно сказать, что модифицирует. На самом деле Lync Front End, зная что идет запрос через Edge, сам отдает внешний адрес.

    2. Переставить с нуля будет проблематично. Или вы сможете поменять доменный суфикс нового сервера?

    • Простой правильный вариант - постаить Lync Edge.
    • Простой и неправильный - переставить на Enerprise Edition ( либо поставить Enerprise Edition рядом).

    3. Можно ли поменять в SE имя внутреннего веб сервера хитрыми недокументированными способами - не скажу. Нужно изучать и тестировать. Можно попробовать поиграть с файлом конфигурации (экспортировав конфигурацю в файл) и поискать имена там.
    Я бы этого делать не стал :-)

    • Помечено в качестве ответа Yuriy Lenchenkov 29 февраля 2012 г. 12:27
    20 февраля 2012 г. 11:48

Все ответы

  • Дмитрий,

    Насколько я понимаю процесс работы клиента lync с адресной книгой примерно проходит по такой сехеме:

    Address Book Service (ABS) обращается к ADDS и синхронизирует информацию с Back-End SQL, сам процесс работает на Front End серверах. Клиент скорее всего скачивает адресную книгу с линка https://fe.<внутр. имя домена>/abs (http://blog.ucmadeeasy.com/2010/09/24/publishing-lync-server-2010-rc-simple-urls-and-web-components-with-forefront-tmg-2010/), Edge сервер тут никак не задействован.

    Enabling external users to download meeting content for your meetings.

    • Enabling external users to expand distribution groups.
    • Enabling remote users to download files from the Address Book Service.
    • Accessing the Reach client
    • Accessing the dial-in Web page
    • Accessing the Location Information Service
    • Enabling external devices to connect to Device Update Service and obtain updates.

    Собственно именно для публикации внутренних URL и нужен публикатор Web TMG или ISA.

    Для того, чтобы клиенты могли скачивать с правельного сайта адресную книгу, его(сайт) нужно создать с внешним именем на IIS, сконфигурировать копирование файлов адресной книги и настроить новое имя сайта для клиентов. К сожалению я не делал публикацию адресной книги lync через NAT, посмотрите ин-ю по теме Address Book Download Web service

    Я думаю (это нужно протестировать) скачивание адресной книги через NAT будет работать без доп. настроек если адрес домена AD и адрес внешнего домена будут совпадать.




    • Изменено ЮА 20 февраля 2012 г. 5:35
    20 февраля 2012 г. 5:30
  • Понятно, что при внутренних подключениях клиент использует внутреннюю ссылку, при внешних (через Edge) - внешнюю на веб сервер Lync Front End.

    Внутреннюю ссылку можно поменять только в Lync Server Front End Enterprise.

    P.S. надеюсь вы понимаете, что во многих сценариях, голос и видео в вашей схеме не будут работать для клиентов, подключенных снаружи.

    P.P.S. Вы сэкономили только на одной лицензии Windows Server Standard и аппаратных ресурсах. Edge не требует лицензии Lync. 

    20 февраля 2012 г. 5:38
  • Понятно, что при внутренних подключениях клиент использует внутреннюю ссылку, при внешних (через Edge) - внешнюю на веб сервер Lync Front End.

    Но вот вопрос: модифицирует ли Edge ответы Lync (ведь как то же клиент узнал о внутреннем адресе пула)? или это делает только Web TMG или ISAпри публикации наружу Web сервисов. Если так то еще и TMG нужно покупать.

    Внутреннюю ссылку можно поменять только в Lync Server Front End Enterprise.
    А в standart "все пропало"? только переставлять с нуля ?

    P.S. надеюсь вы понимаете, что во многих сценариях, голос и видео в вашей схеме не будут работать для клиентов, подключенных снаружи.
    Видео не тестировал, а телефония работает отлично.


    Что качается публикации Web сервисов через TMG, то TMG врятли изменяет содержимое отсылаемого от Lync Server контента, так как обращение идет по HTTPS, а это значит, что прежде чем что-то изменить, TMG сначала нужно расшифровать трафик HTTPS, а потом опять зашифровать. Судя по документации при Web Site Publishing Rule таких шифраций/расшифраций не настраивается.



    • Изменено R. Dmitriy 20 февраля 2012 г. 11:21
    20 февраля 2012 г. 11:06
  • 1. Да, можно сказать, что модифицирует. На самом деле Lync Front End, зная что идет запрос через Edge, сам отдает внешний адрес.

    2. Переставить с нуля будет проблематично. Или вы сможете поменять доменный суфикс нового сервера?

    • Простой правильный вариант - постаить Lync Edge.
    • Простой и неправильный - переставить на Enerprise Edition ( либо поставить Enerprise Edition рядом).

    3. Можно ли поменять в SE имя внутреннего веб сервера хитрыми недокументированными способами - не скажу. Нужно изучать и тестировать. Можно попробовать поиграть с файлом конфигурации (экспортировав конфигурацю в файл) и поискать имена там.
    Я бы этого делать не стал :-)

    • Помечено в качестве ответа Yuriy Lenchenkov 29 февраля 2012 г. 12:27
    20 февраля 2012 г. 11:48
  • Но вот вопрос: модифицирует ли Edge ответы Lync (ведь как то же клиент узнал о внутреннем адресе пула)? или это делает только Web TMG или ISAпри публикации наружу Web сервисов.
    Внешний и внутренний "адреса" клиент получает либо через Edge при внешнем доступе, либо от Front-End'а при внутреннем. Чего ради тут что-то менять - мне совершенно непонятно.
    Видео не тестировал, а телефония работает отлично.
    Какие ваши годы ;) ...
    Что качается публикации Web сервисов через TMG, то TMG врятли изменяет содержимое отсылаемого от Lync Server контента, так как обращение идет по HTTPS, а это значит, что прежде чем что-то изменить, TMG сначала нужно расшифровать трафик HTTPS, а потом опять зашифровать. Судя по документации при Web Site Publishing Rule таких шифраций/расшифраций не настраивается.
    Как я уже говорил - мне совершенно непонятно чего ради тут что-то мнеять? А что касается "шифраций/расшифраций" - именно так при публикации и происходит ;) .
    20 февраля 2012 г. 16:38
    Модератор
  • R. Dmitriy, Stanky:

    Тут человек готов открыть FE всем хацкерам Интернета ради экономии, а вы тут про TMG ;-)
    Хотя... Amatol, вы знаете, что за счет reverse proxy можете экономить на IP адресах, в случае если у вас есть несколько веб серверов работающих по одномк порту (443 или 80)? :-). А кто-то из отвечающих (не буду показывть пальцем на Stanky) имеет опыт использования в качестве reverse proxy компонентов OS Windows Server 2008 R2.  

    Но это уже отдельная тема :-)

    20 февраля 2012 г. 17:01
  • Alexander Donin, подождите подождите) я всего лишь написал о том, что можно попробовать сделать публикацию адресной книги и ни где не упомянул что можно обойтись без Edge,  я вообще полагал что он должен быть)))  Я собственно в своем ответе попытался сказать что публикация адресной книги не зависит от роли Edge, и предположил что можно сделать с публикацией книги и NAT без обратного проксирующего сервера, если где то в моем ответе ошибка вы скажите, я исправлю ;)

    P.S. Не совсем понял(не в техническом плане) про экономию IP, видимо шютк-юмора такая))) 

    То что IIS может выступать как обратный прокси я знал, но у меня не было опыта такой конфигурации, поэтому я об это ничего сказал.



    • Изменено ЮА 21 февраля 2012 г. 5:37
    21 февраля 2012 г. 5:29
  • Не только имею данный опыт, но ещё и делюсь им с окружающими.

    P. S. И 2008 R2 вовсе не ограничено ;) .

    21 февраля 2012 г. 7:47
    Модератор
  • to Stanky. Оперативно :-)

    to Amatol. Про TMG разговор о TMG это от невнимательности и ради шутки.
    А экономия на адресах следующая:
    Имеем 10 веб серверов, каждый из которых опцубликован по порту 443. Можем либо сделать проброс портов. 10 пробросов порта 443. Значит нужно 10 белых IP адреса. Либо можем на reverse Proxy раскидывать запросы на серверы по имени сервера. owa.dom.ru на один сервер, lync.dom.ru на другой. При этом для всех имен в публичном DNS указываем только IP адрес reverse Proxy.

    21 февраля 2012 г. 10:39
  • R. Dmitriy, Stanky:

    Тут человек готов открыть FE всем хацкерам Интернета ради экономии, а вы тут про TMG ;-)

    1) Не вижу потребности менять корпоративный firewall cisco ASA на TMG только ради lync.
    2) То что защита выполнена не на TMG еще не говорит об ее (защиты) отсутствии.
    22 февраля 2012 г. 12:02
  • 1. Так и не меняйте - я, ведь, даже привёл конкретную ссылку, где в течении часа рассказывал, как можно за счёт IIS'а сделать Reverse Proxy ;) .

    2. Как я понял, речь-то была не о том, что TMG как-то сверхнадёжно защищает вашу инфраструктуру, а о том, что вы свой сервер напрямую в интернет выставляете. Хотя, тут можно долго спорить со сторонниками тех или иных религиозных убеждений :) .

    22 февраля 2012 г. 12:06
    Модератор
  • На счет безопасности.. имелось ввиду не отсутвие TMG. Тут MS постарались. Даже отдельный сайт сделали для внешних подключений.

    Имелось ввиду отсутствие Lync Edge. Прийдется публиковать Front End по портам из статьи http://technet.microsoft.com/en-us/library/gg398833.aspx. При этом часть функционала работать всё равно не будет. Как и отдельный сайт :-)

    22 февраля 2012 г. 12:17
  • На счёт того, что с Media-трафиком однозначно будут проблемы - полностью согласен, а вот на счёт отдельного сайта - ровно наоборот!

     Поспорим :) ?

    22 февраля 2012 г. 12:20
    Модератор
  • На счёт того, что с Media-трафиком однозначно будут проблемы - полностью согласен.

     Поспорим :) ?

    Про какие проблемы мы говорите ? -
    я открыл TCP/443,TCP/5061,TCP-UDP/50000-59999,UDP/3478 (т.е. те порты что сказано открыть для Edge) и клиенты подключаются и звонят.
    Большинство перечисленных портов используются Lync для внутренних целей и не используются для связи с клиентами, так что не нужно пугать этим списком, в том числе и во внутренней сети. Например, в списке стоит порт 5076/TCP Used for incoming SIP requests for the Audio Test service, но при тесте в реальной ситуации весь трафик идет через TCP/5061. И так по многим остальным портам. Проверено снифером.

    Determining External A/V Firewall and Port Requirements.
    http://technet.microsoft.com/en-us/library/gg425882.aspx


    • Изменено R. Dmitriy 22 февраля 2012 г. 13:08
    22 февраля 2012 г. 13:02
  • Вы можете верить во что вам нравится - ради бога ;) . Но для справки - через Front-End Media-трафик ходит только в случае конференций. Поэтому, рано или поздно вы столкнётесь с ситуацией, когда звонок точка-точка совершить не удаётся, но "когда приглашаешь третьего, всё нормально"...

    22 февраля 2012 г. 13:06
    Модератор