Доброго дня.
Опять таки, для тех, кто имеет опыт установки и настройки пограничного сервера Lync 2013, тут мало что нового. И все же, в продолжение статьи Пошаговая установка Skype for Business Server 2015 Standard хочу поделиться опытом установки и настройки роли S4B Edge и разъяснить некоторые, не всегда понятные, моменты, поэтому прошу прощения за то, что статья такая длинная.
1. Требования к серверу с ролью Edge и схема решения.
В первую очередь, как обычно, следует начать с ознакомления с общими требованиями. Сервер, на котором будет установлена роль S4B Edge должен соответствовать следующим требованиям:
- Роль Edge, что называется, «standalone», то есть должна быть установлена на отдельном сервере, где нет других ролей сервера Skype для бизнеса;
- Сервер должен размещаться в периметре сети;
- Сервер не должен быть в домене, а должен находиться в рабочей группе;
- Сервер должен быть мультихомным, то есть, в нашем случае, иметь 2 сетевых адаптера;
Отдельное и особое внимание заслуживает рассмотрение требований к сети. Какие порты и протоколы должны быть открыты и как вообще выглядит схема движения трафика. Есть замечательный постер Skype for Business 2015 Protocol Workloads Poster, который описывает всю картину в целом, крайне рекомендую с ним ознакомится. Со своей стороны я, сделаю выжимку относительно роли Edge. В общем схема выглядит примерно так:
Так же, отдельно требуется заранее подготовить внешнюю зону DNS вашего домена.
Записи типа A. Имена можно выбрать по желанию, но именно их надо будет указать далее в топологии, как внешние имена служб S4B.
- sip.domain.com — access edge, запись службы установления подключения
- webconf.domain.com — web conference, запись службы поключения к веб конференции
- av.domain.com — audio & video traffic, запись службы аудио и видео траффика
Записи типа SRV.
- _sip._tls.domain.com — порт 5061 — классическая запись для автоообнаружения;
- _sipfederationtls._tcp.domain.com — порт 5061 — запись для обнаружения вашего домена федеративными пользователями;
Так же немаловажный вопрос, какой сертификат должен использоваться на сервере Edge, выданный собственным доменным центром сертификации или коммерческий, выданный публичным центром сертификации. Ответ тут довольно прост и очевиден. Коммерческий сертификат позволяет:
- Использовать федерацию со Skype(R);
- Избежать ряда административных вопросов в случае федерации со сторонними пользователями Skype for business (Lync и др.), таких как добавление вашего сертификата на сервер вашего федеративного партнера и пр.
- Избежать необходимости установки вашего сертификата на компьютеры удаленных пользователей.
- Избежать необходимости установки вашего сертификата перед подключение к веб-конференции.
- и т.д.
От себя могу порекомендовать использовать UCC Сертификаты наших партнеров. Однако, для целей тестирования вполне подойдет собственный сертификат, его я и буду использовать в этом развертывании.
2. Подготовка к развертыванию.
Сетевые адаптеры. Начать лучше с назначения адресов на сетевые адаптеры. Я их назвал не оригинально, DMZ и LAN соответственно.
- Сетевой адаптер LAN 192.168.1.31, в локальной сети
- Сетевой адаптер DMZ 172.17.1.31, в пограничной сети
FQDN сервера Edge. Поскольку сервер в рабочей группе, а не в домене, необходимо добавить ему DNS суффикс домена lab.local.
DNS. Теперь необходимо добавить имя S4B-Edge в DNS зону домена lab.local
Сертификаты. Теперь надо добавить корневой сертификат доменного центра сертификации, который будет использоваться для выдачи сертификатов серверу Edge. Самый простой, наверно, способ использовать веб-оснастку certsrv. В моем случае CA находится на контроллере домена DC01.
Скачать корневой сертификат,
И установить его в доверенные корневые центры сертификации.
Так, для чего, собственно, были проделаны эти шаги? Все коммуникации между серверами Skype для бизнеса являются зашифрованными. Поэтому было необходимо добиться того, чтобы серверы S4B-FE и S4B-Edge понимали друг друга и были доступны по своим FQDN. Для этой же цели на Edge установлен сертификат доменного центра сертификации.
2. Добавление Edge в топологию S4B.
Для этого, нужно открыть построитель топологии расположенный на сервере S4B-FE, и воспользоваться контекстным меню на соответствующем пункте
Если добавляется пул, в котором будет только один сервер Edge, то надо указать FQDN сервера Edge.
Сразу рекомендуемую включить федерацию и федерацию со Skype. XMPP, кто как хочет ☻
В моем случае я не буду использовать единое имя для всех сервисов, а разнесу их по разным именам.
Использовать только IPv4 на на внешнем (DMZ в моем случае) и внутреннем интерфейсе (LAN)
Поскольку в моем случае будет использоваться один внешний IP-адрес, и сервисы разнесены по разным именам, то надо задать имена этим сервисам и соответствующие порты 5061, 444, 443 «default and recommended»(c). Имена же можно выбрать по желанию ☻
Далее указать локальный адрес (LAN) сервера Edge.
Далее указать пограничный адрес (DMZ) сервера Edge.
Далее указать внешний адрес.
Теперь указать Front-End пул к которому этот сервер Edge будет привязан.
Поскольку других серверов (пулов) Edge тут нет, то смело ассоциируем этот пограничный сервер с пулом переднего плана
Теперь остается только опубликовать топологию
И убедиться, что топология успешно опубликована.
Через несколько минут, нужно будет выгрузить текущую конфигурацию в файл
Полученный файл edgeconf.zip скопировать на сервер Edge, он понадобится чуть позже.
3. Установка ролей и компонентов S4B Edge.
Собственно установка на сервере S4B Edge.
Далее запистить setup.exe с установочного диска Skype for business. Можно даже оставить галку проверить обновления.
Если обновления есть, то они скачаются и устанавливаться будет уже более новая версия
После установки компонентов ядра откроется Deployment Wizard. В нем нас интересует только установка.
Далее по порядку, шаг 1 установить компоненты локального хранилища.
Тут надо будет указать выгруженный ранее файл edgeconf.zip
Далее убедиться, что ошибок нет.
Теперь шаг 2, установка компонентов Skype
Убедиться, что установка прошла без ошибок.
Далее шаг 3, запрос и привязка сертификатов. Обратите внимание, что на втором шаге нет зеленой галки, о том что установка успешно выполнена, можно это проигнорировать, после настройки сертификатов галка появится.
Начнём с внутреннего сертификата, он будет использоваться для шифрования соединения между сервером Front-End и Edge. Итак, его надо запросить.
Запрос можно сделать оффлайновый, но зачем он нужен, когда можно сделать запрос онлайн ☻
Для этого потребуется указать путь к центру сертификации в виде «Сервер\Имя Центра сертификации»
Так же придется указать логин пароль, от чьего имени будет совершен запрос
Какой-то специальный шаблон можно выбирать по вашему усмотрению, по умолчанию будет использоваться шаблон WebServer на 2 года.
Далее можно изменить имя сертификата и по выбору сделать его экспортируемым или нет. Я поставил галку, но её можно и не ставить, этот сертификат нигде кроме этого сервера не пригодится.
Теперь надо запонить разные арибуты сертификата
И
Предложенный СN сертификата — FQDN сервера, в данном развертывании большего и не надо.
SAN имена добавлять в сертификат не надо
Далее краткое саммари и совершение запроса к CA
Далее непосредственно запрос и результат запроса
Далее, предлагается сразу же и првязать сертификат к службе запустив мастер назначения сертификатов к S4B.
Далее опять таки саммари
Теперь сертификат запрошен, выдан и назначен службе.
Теперь надо разобраться с сертификатом для внешнего доступа. Этот сертификат назначается на 3 службы:
- access edge, службы установления подключения (SIP)
- web conference, службы поключения к веб конференции
- audio & video traffic, службы аудио и видео траффика
В принципе, на каждую службу можно назначить по отдельному сертификату, но реальных примеров из жизни, и самое главное, необходимости в этом я не встречал. Тут же можно назначить на эти службы коммерческий сертификат если он есть. В моем случае его нет и я запрошу сертификат в доменном центре сертификации.
Далее практически все как с внутренним сертификатом, за следующими отличиями:
Имя сертификата
Автоматически подставится CN и SAN имена сертификата
Нужно указать sip домен
Так же нужно будет добавить еще одно имя av.alekssh.com
Далее все аналогично с внутренним сертификатом, выполнение запроса, выдача и привязка к соответсвующим службам в стиле «далее-далее». В итоге должно получиться вот так:
Так же проверьте, что в Deployment Wizard все галки радостно зеленеют.
После этого я рекомендую перезагрузить сервер, а после перезагрузки убедиться что службы запущены
и, конечно же, в панели управления на сервере Front-End (или веб консоли cscp) по зеленой галке убедиться, что идет репликация.
Теперь можно приступать к тестированию подключения через интернет 🙂
вроде работает.
Надеюсь статейка будет полезной ☻
Alexander Shestakov
Уведомление: S4B. Пошаговая новая установка Skype for Business Server 2015 Standard. S4B За 2 часа :-) | IT Notes by Alexander Shestakov
Привет. А можешь рассказать, какие порты, через что и куда ты пробрасывал?
НравитсяНравится
Да, в этом конкретном случае, я настроил проброс портов с внешнего адреса в подсеть, которая выполняет роль периметра. В роли файервола я использовал pfsence, пробросил tcp порты 5061, 444 и 443. На внутреннем периметре ничего не настривал, сервер был в локальной сети (по идее это не правильно, но для понимания логики достаточно)
НравитсяНравится
При переходе по https://sip.dom.com, пишет соединение сброшено, подключается теперь только при прокинутом VPN. На внешнем хостинге прописаны sip, _sipfederationtls._tcp, _sip._tls webconf, meet, dialin, av, lyncdiscover, при переходе по https://. Просьба обменяться почтой для ускорения)
НравитсяНравится
2 сетевых адаптера сделано для простоты настройки примера?
НравитсяНравится
Да нет, это если не обязательное требование, то как минимум рекомендация 🙂
НравитсяНравится
нужна ли запись av в публичном сертификате и для чего?
НравитсяНравится
Зависит от того как будет реализован Увпу сервер. В можно использовать как один адре с так и 3. Если один, то можно использовать и одно имя, 3 имени это для понимаю какой трафик куда идет. Если 3 адреса, то 3 имени необходимо. AV в моем случае указывает на адрес по которому осуществляется для движения медиа-трафика.
НравитсяНравится
Добрый день! Александр, подскажите, если сможете:
Поднят EDGE с внешним сертификатом и записями sip.firma.ru и webconf.firma.ru. При авторизации пользователя из интернет с именем user1@firma.ru все проходит замечательно. При авторизации пользователя с именем user2.firma2.ru (для домена firma2.ru есть запись _sip._tls.firma2.ru с отсылкой на sip.firma.ru) клиент скайп выдает предупреждение, что не удается проверить является ли этот сервер доверенным к вашему входу. На что я могу согласиться и также успешно авторизуюсь как пользователь. Вопрос — будет ли после такого предупреждения все корректно работать и как можно от этого избавиться, какие имена добавить во внешний сертификат?
НравитсяНравится
Спасибо, отличный вопрос:) я уж думал я один такой:)) признаться у меня такая конфигурация так и не взлетела. Не могу найти ссылку где я прочел или как я пришел к выводу, но: srv записи должны ссылаться на A запись своего домена, srv firma на sip.firma srv firma2 на sip.firma2 — соответственно в сертификате должен быть набор имен для обоих доменов. В моем случае забили и стали использовать один домен. Если получится проверить, то прошу отписаться по результатам — любопытно:)
НравитсяНравится
Доброго дня Александр. Все настроил по вашей статье, но у меня нет периметра , а просто одна сеть, на границе с инетом стоит микротик. На микротике пробросил tcp порты, но при тестировании выдает следующую ошибку
Тest Steps
Attempting to resolve the host name sip.itp.ru in DNS.
The host name resolved successfully.
Additional Details
Testing TCP port 5061 on host sip.itp.ru to ensure it’s listening and open.
The specified port is either blocked, not listening, or not producing the expected response.
Tell me more about this issue and how to resolve it
Такое ощущение, что трафик попросту не доходит до EDGE за микротиком. Что можно посмотреть ?
НравитсяНравится
Что говорит telnet? С клиента telnet sip.itp.ru 5061
НравитсяНравится
Да все хорошо.Подключение открывает.
НравитсяНравится
Доброго дня Александр. Думаю что вот по ссылке я тут тему раскрыл со своими проблемами
https://social.technet.microsoft.com/Forums/ru-RU/22f00094-1de2-49c6-aaee-5cdc1b88e1ea/s4b-edge-?forum=sfbru
НравитсяНравится
Александр приветствую! Настроил вроде бы эдж, удаленные клиенты стали подключаться к линку, и мобильные и десктопные. Вопрос вот чем. Как определить все таки действительно через эдж народ подключается к линку? Ведь Lyncdiscover.domain.ru указывает на фронтэнд пул, получает рутокен, и его тоже надо выводить за нат. а sip.domain.ru av.domain.ru и webconf.domain.ru должны указывать на сервер эдж дмз интерфейс. в топологии sip.domain.ru указывает на 5061 порт tls, av.domain.ru указывает на 443 а webconf.domain.ru указывает на 444 порт и все это сходится на дмз интерфейсе с адресом, который выведен как дст-нат на роутере.
в SRV записях выставлено следующее.
_sip._tls.domain.ru. 900 IN SRV 0 0 443 csweb.domain.ru.
_sipfederationtls._tcp.domain.ru. 900 IN SRV 0 0 5061 sip.domain.ru.
_sipinternaltls._tcp.domain.ru. 900 IN SRV 0 0 443 csweb.domain.ru.
domain.ru фикция конечно же.
testconnectivity сервис проходит до последнего теста и потом затихает на таймауте, и федерация с pic.lync.com подготовлена со стороны микрософта но клиентов скайпа я не вижу.
НравитсяНравится
Эмпирическим путем выяснено что при выключенном эдже, авторизация через внешний доступ работает, сами звонки на астериск как локальный ригистар-сервер работают но голоса собеседников не слышно. при включении дмз интерфейса голос появляется.
НравитсяНравится
и видео-голосовые звонки между пользователями линка тоже не работают при выкчлюенном дмз интерфейсе, хотя вызовы идут.
Значит все таки авторизация, контакт листы и сообщения с статусом видеть можно а вот звонить нет.
НравитсяНравится
http://www.lynclog.com/2015/02/lync-edge-sip20-488-compression.html
проблема в алгоритме подписи внешнего сертификата…. из-за этого федерация Линк-скайп может не работать
НравитсяНравится
Прошу прощения, работы навалилось. Вообще из-за этого может все что угодно не работать. Неужели у вас коммерческий сертификат не sha256?
НравитсяНравится
Да вот как раз именно такой коммерческий от комодо. Но у меня 2013 линк а не 2015 с4б
НравитсяНравится
В линке там да, нужно было чтобы скайп аккаунт был привязан к учетной записи Майкрософт. Попробуйте меня добавить alex_shestakov@hotmail.com
НравитсяНравится
Не отправляет. Правда я с мобильного клиента пытащся. А почему именно @hotmail.com? Это логины скайпика такие fqdn?
НравитсяНравится
А то я пинаю свой личный shaverdoff@outlook.com
Потому как любые другие варианты не канают
НравитсяНравится
Предлагаю поставить таки «наше все» (wireshark) и посмотреть какие запросу куда идут пакеты при отправке запроса на добавление. Запросы должны идти на адреса 131.253.130.0/24
157.56.187.0/24
Список конечно не полный
НравитсяНравится
это хоть сейчас
вот
вывод с дебагера
TL_INFO(TF_PROTOCOL) [0]1790.13BC::08/10/2017-21:36:57.982.00002c9b (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[959253342] $$begin_record
Trace-Correlation-Id: 959253342
Instance-Id: 274B
Direction: incoming;source=»external edge»;destination=»internal edge»
Peer: federation.messenger.msn.com:5061
Message-Type: response
Start-Line: SIP/2.0 488 Compression algorithm refused
From: sip:sip.altarix.ru;tag=1B60F59B4D65CC1D8F5ED7B50AC93F5B
To: sip:federation.messenger.msn.com;tag=61E59B807C21F9EE65F285A64281F844
Call-ID: 343B245B045CEF7FFFB8
CSeq: 1 NEGOTIATE
Via: SIP/2.0/TLS 172.29.100.92:49257;branch=z9hG4bK75FB3A73.FDB11CE76FAA08A9;branched=FALSE;received=131.253.130.254;ms-received-port=49257;ms-received-cid=41B66600
Content-Length: 0
ms-diagnostics: 2;reason=»See response code and reason phrase»;HRESULT=»0xC3E93C77(SIPPROXY_E_COMPRESSION_ALGORITHM_NOT_ENABLED)»;source=»federation.messenger.msn.com»
ms-telemetry-id: 3A01322D-2518-553C-A8F1-7283448C6BBD
Server: RTC/7.0
$$end_record
НравитсяНравится
это? https://social.technet.microsoft.com/Forums/ie/en-US/4ba6c983-f08f-4f26-8acd-a1351a6d4f5a/issues-with-hosted-exchange-um-and-lync-2013?forum=lyncdeploy
НравитсяНравится
идейно судя по посту
«Confirm you have correct static routes on your Edge’s internal nic to all Lync Server and Lync Client subnets. Have you restarted the Edge server? If NATing the External interface of the Edge server make sure the NAT is bidirectional.» нужно прописывать статки роут от сети дмз эджа до сети линк?
а если у меня один эдж сервер с двумя интерфейсами который одним концом смотрит в дст нат и снаружи телнетом на порты описанные в топологии хожу, а внутренний без дефолтроутера интерфейс в сети самого линка. хождение пакетов есть. линк сеть и клиенты внутренние в разных влан
НравитсяНравится
вообщем у меня не та ошибка
ms-client-diagnostics: 22; reason=»Call failed to establish due to a media connectivity failure when both endpoints are internal»;CallerMediaDebug=»audio:ICEWarn=0x40003a0,LocalSite=10.10.10.125:6735,LocalMR=10.11.11.23:51430,RemoteSite=10.27.46.15:5286,RemoteMR=207.46.5.80:54106,PortRange=1025:65000,LocalMRTCPPort=51430,RemoteMRTCPPort=54106,LocalLocation=2,RemoteLocation=2,FederationType=0″
$$end_record
это у коллеги по ссылки .. .а у меня вот что
ms-diagnostics: 2;reason=»See response code and reason phrase»;HRESULT=»0xC3E93C77(SIPPROXY_E_COMPRESSION_ALGORITHM_NOT_ENABLED)»;source=»federation.messenger.msn.com»
ms-telemetry-id: 08A9AAB9-4154-5B2B-8B20-BF89902BACE8
Server: RTC/7.0
$$end_record
НравитсяНравится
Александр я вот постучался в скайп акк shaverdoff
НравитсяНравится
тьфу ты… Вам постучался.
НравитсяНравится
Вот это я тупанул! надо было в заказе провижена федерации указать сип домен а я хосты эджа указал! вот прям хоть стой хоть падй.. не внимательно прочитал… и причем повторно сделал ошибку, заказал удаление провижена. а ждать теперь еще неделю… и потом неделю на перепровижен)
НравитсяНравится
Ну что бывает 🙂 Там надо указывать sip адрес сервера, чтобы серверы Skype (R) понимали куда идти при обращении к аккаунтам в определенном домене.
НравитсяНравится
не только сип имя сервера эджа но и сип домен который используется
НравитсяНравится
Здравствуйте, Александр! Настраиваю Edge сервер по вашему мануалу, и столкнулся на шаге: «Далее указать пограничный адрес (DMZ) сервера Edge» .Указываю IP во всех трех полях, а вот дальше идти не дает. Выдает ошибку: «Сочетание IP адреса и номера порта должно быть уникальным». Но у вас, на слайде, IP в этих полях одинаковые. Что не так?
НравитсяНравится
Доброго дня,
Надо смотреть какие порты указаны. Одинаковый адрес возможен с разделением по портам.
НравитсяНравится
Доброе время суток!
Александр, а все ли верно с портом в этом абзаце:
_sip._tls.domain.com — порт 5061 — классическая запись для автоообнаружения;
Разве _sip._tls не 443 порт использует?
НравитсяНравится
Добрый день,
В зависимости от того, что указано в топологии. В моём случае (при использовании одного внешнего адреса и разделения по портам) для sip\tls используется порт 5061. При использовании нескольких адресов «классической» будет запись на 443 порт 🙂
НравитсяНравится
Добрый день.
Настраиваю S4B целиком по вашим мануалам, переодически возникают вопросы которые решаются гуглом или чуть большим вниманием к настройкам.
Нынче столкнулся с проблемой настройки именно внешнего доступа.
Внутри организации всё работает прекрасно, так что предоставлю настройки внешнего доступа.
На Edge-сервере две сетевых карты, так же как и у вас прописано.
sip IN A 100.100.100.2
webconf IN A 100.100.100.2
av IN A 100.100.100.2
lyncdiscover IN A 100.100.100.1
scheduler IN A 100.100.100.1
meet IN A 100.100.100.1
dialin IN A 100.100.100.1
meeting IN A 100.100.100.1
sipexternal IN A 100.100.100.1
_sip._tls SRV 5 5 5061 sip
_sipfederationtls._tcp SRV 5 5 5061 sip
_sipinternaltls._tcp SRV 5 5 5061 sip
_sipinternal._tcp SRV 5 5 5061 sip
При помощи MRCA анализирую подключение.
Автодискавер отрабатывает верно.
Само подключение прерывается с ошибкой:
Couldn’t sign in. Error: Error Message: The certificate chain was issued by an authority that is not trusted.
Error Type: TlsFailureException.
Все порты проброшены, telnet до них доступ даёт.
100.100.100.1 — фронт
100.100.100.2 — edge
НравитсяНравится
Приветствую, тут в явном виде говорится про сертификат. У вас используется сертификат выданный доменным центром сертификации? MRCA про него ничего не знает, чтобы он принял сертификат, сертификат должен быть выдан публичным центром сертификации, проще говоря коммерческим. MRCA это конечно хорошо, но что говорит клиент при подключении?
НравитсяНравится
Клиент пишет:
«Не удаётся подключиться к серверу. Проверьте сетевое подключение или адрес сервера и повторите попытку.»
Конкретно это выдаёт мобильный клиент, на котором установлен корневой сертификат доменного центра сертификации.
НравитсяНравится
Прошу прощения. Несколько неверно сообщил работоспособность. Десктоп-приложение работает прекрасно (если импортировать корневой сертификат). А вот мобильный клиент ни в какую.
Плюс meet внешний работает хорошо, но ссылка на подключение к веб-конференции ссылается на локальный адрес сервера, но это, как я понимаю, из-за отсутствия публикации приложения в WAP на текущий момент.
НравитсяНравится
Всё таки оказалось проще и легче.
После верной публикации приложений в WAP всё заработало корректно.
Осталось разобраться с настройками федерации.
НравитсяНравится
Добрый день.
Очень полезная статья, мне во многом помогла, спасибо! Но думаю было бы полезно в неё добавить упоминание, что для работы федерации Skype нужно ещё проходить процесс регистрации на ресурсе https://pic.lync.com и делать дополнительные манипуляции на фронтенд сервере для её активации.
НравитсяНравится
Александр, добрый день! подскажите как работает autodiscover в такой схеме развертывания? поидее внешний клиент увидев учетную запись вида: user@domain.com пойдет искать сервер по записи — lyncdiscover.domain.com, помогите понять принцип работы)
НравитсяНравится
Добрый. Механизм автообнаружения неплохо описан https://technet.microsoft.com/ru-ru/library/dn951397.aspx
НравитсяНравится