none
Настройка EDGE RRS feed

  • Вопрос

  • Добрый день!

    Сломал себе весь мозг и что там у меня. Ситуация следующая. Поднят Lync Server 2010 поднят сервер с  ролю EDGE. Публичный IP один сервисы разнесены по портам 5061 444 и 443. Проблема в следующем нельзя установить A\V если пользоатели находятся в разных местах то есть один с наружи  другой в нутри. Если оба в интете то без проблем в нутри то же все работает. Если же один пользователь в интернете другой в локалке то возможна отсылка сообщений. Так же вызов A\V можно сделать из локалки но установить соединение не удается. Где рыть и что смотреть.

    29 сентября 2011 г. 10:32

Ответы

  • В копилку кому интересно. Было две проблемы

    1. Можно было из интернета подключится под любой записью которая есть в Lync не авторизуясь.
    2. Невозможно было организовать видео/аудио звонок с из интернет во внутр.

     

    1. Проблема была в том, что на EDGE на внутрений адрес был установлен "Универсальный сертификат" который содержал внутрение имена всех серверов из-за чего проходила сквозная авторизация через сертификаты. Мораль на EDGE на внутренем сертификате ни в коем случае не дожно быть не Direct серверов ни Standart ни Front-End.
    2. Вторая проблема была вызвана установкой одного EDGE сервера как мульти сервера. Видемо, что то было не корректно настроено. После того как в топологии было указано что EDGE один почти все стало работать. (Пока не неработает предоставление доступа к приложениям)

    • Помечено в качестве ответа Morozov 3 ноября 2011 г. 15:03
    • Изменено Morozov 3 ноября 2011 г. 15:09 исправление ошибок и добавление.
    3 ноября 2011 г. 15:03

Все ответы

  • Рыть на наличие открытых портов 3478 UDP и диапазона 50000-59999 для A/V Edge.

    Копать в сторону правильной настройки сети Эджа: шлюз по умолчанию прописан для внешней сетевой, для внутренних подсетей добавлены постоянные маршруты.

    Смотреть в сторону добавления во внутренний DNS (или файл HOSTS) записи av.yourcompany.com (A/V Edge) с внешним IP-адресом.

    В случае, если на Эдже для внешней сетевой используются не реальные IP-адреса, а пограничной сети - проверить настройки топологии, а именно настройки использования NAT с прописанным внешним реальным IP адресом A/V Edge.

    29 сентября 2011 г. 12:14
  • Рыть на наличие открытых портов 3478 UDP и диапазона 50000-59999 для A/V Edge.

    Копать в сторону правильной настройки сети Эджа: шлюз по умолчанию прописан для внешней сетевой, для внутренних подсетей добавлены постоянные маршруты.

    Смотреть в сторону добавления во внутренний DNS (или файл HOSTS) записи av.yourcompany.com (A/V Edge) с внешним IP-адресом.

    В случае, если на Эдже для внешней сетевой используются не реальные IP-адреса, а пограничной сети - проверить настройки топологии, а именно настройки использования NAT с прописанным внешним реальным IP адресом A/V Edge.


    Правильно ли я понимаю что если у меня на EDGE все сервисы на одно имя но на разные порты то я должен во внутренем DNS прописать это имя с белым IP?

    Нет NAT не используется пока не настрою с белым IP.

    Порты проверил открыты.

    29 сентября 2011 г. 14:39
  • Вы имеете в виду не на одно имя, а на один IP? Вроде этого:

    sip.company.com - 144.12.13.14:5061

    webconf.company.com - 144.12.13.14:444

    av.company.com - 144.12.13.14:443

    Верно?

    Если так, то попробуйте для записи av.company.com прописать адресс 144.12.13.14 (ес-сна ваши данные подставить) на внутренних DNS или записях HOSTS Эджа и Фронтенда. В соседней ветке я упоминал - решение это спорное, но хуже быть не должно.

    Более приоритетными являются советы проверить настройки сети на Эдже, маршруты, конфигурацию ДНС и доступность указанных портов.

    29 сентября 2011 г. 14:55
  • На самом деле, наличие или отсутствие в DNS'е записей о внешних адресах на работу Edge'а ни как не сказываются ;) .

    Кроме как в сетевых настройках, проблем я больше не вижу - либо какие-то порты закрыты, либо что-то с маршрутизацией. Default Gateway только на внешнем интерфейсе прописан?

    В общем, смотрите лог SIP-стэка во время звонка...

     

    P. S. И что за манера у народа пошла вешать Access Edge на порт 5061 :) ?

    29 сентября 2011 г. 19:46
    Модератор
  • На самом деле, наличие или отсутствие в DNS'е записей о внешних адресах на работу Edge'а ни как не сказываются ;) .

    Кроме как в сетевых настройках, проблем я больше не вижу - либо какие-то порты закрыты, либо что-то с маршрутизацией. Default Gateway только на внешнем интерфейсе прописан?

    В общем, смотрите лог SIP-стэка во время звонка...

     

    P. S. И что за манера у народа пошла вешать Access Edge на порт 5061 :) ?


    Вопрос где его смотреть? На клиенте с наружи, на клиенте с нутри или на EDGE? Предпологаю что на EDGE? Да маршрут по умолчанию прописан только на внешней, на внутреней добавлен с помощью команды route -p 10.0.0.0 255.0.0.0 10.0.0.1 "Ну и что за манера у народа пошла вешать Access Edge на порт 5061 :) ?" Просто так предлагает Topologe Builder при использовании одного IP. К стати имя используется одно типа EDGE.company.ru

    30 сентября 2011 г. 3:01
  • Конечно на Edge'е - на клиентах вы этого сделать не сможете.
    30 сентября 2011 г. 6:10
    Модератор
  • Да маршрут по умолчанию прописан только на внешней, на внутреней добавлен с помощью команды route -p 10.0.0.0 255.0.0.0 10.0.0.1

    А какакая у вас настройка DNS для внешних и внутренних имён? Указывали ли внутренний DNS-сервер или прописали необходимые имена в HOSTS вручную? DNS-cуффиксы добавили на внутренней сетевой?
    30 сентября 2011 г. 11:47
  • РЫть:
    - проверьте связь (ping) от ПК в локальной сети до внутреннего IP Lync Edge.
    Маршрут должен быть
    - проверьте то же самое с Front End сервера
    - проверьте доступность Edge из вышеуказанных мест до Lync Edge по требуемым для Edge портам
    Доступность по tcp портам можете проверить клиентом "telnet", udp - например "portqry".

    Попробуйте организовать аудио или аудио-видео конференцию (сообразить на троих ;) или через меню "Провести собрание" в Lync 2010) между двумя пользователями локальной сети и пригласить  третьего из сети Интернет.
    У третьего будет аудио\видео? Если да, то ищите проблему между ПК в локальной сети и Lync Edge.


    MCITP
    30 сентября 2011 г. 12:34
    Модератор
  • Спорить готов, что если организовать собрание, то и аудио и видео будет. У самого так было и у пользователей на форуме такие же симптомы.

    Здесь где-то неверная настройка Эджа или сетей в которые он подключен. Вот только надо найти где именно трабл )

    30 сентября 2011 г. 12:40
  • Уверен, что проблема в том, что связь с Edge'м имеет только Front End, а до клиентов порты на Firewall'е закрыты - собственно, на что и намекает Илгиз ;) .
    30 сентября 2011 г. 14:40
    Модератор
  • Уверен, что проблема в том, что связь с Edge'м имеет только Front End, а до клиентов порты на Firewall'е закрыты - собственно, на что и намекает Илгиз ;) .

    Угу, в общем да.
    Только я намекаю скорее больше на маршрутизацию от клиентского ПК до внутреннего интерфейса Edge.
    Не только Front End-у должен быть доступен Lync Edge, но и любому клиенскому ПК в локальной сети.
    MCITP
    30 сентября 2011 г. 16:16
    Модератор
  • Ты неправильно понял - я об этом и говорю ;) .

    30 сентября 2011 г. 17:21
    Модератор
  • РЫть:
    - проверьте связь (ping) от ПК в локальной сети до внутреннего IP Lync Edge.
    Маршрут должен быть
    - проверьте то же самое с Front End сервера
    - проверьте доступность Edge из вышеуказанных мест до Lync Edge по требуемым для Edge портам
    Доступность по tcp портам можете проверить клиентом "telnet", udp - например "portqry".

    Попробуйте организовать аудио или аудио-видео конференцию (сообразить на троих ;) или через меню "Провести собрание" в Lync 2010) между двумя пользователями локальной сети и пригласить  третьего из сети Интернет.
    У третьего будет аудио\видео? Если да, то ищите проблему между ПК в локальной сети и Lync Edge.


    MCITP


    Правильно ли я понимаю?

    1. Ping fels.domain.local  Ok
    2. Ping edge.domain.local Ok
    3. telnet fels.domain.local 5061 Ok
    4. telnet edge.domain.local 5061 Ok
    5. tenet fels.domain.local 5062 Ok
    6. telnet edge.domain.local 5062 Ok
    7. telnet fels.domain.local 443 Ok
    8. tenet edge.domain.local 443 Ok
    9. telnet fels.domain.local 8057 Ok
    10. Telnet edge.domain.local 8057 ?
    11. portqry -n fels.domain.local -p UDP -r 3478 Ok
    12. portqry -n edge.domain.local -p UDP -r 3478 Ok
    13. portqry -n fels.domain.local -p UDP -r 50000-59999 Ok
    14. portqry -n edge.domain.local -p UDP -r 50000-59999 Ok

     

    3 октября 2011 г. 14:32
  • а кто такой 8057?

    3 октября 2011 г. 16:01
  • глубоко копаете :-)

    просто обычно внутри периметра так сильно не фильтруют

    3 октября 2011 г. 16:38
  • Обнаружил одну неприятность с безопастностью при заходе с наружи клиент не запрашивает авторизации, что позволяет подцепиться под любым именем в организации. Вопрос где может быть косяк в настройках.
     Сорее всего с этим связано и невозможность позвонить.
    • Изменено Morozov 4 октября 2011 г. 9:26
    4 октября 2011 г. 9:25
  • Мягко говоря, я вам не верю ;) ! Скорее всего, вы уже ранее заходили под данными пользователями и у вас просто есть соответствующие сертификаты аутентификации.
    4 октября 2011 г. 9:29
    Модератор
  • Магко выражаясь с одного и того же удаленного компьютера захожу под разными sip именами авторизацию не спрашивает. Где смотреть сертификат?
    • Изменено Morozov 4 октября 2011 г. 10:56
    4 октября 2011 г. 10:55
  • В стандартной MMC-консоли по управлению сертификатами (пользователя).

    P. S. Галочку "Сохранить пароль" не ставили?

    4 октября 2011 г. 10:56
    Модератор
  • Нет я даже пароля пользователя не знаю а захожу под его логином
    Пользовательских сертификатов нет.

    Может быть проблема что у меня один сертификат на все и на EDGE in и pub и FE?

    • Изменено Morozov 4 октября 2011 г. 11:01
    4 октября 2011 г. 10:59
  • Почему не спрашивает пароль, похоже разобрался, это связано с некорректной работой федерации, которая вызвана некорректными настройками EDGE сервера.

    Еще столкнулся со следующей проблемой при публикации веб компонентов Lync через TMG. Если делать как демонстрировали в ролике по установке EDGE и TMG у меня с наружи при заходе по адресу https://dialin.mycompany.ru выдается сообщение что страница не доступна хотя из нутри по томуже адесу на порт 4443 нормально заходит.

    Вторая проблема клиентом не могу подключится с наружи. Если взвожу галки  External Access Policy->Global->Enable communications with federated users и Access Edge Configuration->Global->Enamle federation->Send archiving duscaimer to federated partners то могу зайти с наружи клиентом под любой учетной записью без пароля единственное запрашивает пароль для синхронизации с Exchange адресной книгой для данной учетки.


    • Изменено Morozov 6 октября 2011 г. 7:45
    6 октября 2011 г. 7:39
  • Чего-то я не понимаю прикола - причём тут вход и федерация?

    Про TMG сложно что-то сказать не видя что и как вы сделали - скорее всего, где-то в правиле публикации ошибка.

    6 октября 2011 г. 8:35
    Модератор
  • Проблема скорее всего связана с тем что у меня два Front-end сервера которые в DNS посажены на одно имя, скорее всего что нужно сделать настройки Kerberos для авторизации. Но что то не смог найти как это сделать.




    • Изменено Morozov 6 октября 2011 г. 9:18
    6 октября 2011 г. 9:15
  • Может, для начала, вы подробно опишите свою инфраструктуру - какие сервера, какие редакции, что установлено, какие сетевые настройки, топология и так далее ;) ?
    6 октября 2011 г. 9:57
    Модератор
  • Не вопрос

    Операционки Windows 2008 R2 S1 Standart

    2 Front-end Сервера с Lync server 2010 Enterprise

    IP *.*.0.107,*.*.0.108 name fels01.domain.local fels02.domain.local pool01.domain.local

    1 Arhiving-Monitoring

    IP *.*.0.109 Name mas01.domain.local

    1 Edge

    IP *.*.0.101 Name con01.domain.local

    IP *.*.129.10 Name edge.domain.ru

    Это го достаточно? Ну центер сертификаци не Microsoft стороний ну думаю это не сильно важно.

     

    6 октября 2011 г. 11:08
  • Для начала, нормально :) .

    Я правильно понимаю, что Edge у вас является членом домена? У него два сетевых интерфейса, один из которых смотрит напрямую во внутреннюю сеть (без DMZ), а второй во внешний мир? Для чего вы добавляли маршрут "route -p 10.0.0.0 255.0.0.0 10.0.0.1"?

    Ваш пул как в DNS'е прописан? Две A-записи с IP-адресами Front End'ов?

    7 октября 2011 г. 9:17
    Модератор
  • Нет Edge не в домене а врабочей группе но одна из сетевых карт смотрит в серверную сеть, а втора в инет. Пул прописан pool01.domain.local *.*.0.107 и pool01.domain.local. *.*.0.108, на Edge на внутреней карточке прописаны внутрение DNS а на внешней на внешний DNS.

    7 октября 2011 г. 15:03
  • А рабочая сеть и серверная - у вас это разные вещи?

    Вы мне про добавление маршрута так и не ответили - он для чего ;) ?

    Внутреннее имя Edge'а у вас во внутреннем DNS'е прописано? Как?

    DNS-суффикс вашего домена вы на Edge'е прописали?

    Какой из его сетевых интерфейсов является "основным" (приоритетней)?

    Для чего вы так извратно поступаете с DNS'ом? Во-первых - он должен быть прописан только на одном интерфейсе, во-вторых - он должен быть либо внешним либо внутренним, чтоб избежать разных проблем и задержек. У вас внутренний DNS внешние имена разрешать умеет?

     

    P. S. Я уже как-то запутался - мы какую проблему решаем :) ?

    7 октября 2011 г. 15:10
    Модератор
  • Ну рабочая сеть это вообще не понятно что просто есть еще пользовательские и другие сети. Маршрут по умолчанию прописан на внешней карте а для внутреней добавлен через команду. Да внутрений умеет разрешать имена внешнего DNS, но вовнутренем присутствует зона стакимже именем как и во внешнем но они различаются :( 
    8 октября 2011 г. 2:20
  • Погодите, что значит в серверную сеть, действительно? У вас внутрення сеть клиентская и серверная отличаются? Если да, добавили ли вы маршруты статические для клиентский сетей? На Эдже должны быть прописаны маршруты всех подсетей внутренних, а не только серверной.



    • Изменено Brers 10 октября 2011 г. 7:29
    10 октября 2011 г. 7:25
  • Brers (Partner)  Считаю что вопрос не уместный. Но уточню сам EDGE находиться одной картой в инте другой в серверной сети. Из которой один шлюз вовнутреннию сеть, а там уже много пользовательских сетей так что шлюз один и я думаю что route -p 10.0.0.0 mask 255.0.0.0 10.0.0.1 покрывает все сети.
    10 октября 2011 г. 8:19
  • Прекрасно, если это так. Но ТС не упоминал находятся ли все его внутренние подсети в диапазоне 10.0.0.0\8.

    А учитывая, что у него всё же не работают звонки, считать вопрос неуместным неуместно.

    Не дана инфа и по прописанным суффиксам, о который упоминал и я и Stanky. А строить догадки причин неполадок по домыслам не очень правильно, не находите?

    10 октября 2011 г. 8:51
  • Да находяться. Суффикс используется domain.local

    10 октября 2011 г. 15:15
  • В копилку кому интересно. Было две проблемы

    1. Можно было из интернета подключится под любой записью которая есть в Lync не авторизуясь.
    2. Невозможно было организовать видео/аудио звонок с из интернет во внутр.

     

    1. Проблема была в том, что на EDGE на внутрений адрес был установлен "Универсальный сертификат" который содержал внутрение имена всех серверов из-за чего проходила сквозная авторизация через сертификаты. Мораль на EDGE на внутренем сертификате ни в коем случае не дожно быть не Direct серверов ни Standart ни Front-End.
    2. Вторая проблема была вызвана установкой одного EDGE сервера как мульти сервера. Видемо, что то было не корректно настроено. После того как в топологии было указано что EDGE один почти все стало работать. (Пока не неработает предоставление доступа к приложениям)

    • Помечено в качестве ответа Morozov 3 ноября 2011 г. 15:03
    • Изменено Morozov 3 ноября 2011 г. 15:09 исправление ошибок и добавление.
    3 ноября 2011 г. 15:03