none
Главное конечное имя неверно RRS feed

  • Вопрос

  • Добрый день, пытаюсь опубликовать веб компоненты Lync в интернет в TMG правило, публикации HTTPS сайта, через прослушиватель HTTP. При проверке правила появляется ошибка.  Главное конечное имя неверно. Подскажите какие сертификаты куда надо назначать. Имею external adres lync.domain.com и внутренний адрес srvlync.domain.local  Выпустил два сертификата, назначил каждый на свой сайт. Что я делаю не так?
    13 декабря 2011 г. 11:42

Ответы

  • Я уверен, что у вас вся загвоздка была именно в том, что в сертификате внешнего сайта не было прописано того имени по которому к нему обращался TMG, то есть "srvlync.domain.local" ;) . На самом TMG это имя овершенно не нужно, так что можете использовать предыдущий сертификат.
    14 декабря 2011 г. 9:47
    Модератор

Все ответы

  • Рекомендую посмотреть.
    13 декабря 2011 г. 19:38
    Модератор
  • Это видео я видел и учился по нему, все сделано как там, но ошибка, причем где я не пойму. У меня вопрос почему при публикации веб сервисов Lync в правиле используется HTTPS, а прослушиватель ставится HTTP?
    14 декабря 2011 г. 6:30
  • А вы можете сказать мне конкретное время в нашем видео, где у вас возникает вопрос :) ?

    14 декабря 2011 г. 8:04
    Модератор
  • На 39-ой минуте вы создаете правило публикации веб-сайт а lync.contoso.com, у меня Lync расположен допустим на сервере srvlync.domain.local в топологии указано, что Internal FQDN srvlync.domain.local, а External FQDN lync.domain.ru Я сгенерировал 2 сертификата для Internal и External 

    При создании правила в TMG я указываю внутреннее имя сайта srvlync.domain.local, а внешнее  lync.domain.ru использую SSL, но прослушиватель ставлю HTTP, то же что и для сайта CA. В итоге получаю ошибку Не верное конечное имя. Что не так, не пойму. Спасибо.

    14 декабря 2011 г. 8:11
  • Ну так а вы дальше-то смотрите - на 43:10 я, как раз, говорю, что публикацию сделали неправильно, а точнее, забыли сделать HTTPS ;) .
    14 декабря 2011 г. 8:30
    Модератор
  • До этого я нашел, включил HTTPS, запросил сертификат для External Service External FQDN lync.domain.ru , может надо добавить в него как  SAN Internal FQDN srvlync.domain.local? Ошибка та же, что ещё проверить?
    14 декабря 2011 г. 8:53
  • У вас на внешний сайт Lync'а в IIS'е сертификат с какими именами повешен?

    Вы бы, хоть, картинку с ошибкой показали, что ли ;) .

    14 декабря 2011 г. 8:54
    Модератор
  • Добавил в SAN сертификата имя Internal FQDN srvlync.domain.local. Почему он сам туда не попадает? Ошибка исчезла. теперь просто выдает 403 доступ запрещен, но так и должно быть? Подскажите, пожалуйста, как во внешнем DNS прописать SRV для Lync, у роли EDGE три внешних IP av, conf, sip 
    14 декабря 2011 г. 9:37
  • Вы в который сертификат это добавили? Тот что на Front-End'е или тот, что на TMG?

    Куда именно вы заходите, что получаете 403?

    Что значит "как во внешнем DNS прописать SRV для Lync"? Берёте и прописываете с помощью соответствующих средств, соответствующие записи. А, вообще, в том же видео про это всё рассказано ;) .

    14 декабря 2011 г. 9:41
    Модератор
  • Я запросил новый сертификат для Front End только для Web External Service, добавил ему ещё один SAN с именем  Internal FQDN srvlync.domain.local , сделал его экспортируемым и выгрузил на TMG. Может надо на самом Front End заменить без лишнего SAN и без экспорта ключа?
    14 декабря 2011 г. 9:45
  • ошибка 403 при  переходе на External web адрес lync.domain.ru 
    14 декабря 2011 г. 9:47
  • Я уверен, что у вас вся загвоздка была именно в том, что в сертификате внешнего сайта не было прописано того имени по которому к нему обращался TMG, то есть "srvlync.domain.local" ;) . На самом TMG это имя овершенно не нужно, так что можете использовать предыдущий сертификат.
    14 декабря 2011 г. 9:47
    Модератор
  • Ну, в этом я проблемы не вижу - это штатное поведение ;) .
    14 декабря 2011 г. 9:51
    Модератор
  • Проблема ещё в том что при попытке получить доступ на сайт https://dialin.csoft.vrn.ru из внешней сети, получаю ошибку 

    403 - запрещено. Доступ запрещен.

    Предоставленные учетные данные не дают права на просмотр этого каталога или страницы.

    14 декабря 2011 г. 10:26
  • видимо по этой же причине нет доступа к адресной книге из внешней сети, где-то я напутал с авторизацией в правиле, нее могу понять где
    14 декабря 2011 г. 11:04
  • У меня ваш "https://dialin.csoft.vrn.ru" прекрасно открывается ;) .

    14 декабря 2011 г. 17:51
    Модератор
  • Да, спасибо. Все заработало после смены режима передачи заголовков.
    15 декабря 2011 г. 5:55
  • Можно ещё один вопрос. В зону csoft.vrn.ru на сервере провайдера я прописал SRV запись и клиент находит сервер автоматически через интернет, как мне прописать у себя запись для sipinternal у меня нет зоны csoft.vrn.ru  в локальном DNS? Хочется чтобы вход во внутренней и внешней сети происходил автоматически, я подумывал о том чтобы у провайдера указать  sipinternal, но тогда машины без доступа в интернет в локальной сети не найдут сервер Lync
    15 декабря 2011 г. 5:59
  • Так просто создайте у себя внутри эту зону. Если вы во внешней создадите такую запись, у вас внешние клиенты не смогут подключиться, так как клиент не знает где он находятся внутри или снаружи ;) .

    15 декабря 2011 г. 8:32
    Модератор
  • после создания у  себя этой зоны, возникают проблемы с доступом из внутренней сети к сайту http://csoft.vrn.ru т.к. хостинг провайдер может менять IP адрес 
    15 декабря 2011 г. 8:35
  • Ну, я в таких случаях, объясняю всем, что во внутренней сети к сайту обращаться лучше через "www", а во внутренней зоне делаю делегирование этого имени на DNS-сервера, держащие внешнюю зону. В этом случае, как бы ни менялись IP-адреса, для вас это будет проходить прозрачно.

    В вашем случае, нужно делегировать эту запись на сервера "ns.intercon.ru" и "ns1.intercon.ru", ну и, разумеется, внутренние DNS-сервера должны иметь к ним доступ.

    15 декабря 2011 г. 8:39
    Модератор
  • т.е. я создаю зону vrn.ru, создаю делегирование домена csoft, а как же мне добавить SRV запись теперь?
    15 декабря 2011 г. 9:05
  • Нет - создаёте зону "csoft.vrn.ru", а внутри неё уже создаёте все необходямые вам записи. А всё, что должно быть согласовано с внешней зоной, делаете делегирование.
    15 декабря 2011 г. 9:08
    Модератор
  • создал зону csoft.vrn.ru, домен WWW делегировал на внешний DNS, создал SRV запись в зоне csoft.vrn.ru

      > set type=srv

    > _sipinternaltls._tcp.csoft.vrn.ru

      srvdc.csv.local

    Address:  192.168.10.101

     

    _sipinternaltls._tcp.csoft.vrn.ru       SRV service location:

              priority       = 0

              weight         = 0

              port           = 5061

              svr hostname   = srvmail.csv.local

    srvmail.csv.local       internet address = 192.168.10.9

    в AD в атрибутах пользователя параметр proxyAddresses имеет одно из значений SIP:user@csoft.vrn.ru

    При включении авто поиска сервера в Lync выдает ошибку "Сервер не доступен"

     

    Что не так? 

    15 декабря 2011 г. 9:39
  • А у вас Front-End называется "srvmail.csv.local"? Больше, как-то, на почтовый похоже ;) .

    15 декабря 2011 г. 9:43
    Модератор
  • да, так сложилось исторически, хотелось объединить на одной машине Lync и Exchange, но потом от этого решения отказались, а имя сервера осталось

    Вроде все заработало, после очистки локального кеша DNS. Спасибо.

    Хотел бы ещё спросить если у вас материалы по настройки интеграции Lync c SIP операторами или другие решения по интеграции с городской и офисной телефонией?

    15 декабря 2011 г. 9:46
  • Конечно есть ;) ! На данный момент у нас уже пять записей по теме Lync'а.

    15 декабря 2011 г. 9:50
    Модератор
  • Спасибо,  у вас очень хорошие и информативные материалы. 
    15 декабря 2011 г. 9:55
  • Простите, продолжил тестирование внешних клиентов и столкнулся с проблемой, что передача файлов, доступ к рабочему столу и прочие фишки не работают, нормально проходит только сообщения и голосовые звонки. Что может быть не так?
    15 декабря 2011 г. 13:53
  • Давайте, всё же, не раздувать данную тему до бесконечности, а создавать по каждому вопросу соответствующую тему ;) . А то мы тут уже обсудили всё от сертификатов до DNS'а.
    15 декабря 2011 г. 17:45
    Модератор
  • Ну так а вы дальше-то смотрите - на 43:10 я, как раз, говорю, что публикацию сделали неправильно, а точнее, забыли сделать HTTPS ;) .


    Добрый день!
    Хотелось бы вернуться к этой ошибке.
    Решил вывесить Lync наружу. У нас это не интернет, а общая сеть кучи предприятий, но ничего от этого не меняется. Все делал в соответствии с

    рекомендациями в видео Stanky. Поставлено 4 сервера. Lync работает. Имена внутренней и внешней сети совпадают. Выписал сертификат Lync. Все имена в нем

    прописаны правильно. Сертификат действителен. Импортирован в TMG. Вся проблема начинается когда пытаешься создать правило для прослушивания web-служб

    Lync. При тестировании правила тут же выскакивает эта самая ошибка из темы этой ветки.

    Может быть кто-нибудь расскажет какова должна быть конфигурация сетевых интерфейсов TMG и настройки самого TMG для работы в этой схеме? В видео это не отражено, а наверное в этом все дело, по тому, что у авторов тестирование проходит сразу на ура, еще до того как они включили SSL и установили сертификат.

    Уже второй раз полностью перестанавливаю всю систему, но всё равно натыкаюсь на эту ошибку. Прослушиватель тоже ведет себя как-то странно. Собственно говоря, беспокоит вот этот восклицательный знак

    При этом в выписанном сертификате все имена прописаны правильно и сам сертификат признан пригодным к использованию

    Вот сдается мне все же что вопрос не в сертификатах, а в настройках TMG в этой схеме работы.

    Помогите, плиз, кто чем может! :)
    Очень надо срочно вывесить Lync наружу, а ничего не получается :(

    Обнаружил в оповещениях еще вот такую странную вещь. Не понимаю при чем тут упоминается sip.krti.vpn?  В правиле публикации он нигде не упоминается ведь.  

     
    • Изменено dima.spb 13 января 2013 г. 8:31
    13 января 2013 г. 6:33