none
EDGE: правильная топология с одним пулом и большим количеством небольших офисов соединенных по IPSec RRS feed

  • Общие обсуждения

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

    Есть существующая топология:

    какой-то большой офис A, скажем Москва.

    какой небольшой офис B, скажем Сыктывкар.

    С точки зрения AD - это два сайта с разными внутренними подсетями (скажем 10.A.x.x и 10.B.x.x).

    C точки зрения топологии LYNC: один стандартный пул, с mediation и edge установленным в офисе А.

    Внутренние звонки (офис А и офис B) работают напрямую между клиентами. Lync клиенты в обоих офисах считают себя internal (они "отрезолвили" internal записи в DNS).

    Звонки между remote worker-ом и сотрудником в офисе А идут через EDGE. Lync-клиент в офисе интерпретируется как internal, клиент снаружи определил edge сервер через внешние DNS записи и интерпретировался как external (используем DNS splitting).

    Звонки между remote worker-ами работают в зависимости как отработает STUN\TURN: звонок либо установится напрямую, либо EDGE будет релеить трафик обоих клиентов.

    Проблема в следующем: Lync-клиент в офисе B также делает свои вызовы через EDGE в сторону любого remote worker-а. Хотя, возможно, это не будет оптимальным маршрутом: remote worker может сидеть в том же Сыктывкаре, но дома. Но трафик пойдет до EDGE в офисе A (в Москве), а потом с EDGE отправится в сторону remote worker, который может также сидеть в Сыктывкаре. И вместо 10ms получим 200ms. Хотелось бы, чтобы соединение устанавливалось напрямую (интернет из офиса B разрешен). А так похоже получается, что Lync-клиент видя что он internal лезет к EDGE серверу на внутренний интерфейс и в качестве кандидата при установлении сессии с внешним Lync-клиентом подставляет внешний (public) IP EDGE сервера.
    Что исправить в топологии или дизайне?

    Николай.

    16 марта 2015 г. 12:03