Управление сетями Windows с помощью сценариев. Часть 8. Устранение неполадок с удаленными сценариями с помощью Network Monitor 3.0
Опубликовано: 23 Марта, 2023
Управление сетями Windows с помощью скриптов. Часть 10. Приемы удаленного скриптинга
Управление сетями Windows с помощью сценариев. Часть 11. Дополнительные приемы работы со сценариями
Управление сетями Windows с помощью сценариев. Часть 12. Свойства класса WMI
Управление сетями Windows с помощью сценариев. Часть 13. Удобный сценарий возврата всех значений
Управление сетями Windows с помощью сценариев. Часть 14. Дополнительные сведения о сценариях WMI
В предыдущей статье этой серии мы приступили к устранению загадочной ошибки, возникшей при попытке удаленного изменения IP-адреса на компьютере с XP с помощью разработанного нами ранее сценария ChangeIPAddress.vbs. Таинственная ошибка, которая произошла, была следующей:
SWbemObjectEx: Ошибка удаленного вызова процедуры
В предыдущей статье я упомянул, что связался с некоторыми гуру сценариев по поводу этой ошибки, и «лучший ответ», который я получил, заключался в том, что исправление, вероятно, нарушило функциональность WMI, и в результате этот сценарий работал удаленно, но выдавал ошибку.
Оформите предзаказ на копию Microsoft Windows Vista Resource Kit уже сегодня!
Но впоследствии со мной связался проницательный читатель со следующим комментарием:
На мой взгляд, это не ошибка ни в одном исправлении. Помните, что вы меняете IP-адрес xp2. Удаленный вызов процедуры завершился неудачно из-за потери соединения с xp2 по исходному IP-адресу (172.16.11.43). Затем он тратит несколько раз (около 1 минуты) на поиск xp2 на новом IP-адресе (172.16.11.65), прежде чем сдается.
Представьте, что вы просто подключаетесь к серверу с правами администратора и меняете IP-адрес сервера. Вы потеряете связь? Он будет висеть некоторое время, и это то же самое. Но изменение шлюза по умолчанию на сервере не прервет существующее (telnet) соединение (при условии, что вы делаете это из той же подсети). Если вы попытаетесь изменить настройку шлюза по умолчанию с удаленного сайта, вы должны столкнуться с такой же задержкой.
Хорошая точка зрения! Как мы можем проверить это объяснение?
Использование сетевого монитора 3.0
Microsoft недавно выпустила новую версию Network Monitor, инструмента для перехвата пакетов, входящего в состав Microsoft Systems Management Server. Сетевой монитор 3.0 имеет несколько улучшений по сравнению с предыдущей версией этого инструмента, а именно:
Новый, улучшенный пользовательский интерфейс, отображающий кадры во время их захвата в режиме реального времени.
Несколько одновременных сеансов захвата и одновременный захват на нескольких сетевых адаптерах.
Возможность отображать сетевые «разговоры», т. е. сеансы по определенному протоколу.
Поддержка Vista, Windows XP и Windows Server 2003, включая 32-битные и 64-битные платформы.
Новая панель фильтрации, позволяющая вручную задавать фильтры.
Дополнительные сведения о Network Monitor 3.0 см. в блоге Пола Лонга на TechNet.
Тогда вот мой план. Я собираюсь использовать NM3 для захвата сетевой трассировки с машины, на которой я запускаю сценарий ChangeIPAddress.vbs. Моя тестовая установка для этого выглядит следующим образом:
Рабочая станция администратора Имя: test124.test.com IP-адрес: 172.16.11.124 (статический)
Целевая машина Имя: test125.test.com IP-адрес: 172.16.11.125 (статический)
Но прежде чем я попытаюсь запустить ChangeIPAddress.vbs на test124, чтобы изменить IP-адрес test125, давайте быстро взглянем на NM3.
Когда вы запускаете NM3, это выглядит так (рисунок 1):
Рис. 1. Начальный экран Network Monitor 3.0 (щелкните, чтобы увеличить изображение)
Прежде чем мы пойдем дальше, давайте установим флажок «Включить диалоги», чтобы мы могли просматривать каждый тип сеанса протокола, который происходит во время нашей трассировки.
Теперь нажмите «Создать новую вкладку захвата». Откроется новая вкладка с именем Capture1, которую мы можем использовать для создания трассировки сети (рис. 2):
Рис. 2. Открытие новой вкладки захвата (щелкните, чтобы увеличить изображение)
Теперь давайте протестируем NM3 на чем-нибудь простом. Мы нажмем кнопку Play, чтобы начать захват, а затем с машины test124 откроем командную строку и наберем ping 172.16.11.125, т.е. мы пингуем test125 с test124. Результат такой (Рисунок 3):
Рис. 3. Трассировка проверки связи 172.16.11.125 (щелкните, чтобы увеличить изображение)
Это как раз то, что мы ожидаем: два пакета ARP (запрос ARP, за которым следует ответ ARP), а затем серия пакетов ICMP (сообщения Echo Request, за которыми следуют сообщения Echo Reply). Если вы знакомы с основами работы с сетями TCP/IP, это будет легко понять.
Давайте посмотрим на «разговоры», которые произошли. Разверните узел My Traffic, чтобы отобразить их (рис. 4):
Рис. 4. Отображение диалогов (щелкните, чтобы увеличить изображение)
Обратите внимание, что произошли два диалога: ARP и IPv4 (ICMP). Опять же, это должно быть довольно очевидно, если вы знакомы с основами сетей TCP/IP.
Давайте теперь выберем пакет запроса ARP и заглянем внутрь него (рисунок 5):
Рис. 5. Изучение пакета (щелкните, чтобы увеличить изображение)
Теперь, когда у нас есть краткое введение в NM3 (есть еще много всего!), давайте попробуем использовать его для устранения нашей загадочной ошибки.
Захват следов
Я начну с перезагрузки обеих рабочих станций, чтобы очистить все кеши (ARP, DNS и т. д.), а затем открою командную строку на test124 и наберу ChangeIPAddress.vbs 172.16.11.144, чтобы изменить IP-адрес test125 с 172.16.11.125. на 172.16.11.144. (В этом скрипте я жестко запрограммировал целевой компьютер как «test125».) Вот результат (рис. 6):
Рис. 6. Результат запуска ChangeIPAddress.vbs 172.16.11.144 (щелкните, чтобы увеличить изображение)
Вот обзор того, что произошло. Захват длился в общей сложности почти 90 секунд, всего было отснято 274 кадра. Сообщение об ошибке появилось в кадре 241, а командная строка вернулась в кадре 274. (Я знаю это, потому что наблюдал за выводом команды во время захвата трассировки.) Это большой объем трафика для анализа! Глядя на рисунок 6 выше, мы можем, по крайней мере, начать его анализ:
Кадры 3-4 показывают, что имя TEST125 преобразуется в IP-адрес 172.16.11.125 с использованием DNS.
Кадры 5–6 показывают, что IP-адрес 172.16.11.125 преобразуется в MAC-адрес с помощью ARP.
Кадры 7–9 показывают трехстороннее рукопожатие TCP (SYN, SYN/ACK, ACK), происходящее между test124 и test125.
Кадры 10–11 показывают, что между двумя машинами устанавливается привязка RPC.
Кадры 12–13 показывают, что DCOM используется поверх RCP (WMI использует DCOM для обработки удаленных вызовов).
И так далее.
Очевидно, что мы не можем отобразить на рисунке все 274 кадра, поэтому я скопировал сводную информацию о кадрах в текстовый файл. (Я также сохранил захват в виде файла.cap). Щелкните здесь, чтобы просмотреть сводку кадров, полученную при запуске ChangeIPAddress.vbs.
Это довольно ошеломляюще, не так ли? Как можно начать понимать, о чем вам говорит этот захват?
Что ж, при устранении неполадок хорошо начинать с того, что вы знаете, а не с того, чего не знаете. И мы знаем, что другой сценарий (ChangeGateway.vbs), который мы разработали в нашей предыдущей статье, работал без каких-либо сообщений об ошибках. Поэтому, прежде чем мы продолжим рассмотрение файла ChangeIPAddress.txt, давайте перезагрузим наши рабочие станции и сделаем еще один захват, на этот раз показав результат выполнения команды ChangeGateway.vbs 172.16.11.2 1 на test124, чтобы изменить шлюз по умолчанию для test125 с 172.16.11.1. на 172.16.11.2 (с указанием метрики 1). Вот как выглядит этот второй снимок (рис. 7):
Рис. 7. Результат запуска ChangeGateway.vbs 172.16.11.2 1 (щелкните, чтобы увеличить изображение)
На этот раз нужно проанализировать только 217 кадров (!), и вы можете щелкнуть здесь, чтобы просмотреть сводку кадров.
Анализ захвата для ChangeGateway.vbs
Давайте попробуем проанализировать этот второй захват (тот, который работал без ошибок), разбив сводку кадра по частям. Вот оно:
1 0.000000 NetmonFilter NetmonFilter: обновленный фильтр захвата: нет 2 0,000000 NetworkInfo NetworkInfo: информация о сети для TEST124, количество сетевых адаптеров = 1
Просто заголовок NM3 — не обращайте внимания.
3 0.000000 {DNS:3, UDP:2, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x4275, QUERY (стандартный запрос), запрос для 124.11.16.172.in-addr.arpa типа SOA на уроке Интернет 4 1.281250 {ARP:4} 172.16.11.181 172.16.11.1 ARP ARP: запрос, 172.16.11.181 запрашивает 172.16.11.1 5 1.890625 {DNS:6, UDP:5, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0xEB6E, QUERY (стандартный запрос), запрос для test125.test.local типа Host Addr в классе Internet 6 1.890625 {DNS:6, UDP:5, IPv4:1} dc181.test.local 172.16.11.124 DNS DNS: QueryId = 0xEB6E, QUERY (стандартный запрос), ответ – успех 7 1.906250 {ARP:7} 172.16.11.124 172.16.11.125 ARP ARP: запрос, 172.16.11.124 запрашивает 172.16.11.125 8 1.906250 {ARP:7} 172.16.11.125 172.16.11.124 ARP ARP: Ответ, 172.16.11.125 в 00-11-D8-E3-EC-84
Материалы для разрешения имен и адресов (DNS и ARP).
Больше RPC и DCOM. Я думаю, что «Alter Cont» указывает на использование альтернативного контекста, но на самом деле я не уверен. Тем не менее, все должно быть в порядке, так как скрипт работал без каких-либо ошибок.
Там много вещей RPC/DCOM. Выглядит загадочно, не так ли? Но если вы посмотрите внимательно, то увидите, что происходят некоторые вещи WMI, например, WMI-IWbemLoginClientID, WMI-IWbemLevel1Login, WMI-IWbemServices, WMI-IWbemFetchSmartEnum и так далее. Поиск в MSDN расскажет нам больше о том, что здесь происходит. Например, на этой странице говорится, что «интерфейс IWbemServices используется клиентами и поставщиками для доступа к службам WMI», поэтому похоже, что все эти I-штучки являются интерфейсами WMI (API), которые вызываются на удаленной машине (с использованием DCOM). рабочей станцией, с которой мы запускаем наш скрипт. И некоторые из этих интерфейсов на самом деле кажутся недокументированными, поэтому мы не будем слишком беспокоиться о том, чтобы попытаться их понять.
Отсюда все становится довольно плотным. Во-первых, есть еще куча вещей TCP с пакетами RPC «Continued Response», которые, кажется, указывают на то, что соединения, установленные ранее, используются для какой-то цели. Я собираюсь пропустить несколько кадров из следующей части трассировки:
Пока прошло всего две секунды. Теперь есть куча вещей DCOM, за которыми следуют TCP-соединения, завершающиеся с использованием FIN / ACK, поэтому я предполагаю, что скрипт, вероятно, выполнил свою работу и теперь очищает:
Теперь между test124 и контроллером домена происходят некоторые действия с DNS и LDAP. Я не уверен, почему это происходит, но я пропущу некоторые из этих кадров, так как их много:
179 2.546875 {MSRPC:19, TCP:18, IPv4:1} 172.16.11.124 dc181.test.local MSRPC MSRPC: c/o Bind: UUID {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Endpoint Mapper Call=0x1 Assoc Grp =0x0 Передать=0x16D0 Принять=0x16D0 180 2.546875 {MSRPC:19, TCP:18, IPv4:1} dc181.test.local 172.16.11.124 MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x7DAD Xmit=0x16D0 Recv=0x16D0 181 2.546875 {MSRPC:19, TCP:18, IPv4:1} 172.16.11.124 dc181.test.local EPM EPM: запрос: ept_map: отчет о недоставке, служба сервера отслеживания v1.0, RPC v5, 0.0.0.0:135 (0x87) [Разрешение конечной точки DCE (135)] 182 2.546875 {MSRPC:19, TCP:18, IPv4:1} dc181.test.local 172.16.11.124 EPM EPM: Ответ: ept_map: 0x16C9A0D6 – EP_S_NOT_REGISTERED 183 2.546875 {DNS:21, UDP:20, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x896A, QUERY (стандартный запрос), запрос для _ldap._tcp.Default-First-Site._sites. dc._msdcs.test.local типа SRV в классе Internet 184 2.546875 {DNS:21, UDP:20, IPv4:1} dc181.test.local 172.16.11.124 DNS DNS: QueryId = 0x896A, QUERY (стандартный запрос), ответ – успех 185 2.546875 {LDAP:23, UDP:22, IPv4:1} 172.16.11.124 dc181.test.local LDAP LDAP: поисковый запрос, MessageID:4, BaseObject: NULL, SearchScope: базовый объект, SearchAlias: neverDerefAliases 186 2.546875 {LDAP:23, UDP:22, IPv4:1} dc181.test.local 172.16.11.124 LDAP LDAP: запись результата поиска, MessageID:4, статус: успешно . . . 212 6.546875 {DNS:32, UDP:5, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x266D, QUERY (стандартный запрос), запрос для download.windowsupdate.com типа Host Addr в классе Internet 213 6.546875 {ARP:4} 172.16.11.181 172.16.11.1 ARP ARP: запрос, 172.16.11.181 запрашивает 172.16.11.1 214 7.546875 {DNS:32, UDP:5, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x266D, QUERY (стандартный запрос), запрос для download.windowsupdate.com типа Host Addr в классе Internet 215 8.546875 {DNS:32, UDP:5, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x266D, QUERY (стандартный запрос), запрос для download.windowsupdate.com типа Host Addr в классе Internet 216 9.281250 {ARP:4} 172.16.11.181 172.16.11.1 ARP ARP: запрос, 172.16.11.181 запрашивает 172.16.11.1
В этот момент сценарий уже закончился, поэтому я прекратил захват.
Анализ захвата для ChangeIPAddress.vbs
Теперь у нас есть некоторое представление о том, как выглядит захват успешного удаленного сценария:
Немного DNS и ARP
Установление сеансов TCP с использованием трехэтапного рукопожатия
Привязки RPC и DCOM
Больше рукопожатий TCP
Материал Kerberos (машины находятся в домене)
Другие материалы RPC/DCOM
Больше рукопожатий TCP, больше Kerberos, гораздо больше RPC/DCOM в сочетании с TCP-коммуникациями.
БОЛЬШЕ DCOM с последующим разрывом сеансов TCP, установленных ранее
И все это заняло чуть более 2 секунд.
Теперь давайте посмотрим на наш захват для ChangeIPAddress.vbs (скрипт, который генерирует ошибку RPC, когда мы запускаем его удаленно) и посмотрим, чем он отличается от приведенного выше.
1 0.000000 NetmonFilter NetmonFilter: обновленный фильтр захвата: нет 2 0,000000 NetworkInfo NetworkInfo: информация о сети для TEST124, количество сетевых адаптеров = 1