none
Проблема сетевого доступа к WS2003-DC по некоторым протоколам. RRS feed

  • Вопрос

  •  

    Добрый день!

    в кратце - архитектура среды:

     

    2 физически распределенных подсети - 2.х, 3.х - объединены VLAN`ом 2го уровня провайдера - связаны через Cisco router 871 и WS2003 RRAS-LAN (дополнительный)

     

     

    Домен AD - уровень 2000 native.

     

    4 контроллера, распределенных между 2мя сайтами с высокоскоростным соединением, - репликация один раз в час. Глобальный каталог есть в каждом сайте, все FSMO-роли хранят контроллеры 1-го сайта.

     

    Каждый DC хранит AD-integrated зону, настроен WINS, в каждой подсети есть по одному DHCP-серверу для своей области. Суперобласть не сформирована.

     

    Шлюз в инет - машина с адресом 192.168.2.100

     

    Настройки машин следующие:

     

    Контроллеры в 1м сайте:

     

    {DC1.mydomain.ru

    WS2000

    ip: 192.168.2.5

    mask: 255.255.255.0

    gw: 192.168.2.100

    dns: 127.0.0.1; 192.168.2.7; inetaddr

    wins: 192.168.2.6

    suffix: mydomain.ru

    }

     

    {DC2.mydomain.ru

    WS2003

    ip: 192.168.2.7

    mask: 255.255.255.0

    gw: 192.168.2.100

    dns: 127.0.0.1; 192.168.2.5

    wins: 192.168.2.6

    suffix: mydomain.ru

    }

     

    контроллер во 2м сайте:

     

    {DC3.mydomain.ru

    WS2003

    ip: 192.168.3.5

    mask: 255.255.255.0

    gw: 192.168.3.1

    dns: 127.0.0.1; 192.168.2.5; forwarder=192.168.2.5

    wins: 192.168.3.6

    suffix=mydomain.ru

     

    }

    клиент(ы) в подсети 3.х

     

    {client.mydomain.ru

    XPsp2

    ip: 192.168.3.200

    mask:255.255.255.0

    gw:192.168.3.1

    dns: 192.168.3.5

    wins: 192.168.3.6

    suffix: mydomain.ru

    }

     

    Проблема в том, что клиенты из подсети 3.х не могут достучаться до DC2.mydomain.ru по NBIOS имени и по IP-адресу через SMB - в частности.

    после (банально) ввода через пуск-выполнить \\FQDN -имени сервера проблем при наборе плоского имени не возникает, в т.ч. и у коннекта Citrix-приложений - т.е. связь в кэше остается, до ребута.

     

    При этом - я могу добраться до сервера по ICMP, как по имени, - так и по IP - как до ввода FQDN так и после него.

    nbtstat -r показывает, что все имена разрешаются только через WINS. Броадкасты, на всякий случай на RRAS разрешены.

     

    У клиентов во 2й подсети подобных проблем не существует.

     

    Предполагал - что дело таится на циске - но RRAS эту проблему так же не решил.

    pathping до хоста в 3й подсети хоп-циску не затрагивает.

     

    Копал так же и в Default DC Policy - machine_policy\security - подписка SMB-траффика - но у DC1-то подобных глюков не наблюдается, - локальная политика на DC2 не задействована.

     

    Жупналы событий ничем критическо-подозрительным похвастаться не могут.

     

    Еще - DC2 был мигрирован из WS2000 - с adprep и всеми вытекающими.

     

    Что еще рассказать?)

     

    Есстественно - любой момент могу детализировать более подробно -

    всем заранее спасибо за ответ!

     

     

     

     

     

     

     

     

    5 ноября 2008 г. 13:54

Ответы

  •  

    Проблема разрешилась прописыванием суффиксов подключения и регистрацией их в соотв. dns.

    в подсети 2.х пробем не наблюдалось видимо благодаря широковещанию.

    15 ноября 2008 г. 8:42

Все ответы

  • ... добавилось уточнение

     

    так же относится и к http-траффику

     

    внутренний веб-сервер из подсети 2.х так же не доступен по IP из 3й подсети, если предварительно не разрешено его FQDN

    =)

     

    5 ноября 2008 г. 15:28
  • пока копаю в DNS - локальные настройки тут, видимо не при чем.

     

    Поменял у клиента из подсети 3.х адрес preffered dns на DC1.mydomain.ru из подсети 2.х - проблема с FQDN исчезла

     но не понимаю пока - в чем разница между двумя DNS с праймери зоной. Все записи ресурсов идентичные, с репликацией проблем нет .....

    7 ноября 2008 г. 7:26
  •  

    Проблема разрешилась прописыванием суффиксов подключения и регистрацией их в соотв. dns.

    в подсети 2.х пробем не наблюдалось видимо благодаря широковещанию.

    15 ноября 2008 г. 8:42