Tomsk Sysadmins Forum
Windows => Администрирование => Topic started by: Ghost Dog on April 29, 2006, 03:14:00
-
Здравствуйте, All.
На компе с Windows Server 2003 sp1 есть одна сетевая карта. Допустим, 10.0.5.2
Ну а у меня, допустим такой же 2003, 10.0.5.1
Пытаюсь удалённо настроить на сервере шлюз по умолчанию. Мог бы через mstsc, mmc конечно, но вопрос не в этом.
Меня заинтересовала утилита netsh, написано что может работать с удалёнными машинами.
Вот так мы с ней общаемся:
C:\Documents and Settings\Администратор.HOME>netsh -r 10.0.5.2
[10.0.5.2] netsh>int ip
[10.0.5.2] netsh interface ip>set ?
Применимы следующие команды:
Команды, наследуемые из контекста "netsh":
set file - Копирования с потока вывода консоли в файл.
set machine - Установление текущей машины, на которой выполняются операции.
set mode - Установление значения текущего режима.
[10.0.5.2] netsh interface ip>
По счастливой случайности на удалённой машине, как и на моей, есть пользователь Администратор с пустым паролем, поэтому логин успешный. Но изменить параметры интерфейса как видите нельзя.
Для сравнения, локально всё выглядит так:
netsh>int ip
netsh interface ip>set ?
Применимы следующие команды:
Команды, наследуемые из контекста "netsh":
set file - Копирования с потока вывода консоли в файл.
set machine - Установление текущей машины, на которой выполняются операции.
set mode - Установление значения текущего режима.
Команды в этом контексте:
set address - Установка указанному интерфейсу IP-адреса или основного шлюза.
set dns - Установка режима DNS-сервера и адресов.
set wins - Установка режима WINS-сервера и адресов.
netsh interface ip>
То есть можно написать например netsh set address итд.
В справке MS упоминания о таком поведении не нашёл, в гугле тоже.
Подскажите чего-нибудь, пожалуйста.
-
По моему скромному мнению существует единственный корректный и широкоиспользуемый способ удалённой настройки сетевого интерфейса: DHCP. Всё остальное будет работать криво по той простой причине, что применение новых параметров сетевого подключения неизбежно ведёт к разрыву всех существующих сеансов связи. Будь то терминал или RPC... Из-за этого процесс конфигурирования не сможет завершиться корректно.
В общем, не зря Майкрософт выключил эту опцию для удалённых машин.
-
То есть это всё-таки специально? Я подумал, может я что-то неправильно делаю..
Может и не зря (что-то вроде защиты от дурака), а может и зря.
Допустим, у меня были клиенты со статической конфигурацией, а я захотел их всех на dhcp перевести. Ну опять-таки разные варианты есть, но я бы не отказался от возможности простым скриптом со своей машины попросить их всех перейти на dhcp. Или всем настройки файервола встроенного изменить (тоже нельзя).
применение новых параметров сетевого подключения неизбежно ведёт к разрыву всех существующих сеансов связи.
Ну конечно, если я ip-адрес поменяю, да чтобы ещё он из другой подсети был, тогда соединение разорвётся. Но (для примера) шлюз по умолчанию я через mstsc поменял и никаких проблем.
Из-за этого процесс конфигурирования не сможет завершиться корректно.
Опять таки, даже если изменения которые я попрошу, приведут к разрыву соединения, что мешает удалённой машине применить их? Ничего. Пусть запомнит изменения в буфер, разорвёт соединеие и применит их. А потом я по новому адресу заново соединюсь.
-
Допустим, у меня были клиенты со статической конфигурацией, а я захотел их всех на dhcp перевести. Ну опять-таки разные варианты есть, но я бы не отказался от возможности простым скриптом со своей машины попросить их всех перейти на dhcp.
По поводу удалённого перевода на DHCP можно здесь прочитать:
http://support.microsoft.com/kb/194407/en-us (http://support.microsoft.com/kb/194407/en-us)
Или всем настройки файервола встроенного изменить (тоже нельзя).
Настройки файрволла обычно меняются групповыми политиками.
Ну конечно, если я ip-адрес поменяю, да чтобы ещё он из другой подсети был, тогда соединение разорвётся. Но (для примера) шлюз по умолчанию я через mstsc поменял и никаких проблем.
Опять таки, даже если изменения которые я попрошу, приведут к разрыву соединения, что мешает удалённой машине применить их? Ничего. Пусть запомнит изменения в буфер, разорвёт соединеие и применит их. А потом я по новому адресу заново соединюсь.
Всё конечно можно сделать. Но ИМХО, настраивать сетевой интерфейс удалённо, соединившись через него же - это всё равно что пилить сук, на котором сидишь.
-
Спасибо за ссылку, я этого не знал.
Раз уж речь зашла о способах администрирования, связанных с исправлением реестра: во-первых надо знать все эти ключи. Иногда MS их публикует, но но эта например статья (как в ней написано) относится к NT-2000, а про XP и 2003 молчок. То есть если работает - хорошо, если нет - "Microsoft cannot guarantee...".
Во-вторых, как написать скрипт, удалённо исправляющий реестр? Могу предложить (самому себе :)) использовать утилиту reg.exe - она может подключаться к удалённому реестру, посылать запросы и вносить изменения. Но она не может элементарного - указать учётную запись, под которой произойдёт подключение. То есть надо, например, иметь локально все те учётные записи, под которыми будешь подключаться в скрипте использовать runas, или запомнить их в "сохранение имен пользователей и паролей".
В-третьих, вообще поощрять прямое редактирование базы данных (которой является реестр) кажется мне ошибкой дизайна Windows. Надо же предоставить набор функций типа netsh, которые сами всё в реестре поправят.
Конечно, есть нормальное, мощное средство администрирования AD. А всё остальное глупости.
Но принцип действия домена в том, что удалённый компьютер при аутентификации сам скачивает все политики, скрипты итд и локально их применяет. А я ищу в Windows инструмент, не требующий инициативы от удалённого компьютера. Зря что ли 135 порт epmap открыт?
ИМХО, настраивать сетевой интерфейс удалённо, соединившись через него же - это всё равно что пилить сук, на котором сидишь.
Ну да, согласен :)
Ну а если не тот же интерфейс, а другой? Соседний сук?
-
Оказывается, я забыл про один источник информации по Windows и скриптам, в том числе удалённым.
MS Script Center http://www.microsoft.com/technet/scriptcenter/learnit.mspx (http://www.microsoft.com/technet/scriptcenter/learnit.mspx)
Пошёл читать, спасибо за внимание.