С нового винграда на старом месс тупо не отображается. Смотрю там, отвечаю тут.


Да почти везде.


Ошибка. Даже две. На каждом из интефейсов. Итого четыре.
1, 2) Интерфейс не может быть сам себе шлюзом.
3, 4) Шлюз в описанной ситуации вообще нахрен не нужен.

И общая ошибка.
5) Дефолтных шлюзов не должно быть более одного.


Ошибка. На каждом из интерфейсов. Итого ещё две.
6, 7) Маршрут в подсеть интерфейса не требуется.

Как лечить:

1) Выключить RRAS.
2) Убрать шлюзы из настроек интерфейсов.
3) Запустить мастер настройки сервера, выбрать роль маршрутизатора ЛВС.
4) На все вопросы отвечать "Да", и НИЧЕГО не менять в настройках по дефолту.
5) Перегрузить сервер.
6) На рабстанциях удалить маршруты в СВОЮ подсеть, но добавить в УДАЛЁННУЮ черз шлюз в СВОЕЙ.

А если требуется аналогичным образом соединить сеть класса С с сетью класса В, т.е. у сети NETNEW параметры: IP: 192.168.20.X, SM: 255.255.0.0, все вышеописанные действия аналогичны?

Классы сетей не существуют. Забудь это слово.

А вот у сети NETNEW указанных тобой параметров быть не должно - эти приведут к общей ошибке адресации. И куче неизлечимых проблем.

Какие тогда должны быть параметры у сети NETNEW с целью достижения количества хостов порядка нескольких тысяч?

Правильные.
Например, использовать 172.16/16. Или там 10.0/16.
Или хотя бы 192.168.128/17 - не очень хорошо, но можно.
А вот 192.168.20/16 - это ошибка. неверный адрес сети. Ненулевые биты адреса в нулевых битах маски.

А если испльзовать IP: 192.168.20.X SM: 255.255.240.0

192.168.020.000 = 11000000 10101000 00010100 00000000
255.255.255.240 = 11111111 11111111 11110000 00000000
Ещё вопросы есть?

Может ;)
Попробуй соединить напрямую 2 компа с разными подсетями и прописать у каждого в качестве шлюза самого себя и попробуй попинговать друг друга - удивишься   
Ну а потом попробуй объяснить как это все работает 

_zorn_, если у тебя работает, то это следствие каких-то особенностей реализации, а не соответствие стандарту. 
Только что две соединённых кроссом ХР-шки настроил, одну 172.16.0.1/24, другую 172.16.1.1/24, и каждая сама себе шлюз. Попробовал "попинговать друг друга" - вполне ожидаемый "Превышен интервал ожидания для запроса.". Стоит же их свести в одну подсеть - пакетики полетели. Фаер есссно выключил.

 
Есть, уважаемый советчик, до сих пор Вы были правы. Ситуацию с ненулевыми битами адреса я понял. И теперь вынужден разъяснить полностью мою проблему. Сеть NETOLD с параметрами IP: 192.168.0.X SM: 255.255.255.0 представляет собой клиент-серверную сеть (домен) со статической IP-адресацией. Когда сеть создавалась, как уже понятно, она создавалась как сеть типа SOHO, никто не мог тогда предположить, что в ней будет больше 254 хостов. Однако в результате структурных изменений в организации, потребовалось гораздо большее количество IP-адресов. Т.к. адресация статическая, то изменить маску сразу у всех рабочих станций домена не получится. Изменять уже имеющиеся IP-адреса тоже нельзя т.к. они прописаны в DNS. Единственным способом, насколько я в данном случае понимаю, является изменение маски подсети на всех серверах и рабочих станциях домена, для "расширения" диапазона используемых IP-адресов. Ответьте пожалуйста, правильное ли это решение и какую в данном случае следует использовать маску подсети? 

Да не вопрос. Расширяйте. Только, начиная с некоторого момента, у вас поползёт адрес сети.

192.168.20/24
192.168.20/23
192.168.20/22
192.168.16/21
192.168.16/20
192.168.0/19
...
192.168.0/16

Компам по барабану, а вот при прописывании маршрутов это необходимо учитывать.
Ну и учтите, что на время смены масок у тех, кто сменил маску, и у тех, кто не сменил, могут возникнуть определённые проблемы. Вплоть до отсутствия доступа и даже видимости в сетеовм окружении.
Опять же учтите, что домен весьма болезненно относится к изменению адресации. А если там вертятся какие-то серверы (ну, к примеру, МS SQL), то и они не заколотятся от счастья. Могут протухнуть некоторые сертификаты... и тыды, и тыпы...
Так что чеклист на смену адресов и масок для каждого сервера будет о-о-очень длинным.

PS. Я бы на самом деле делал это в несколько этапов. И первым поставил бы перевод со статики на ДЦХП, оставаясь в той же подсети. Это нужно будет сделать одним скачком, причём изменение настроек сетевой подсистемы вполне можно выполнить и доменным логон-скриптом. А дальше уже можно просто играть адресами скопов и передаваемыми параметрами (вроде времени аренды), расширяя подсеть до требуемого размера.

Про проблемы я догадываюсь, особеммно меня беспокоит вопрос о том смогут ли пользователи домена нормально логиниться после смены маски или потребуется заново проводить сетевую идентификацию каждого пользователя, правда на некоторых форумах утверждается, что здесь ничего страшного быть не должно. Временным отсутствием доступа и потерей сетевого окружения можно пренебречь. Переход на динамическую адресацию пока не возможен по ряду причин. Но из Вашего ответа я так и не понял какую всетаки целесообразнее выбрать новую маску подсети при уже имеющихся IP: 192.168.0.0-255, для увеличения количества подключаемых хостов?

Это сообщение отредактировал(а) evgvagin - 3.10.2013, 12:35

идентификация как станции, так и пользователя выполняется по его SID, на который ИП не влияет. А вот сертификаты могут стать невалидными - если используется, скажем, VPN или HTTPS, сертификаты придётся перевыпустить.


Если надо захватить хосты подсети 192.168.20/24, и хочется иметь адрес подсети 192.168.0.0, маска должна быть не уже, чем /19, и не шире, чем /16. Одна из четырёх, любая. Шире нельзя - налезет на белый диапазон. Уже нельзя - не захватит адреса.

 Но префикс /16 как раз и соответствует маске 255.255.0.0, или это относится применительно к маршрутизации.

Да, префикс обозначает имено такую подсеть. Однако процитированные тобой слова - вот о такой нестыковке. На /16 она тоже распространяется в полный рост.

Но у меня параметры IP: 192.168.20.X, SM: 255.255.240.0 Уважаемый советчник Вы не ошиблись???

Да пожалуйста... Работать - будет. Однако неминуемы и проблемы, в основном в форме наличия доступа там, где его не должно быть, и наоборот. Их можно и не увидеть. А можно вляпаться обеими ногами.

Уважаемый советчик я все делал по Вашему алгоритму, в результате получается вот, что:

1) Настроил маршрутизатор назовем его MSERVER с параметрами интерфейсов:
NETOLD: IP: 192.168.0.126, SM: 255.255.255.0 Gat: отсутствует
NETNEW: IP: 192.168.20.1, SM: 255.255.255.0 Gat: отсутствует
2) Один из ПК в сети NETNEW (user45) настроил с параметрами:
IP: 192.168.20.2, SM: 255.255.255.0 Gat: 192.168.20.1
3) На нескольких ПК в сети NETOLD прописал шлюз Gat: 192.168.0.126

В результате: все компьютеры с прописанными шлюзами из обоих сетей нормально пингуют друг друга, а также подключаются к удаленному рабочему столу, но в сетевом окружении друг друга не видят. Компьютер user45 видет в сетевом окружении только маршрутизатор MSERVER и больше ничего, и подключится к домену NETOLD, также не может. В чем может быть причина, исправима ли данная ситуация?

Что в общем ожидаемо. Вариантов решения как минимум два. 

Первый, наиболее простой - тупо прописываем привязки ВСЕХ компьютеров поадресно в LMHOSTS, и распространяем полученный файл. Видимости, может, и не прибавится, но доступ по именам точно появится. Распространение можно привязать на старт компьютера - просто забирать актуальную копию с сервера. Некрасиво, но работать может.

Второй,  более правильный - на контроллере домена поднимаем WINS-сервер, и делаем соотв. настройки на станциях.


Первое нормально (см. выше), второе странно... подробнее. Какие сообщения идут на консоль? в журналы (и станции, и контроллера)? Не блочит ли что маршрутизаторовский файрвол?

WINS-сервер необходимо прописать в сетевых интерфейсах ПК в обоих сетях (NETOLD и NETNEW)?



Журналы пока не смотрел, но при проведении сетевой идентификации ПК user45 выдается сообщение об отсутсвии домена с указанным именем. Брандмауэр на маршрутизаторе MSERVER отключен, правда народ на форумах утверждает, что если виндовый брандмауэр отключен, то это не значит, что он не может поднасрать. Но более подробных комментариев по этому поводу я не нашел.
Кстати Уважаемый советчик, а не проще ли в таком случае использовать, для маршрутизации в данном случае, аппаратный роутер. И если да, то какой модели?


Это сообщение отредактировал(а) evgvagin - 8.10.2013, 18:19

Уважаемый Akina, после настройки WINS на сетевом адаптере ПК user45, из сети NETNEW, на нем полностью появилось сетевое окружение сети NETOLD (домен kui), причем в нем есть все ПК не зависимо от прописанного шлюза и WINS. Но прописать ПК user45 в домен kui сети NETOLD по прежнему не получается. Сетевые параметры user45: 
IP: 192.168.20.2, SM: 255.255.255.0 Gat: 192.168.20.1 DNS: 192.168.0.240
DNS для домена kui сети NETOLD.
Запись ошибки при попытке подключения:

Вероятно, доменное имя "KUI" является NetBIOS-именем домена. Проверьте, что имя домена правильно зарегистрировано в WINS.

Если вы убеждены, что это имя не является NetBIOS-именем домена, то следующая информация поможет в исправлении ошибки в конфигурации DNS вашей сети.

При запросе DNS записи ресурса размещения службы (SRV), используемой для выяснения размещения контроллера домена для домена "KUI" произошла ошибка:

Произошла ошибка: "Ошибка DNS-сервера."
(код ошибки: 0x0000232A RCODE_SERVER_FAILURE)

Опрос проводился для SRV-записи для _ldap._tcp.dc._msdcs.KUI

К возможным причинам ошибки относятся:

1. DNS-серверы, используемые этим компьютером содержат неправильные корневые ссылки. Этот компьютер настроен на использование DNS-серверов со следующими IP-адресами:

192.168.0.240


2. В одной или в нескольких зонах из указанных ниже содержится неверное делегирование:

KUI
. (корневая зона)

Для получения сведений об исправлении этой ошибки щелкните кнопку "Справка".

Что здесь необходимо предпринять?

И еще, все таки не целесообразнее ли будет в данном случае использовать физический маршрутизатор? 

Моя стихия - это eDir, а не AD... но наличие на контроллере домена корневой зоны свидетельствует о замкнутости системы... это так?

Да

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

Вы имеете в виду при настройке подключения к домену? А все таки как с вопросом   :И еще, все таки не целесообразнее ли будет в данном случае использовать физический маршрутизатор?  

evgvagin, я думаю, что физический маршрутизатор не изменит наблюдаемой картины. А если изменит - то это будут претензии к настройке программного маршрутизатора, а не к нему самому.