none
обьединение нескольких сетей RRS feed

  • Вопрос

  • Здрасьте.
    Вопрос в следующем, требуется обьединить несколько филиалов между собой.
    В каждом филиале порядка 3-5 ПК, которые работают с собственным ПО. после присоединения к другой сети работают с другим.
    Как все это дело качественнее организовать?
    Терминал? VPN?
    16 июля 2008 г. 5:08

Все ответы

  • В каких целях нужно объединение?Предоставление полноценного доступа ко всем сервисам из одной сети к другой (или объединение сервисов) или же доступ к одной-двум программам?

    в первом случае действительно логичнее использовать VPN. Во втором - терминал

    Если же требуется просто обмен какими-либо данными, то можно обойтись типовой маршрутизацией

    16 июля 2008 г. 5:49
  •  dmirk написано:

    В каких целях нужно объединение?Предоставление полноценного доступа ко всем сервисам из одной сети к другой (или объединение сервисов) или же доступ к одной-двум программам?

    в первом случае действительно логичнее использовать VPN. Во втором - терминал

    Если же требуется просто обмен какими-либо данными, то можно обойтись типовой маршрутизацией



    требуется доступ к одной, двум прорраммам...
    16 июля 2008 г. 6:31
  • Тогда можно обойтись терминалом (не забывая про шифрование)

    В случае с VPN задача шифрования данных отпадает (точнее она просто перекладывается на VPN Smile)

    16 июля 2008 г. 8:25
  •  

    А как правильно поступить, если при этом в центральном офисе есть AD?

    Цель объединения - работа с корпоративными ресурсами и создание единго информационного пространства.

    Между филиалами VPN IPSec через ISA 2006

    18 июля 2008 г. 16:48
  • А как правильно поступить, если при этом в центральном офисе есть AD?

    Цель объединения - работа с корпоративными ресурсами и создание единго информационного пространства.

    Между филиалами VPN IPSec через ISA 2006

     

    Не совсем понятно в чем вопрос. Схема разворачивания AD зависит от многих факторов (административных, организационных, от количества пользователей в офисах, от типов предоставляемых сервисов, от каналов связи и т.п.). В зависимости от этого и надо решать ставить ли в каждом офисе контроллер имеющегося в центральном офисе домена, либо разворачивать новые домены (в новом или имеющемся лесу с последующей настройкой доверительных отношений (при необходимости)),либо проводить аутентификацию пользователей напрямую в центральном офисе. Хотя межсайтовый трафик AD по умолчанию сжимается и шифруется, использование VPN наиболее надёжное и "классическое" решение

    19 июля 2008 г. 9:23
  •  dmirk написано:

    А как правильно поступить, если при этом в центральном офисе есть AD?

    Цель объединения - работа с корпоративными ресурсами и создание единго информационного пространства.

    Между филиалами VPN IPSec через ISA 2006

     

    Не совсем понятно в чем вопрос. Схема разворачивания AD зависит от многих факторов (административных, организационных, от количества пользователей в офисах, от типов предоставляемых сервисов, от каналов связи и т.п.). В зависимости от этого и надо решать ставить ли в каждом офисе контроллер имеющегося в центральном офисе домена, либо разворачивать новые домены (в новом или имеющемся лесу с последующей настройкой доверительных отношений (при необходимости)),либо проводить аутентификацию пользователей напрямую в центральном офисе. Хотя межсайтовый трафик AD по умолчанию сжимается и шифруется, использование VPN наиболее надёжное и "классическое" решение

    Ситуация следующая:

    ЦО - AD, DHCP, ISA, Сервер приложений. 60 раб мест

    УО - Есть сервер, но функциональность еще не поределена (ISA, DNS, DHCP), 20 раб мест.

    Цель - построить единое прозрачное и в тоже время надежное информационное пространство между офисами. Пользователи должны иметь доступ к серверу приложений, независимо от места полодения. УО желательно управлять GP из ЦО.

    Можно ли при таком раскладе обойтись без AD  в УО?

    19 июля 2008 г. 20:53
  • Цель - построить единое прозрачное и в тоже время надежное информационное пространство между офисами. Пользователи должны иметь доступ к серверу приложений, независимо от места полодения. УО желательно управлять GP из ЦО.

    Можно ли при таком раскладе обойтись без AD  в УО?



    >>УО желательно управлять GP из ЦО.
    Каким образом это вы сделаете без доменной структуры? Wink

    >>Можно ли при таком раскладе обойтись без AD  в УО?
    В целом обойтись конечно же можно(если не учитывать предыдущий вопрос). Но одна из основных обязанностей AD - авторизация и аутентификация. Т.е. наиболее надёжный способ предоставления доступа к ресурсам только авторизованным пользователям - AD. Иначе придётся либо делать доступ для анонимных пользователей, либо дублировать учетные записи



    22 июля 2008 г. 9:42
  • Можно обойтись без контроллера домена в удаленных офисах.

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

    При обрыве канала связи пользователи не смогут получит доступ к ресурсам расположенным на других компьютерах (хотя это ограничение можно обойти).

     

    В целом ставить контроллер домена в офис меньше 50 человек обычно не целесообразно, если существуют надежные каналы связи, хотя бы 64К, и отсутвуют сервисы, которые требуют AD (например Exchange).

     

     

     

     

    22 июля 2008 г. 10:21
    Модератор
  • В целом ставить контроллер домена в офис меньше 50 человек обычно не целесообразно, если существуют надежные каналы связи, хотя бы 64К, и отсутвуют сервисы, которые требуют AD (например Exchange).

     


    В теории - да. На практике - нет. На 64К время логона одного пользователя составит минуту-две (в зависимости от того, логинился ли он уже на эту машину). Если же логиниться будут все 50 пользователей (например утром) - это забьёт канал и логон будет происходить оочень долго. Плюс не стоит забывать про периодическое обновление билетов Kerberos и про прочие обязательные обращения к контроллерам (например для синхронизации времени и фонового обновления GP). Другими словами, работать на такой скорости (без установки локального контроллера в сайте) невозможно.

    22 июля 2008 г. 10:55
  • 64К это расчетная величина базирующаяся на том, что 50 пользоватлей будут логиниться в пределах интервала 15мин. Размеры групповых политик конечно усреднены.

     

    Безусловно логон будет происходить немного дольше, но незначительно.

     

    22 июля 2008 г. 13:45
    Модератор
  • http://www.microsoft.com/downloads/details.aspx?FamilyID=9353a4f6-a8a8-40bb-9fa7-3a95c9540112&DisplayLang=en#filelist

     

    документ: Planning the Physical Structure for a Branch Office Deployment

     

    Были правда руководства и получше, но сейчас найти не успеваю.

    22 июля 2008 г. 14:14
    Модератор
  • Зачитано "до дыр" Smile

    Аналогичное руководство по Win 2008 гораздо полнее и там даже есть таблицы для обсуждаемых случаев (зависимость от количества пользователей, ширины канала, сервисов и т.п.). Да и у Зубанова есть неплохая книга на данную тему. Но, повторюсь, это только теория Sad

    22 июля 2008 г. 14:57
  •  dmirk написано:

    Цель - построить единое прозрачное и в тоже время надежное информационное пространство между офисами. Пользователи должны иметь доступ к серверу приложений, независимо от места полодения. УО желательно управлять GP из ЦО.

    Можно ли при таком раскладе обойтись без AD  в УО?



    >>УО желательно управлять GP из ЦО.
    Каким образом это вы сделаете без доменной структуры?

    >>Можно ли при таком раскладе обойтись без AD  в УО?
    В целом обойтись конечно же можно(если не учитывать предыдущий вопрос). Но одна из основных обязанностей AD - авторизация и аутентификация. Т.е. наиболее надёжный способ предоставления доступа к ресурсам только авторизованным пользователям - AD. Иначе придётся либо делать доступ для анонимных пользователей, либо дублировать учетные записи



    AD есть, но в ЦО. Я так понимаю VPN site2site - штука прозрачная для рабочей станции...

    22 июля 2008 г. 18:11
  •  dmirk написано:

    В целом ставить контроллер домена в офис меньше 50 человек обычно не целесообразно, если существуют надежные каналы связи, хотя бы 64К, и отсутвуют сервисы, которые требуют AD (например Exchange).

     


    В теории - да. На практике - нет. На 64К время логона одного пользователя составит минуту-две (в зависимости от того, логинился ли он уже на эту машину). Если же логиниться будут все 50 пользователей (например утром) - это забьёт канал и логон будет происходить оочень долго. Плюс не стоит забывать про периодическое обновление билетов Kerberos и про прочие обязательные обращения к контроллерам (например для синхронизации времени и фонового обновления GP). Другими словами, работать на такой скорости (без установки локального контроллера в сайте) невозможно.

     

    Господа, господа!!!

    Но ведь речь идет о всего 11 человеках. Смогут они нормально рабоать?

    Скорость Интернет канала - 2 Мб/с. Скорость ВПН канала не мерили, но могу сказать, что оператор один - работает все в принципе нормально.

    22 июля 2008 г. 18:19
  • В принципе на сегодня шесть пользователей работают нормально, но компьютеры из УО не видят компы в ЦО (ИСА блокирует Сеансы NetBios, хотя правило разрешаюшее данный трафик создано).

     

    22 июля 2008 г. 18:24
  • При вашем канале и количестве пользователей можно обойтись без DC. Если канал не только широкий, но и постоянный (без частых сбоев). Насчет Netbios: как именно они их не видят?В сетевом окружении или нет доступа до имени? В первом случае надо настраивать Computer Browser, во втором - Wins (либо разрешать пропускать бродкасты, что не есть гуд)

    23 июля 2008 г. 5:32
  •  dmirk написано:

    При вашем канале и количестве пользователей можно обойтись без DC. Если канал не только широкий, но и постоянный (без частых сбоев). Насчет Netbios: как именно они их не видят?В сетевом окружении или нет доступа до имени? В первом случае надо настраивать Computer Browser, во втором - Wins (либо разрешать пропускать бродкасты, что не есть гуд)

    Не видячт в окружении.

    По IP-запросы проходят и даже сетевые диски цепляются.

    Как настроить Computer Browser?

     

    А как открыть бродкасты? Почему не гуд?

    23 июля 2008 г. 9:17
  • "Не гуд" потому что это приведёт к излишнему шуму в сети.

    О Computer Browser очень подробно рассказано тут

    23 июля 2008 г. 15:18
  •  dmirk написано:

    "Не гуд" потому что это приведёт к излишнему шуму в сети.

    О Computer Browser очень подробно рассказано тут

    Получается, что мне надо просто поднять в ЦО Wins сервер?

    23 июля 2008 г. 16:58
  • ..и в УО,для экономии трафика. После чего настроить репликацию этих двух WINS-серверов.

    Либо просто на клиентских местах в УО в качестве WINS указать WINS-сервер ЦО (т.к. канал широкий)

    23 июля 2008 г. 17:01
  •  dmirk написано:

    ..и в УО,для экономии трафика. После чего настроить репликацию этих двух WINS-серверов.

    Либо просто на клиентских местах в УО в качестве WINS указать WINS-сервер ЦО (т.к. канал широкий)

     

    Я на клиентских машинах прописал винс из ЦО.

    Но тем не менее сама ИСА не может войти в домен - самаже блокирует свои запросы нетбиос.

    23 июля 2008 г. 18:57