Работа администратора может на 90% состоять из устранения всевозможных проблем. Хорошие практические навыки в устранении неполадок позволяют быстро реагировать в кризисной ситуации и поддерживать бесперебойную работу сети. Когда приходится сталкиваться с непростой проблемой, стоит прежде всего задать себе ряд элементарных вопросов. Что изменилось? Возникала ли подобная ситуация раньше и если да, то когда? Можно ли воспроизвести проблему? Не сделал ли пользователь что-нибудь не так? Не оказались ли другие пользователи в таком же положении?
Затем следует локализовать проблему, с каждым шагом сужая область ее возможного возникновения «методом деления пополам». Например, если рабочая станция не может подключиться к сети, нужно попытаться определить масштаб проблемы - на уровне всей сети или отдельной рабочей станции. Если удалось быстро выяснить, что проблема касается только отдельной рабочей станции, значит, мы сумели сократить область поиска источника проблемы и в какой-то степени локализовать ее. Даже если сразу трудно найти решение, локализация проблемы сбережет огромное количество времени при обращении за помощью к другим специалистам.
Чтобы дать читателям представление о процессе устранения неполадок, я собрал несколько сценариев, начиная от распространенных и простых проблем и заканчивая довольно сложными. Если кого-то заинтересуют инструменты, которые я использую в сценариях, рекомендую прочитать врезку «Базовые инструменты для устранения неполадок».
Проблема: нет ни одного доступного сервера домена для проверки паролей
Многие наверняка неоднократно сталкивались с такой ситуацией: вы садитесь за свой компьютер и пытаетесь войти в сеть, но получаете сообщение об ошибке — недоступен ни один сервер домена, который мог бы проверить ваш пароль.
Чтобы устранить эту проблему, следует установить, относится ли она к рабочей станции, к сети или к серверу. Для начала нужно ответить на несколько вопросов.
Что изменилось? Какие изменения в сети могли бы привести к возникновению проблемы? Не был ли добавлен новый сервер, не был ли удален существующий, не менялось ли состояние концентратора или коммутатора, не был ли удален или добавлен контроллер домена (DC), не была ли установлена или прекращена связь с удаленным DC?
Сталкиваются ли другие рабочие станции с той же проблемой?
Находится ли сервер в рабочем состоянии?
Выясняется, что рабочая станция до сих пор работала как полагается. Ни на одной другой рабочей станции подобная ситуация не возникает, а сервер работает, поэтому можно с большой долей вероятности предположить, что проблема касается конкретной рабочей станции. Затем необходимо выяснить, где именно в пределах компьютера кроется ошибка. Дальнейшие вопросы могут быть такими.
Может ли рабочая станция обратиться к серверу?
Может ли рабочая станция получить IP-адрес?
Можно обращаться к серверу по ping, но запрос-ответ иной раз не срабатывает, что свидетельствует о неустойчивом соединении между сервером и рабочей станцией. Пользователь набирает в командной строке:
ipconfig /renew
Когда такая команда выполняется несколько раз, иногда на рабочей станции IP-адрес обновляется, а иногда нет. Это признак неустойчивого соединения между сервером и рабочей станцией. Часто пытаются поменять местами одну рабочую станцию с другой. Новая рабочая станция не функционирует на месте первой рабочей станции, а первая рабочая станция без проблем подключается к сети из другого расположения. Ясно, что что-то не так с кабелем или концентратором в первоначальном месте.
Попытка соединить кабель с другим концентратором ни к чему не приводит — подключиться к сети по-прежнему невозможно. Теперь понятно, что виновником является кабель. Проблема локализована. При дальнейшем исследовании обнаруживается, что в серверной комнате пережат пучок кабелей и что в соответствующем патч-корде переломлен шестой провод.
Проблема: не запускаются службы Windows
Представим себе следующую ситуацию: администратор перезапускает машину с Windows 2000 Server, и службы, настройка которых не предполагает запуска с учетной записью Local System Account, не запускаются. Приходится вручную открывать службу, заново вводить пароль и запускать службу. Каждый раз при вводе пароля система выдает сообщение об ошибке: <имя_пользователя> предоставлено право регистрации в качестве службы.
Чтобы устранить эту проблему, нужно ответить на следующие вопросы.
Что изменилось? Не внес ли кто-нибудь изменений на этом сервере?
Запускались ли службы раньше?
Являются ли действующими имя пользователя и пароль?
Вы исследуете ситуацию и обнаруживаете, что сервер, являющийся контроллером домена, до недавнего времени был членом организационной единицы (OU) Domain Controllers. Службы запускались нормально, пока сервер не был выведен из этой организационной единицы. Имя пользователя и пароль, которыми вы пользовались для запуска служб, действительны. При дальнейшем исследовании выясняется, что члены организационной единицы Domain Controllers имеют особые права, в том числе право регистрации в качестве службы. Сервер потерял это право, когда был перемещен из данной организационной единицы, и теперь следует вновь предоставить его серверу.
Чтобы сделать это, нужно выполнить следующие шаги.
- Запустить оснастку Active Directory Users and Computers консоли Microsoft Management Console (MMC) и открыть диалоговое окно Properties организационной единицы Domain Controllers.
- На вкладке Group Policy щелкнуть Default Domain Controllers Policy, затем Edit. На этом шаге запускается Group Policy Manager.
- Раскрыть объект Computer Configuration, затем Windows Settings и Security Settings. Далее следует раскрыть Local Policies и щелкнуть User Rights Assignment.
- правой панели нужно щелкнуть Log on as a service, затем щелкнуть Security.
- Добавить учетную запись, используемую для запуска службы, в политику и щелкнуть OK.
Более подробно об этой процедуре рассказано в статье Microsoft «How to Troubleshoot Service Startup Problems» (http://support.microsoft.com/?kbid=259733).
Проблема: извне перестала приходить электронная почта
Предположим, в компании используется Microsoft Exchange 2000 Server для обработки внутренней и внешней почты. Internet-провайдер неожиданно прекратил предоставление услуг, и компания быстро переключилась на нового провайдера. Пользователи имеют выход в Internet, но не получают внешние сообщения. Причем похоже, что исходящая почта работает нормально.
Следует начать процесс устранения проблемы, задав себе следующий вопрос:
работала ли почта до переключения на другого провайдера?
Чтобы убедиться в том, что сервер Exchange работает и защитный брандмауэр имеет правильную конфигурацию, нужно выполнить обращение к серверу через Internet на порт 25. Более подробно об этой процедуре можно прочитать в статье Microsoft «XFOR: Telnet to Port 25 of IMC to Test IMC Communication» по адресу: http://support.microsoft.com/?kbid=153119. Можно послать тестовое сообщение, которое позволит сделать вывод, что сервер и брандмауэр в порядке. Затем нужно задать себе следующий вопрос:
правильно ли был выполнен перенос домена при переходе к новому провайдеру?
С помощью утилиты Nslookup администратор пытается найти запись почтового сервера (MX) своего домена, но не обнаруживает ни одной записи. Отсюда можно сделать вывод, что при смене Internet-провайдера компания, обслуживавшая домен, выполнила пересылку домена неправильно. Следует обратиться в эту компанию, узнать IP-адрес для записи MX и попросить правильно выполнить пересылку домена новому Internet-провайдеру. После того как запись MX будет тиражироваться по Internet, получение входящей почты возобновится.
Проблема: серверы пропадают из сети
Предположим, обнаружилось, что рабочая станция Windows 2000 Professional может видеть серверы Windows 2000 лишь время от времени. Как будто серверы исчезают из сети. Для того чтобы начать процесс устранения проблемы, нужно задать себе следующие вопросы.
Не возникала ли эта проблема раньше?
Все ли рабочие станции сталкиваются с ней?
После исследования обнаруживается, что проблема появилась после модернизации серверов с Windows NT 4.0 на Windows 2000. Все рабочие станции сети сталкиваются с похожими трудностями. Теперь следует определить, к серверам относится эта проблема или к сети.
Необходимо зарегистрироваться на рабочей станции, открыть командную строку и ввести
Ping /pathping
для того, чтобы запросить сервер. Если запрос по IP-адресу выполнить можно, а по имени сервера — нет, вероятно, мы имеем дело с проблемой преобразования имен в IP-адреса или с проблемой DNS. Затем мы вводим
ipconfig /all
и замечаем, что сервер DNS, к которому обращается рабочая станция, есть сервер DNS Internet-провайдера. Windows 2000 использует DNS как первичный источник для разрешения имен, но рабочая станция пытается задействовать сервер DNS Internet-провайдера для получения имен серверов Windows 2000 нашей сети. Когда рабочие станции отправляют запрос на сервер DNS Internet-провайдера, они не могут получить от него правильный адрес, и серверы исчезают из сети. Чтобы устранить проблему, следует сделать первичным сервером DNS внутренний сервер DNS Windows 2000, чтобы внутренние рабочие станции опрашивали для локальных серверов внутренний DNS Windows 2000. После проверки корректности установки и работы DNS на сервере Windows 2000 настройки IP-адреса сервера DNS меняются так, чтобы он указывал сам на себя. Затем, с помощью менеджера DNS, нужно убедиться, что сервер DNS расположен в корне и что активизировано перенаправление. Посредством перенаправления достигается разрешение любых имен, не являющихся для сети локальными. Следует ввести серверы DNS Internet-провайдера в поле Forwarders. Наконец, необходимо переконфигурировать службу DHCP на сервере, изменяя адреса серверов DNS с Internet-провайдера на сервер Windows 2000, и обновить IP-адреса на рабочих станциях. Теперь сеть работает стабильно. Чтобы получить более подробную информацию о конфигурировании DNS в этой среде, рекомендую прочитать статью Microsoft «HOW TO: Configure DNS for Internet Access in Windows 2000» (http://support.microsoft.com/?kbid=300202).
Проблема: несколько линий WAN в одной LAN
Недавно в компании была установлена локальная сеть с двумя подключениями к глобальной сети WAN в Лос-Анджелесе. Одна линия WAN идет к корпоративной сети frame relay, другая идет в Internet и используется для обеспечения отказоустойчивости. На Рисунке 1 показана конфигурация сети. Пользователи из Лос-Анджелеса сталкиваются с нерегулярными проблемами, когда пытаются соединиться с сервером в Нью-Йорке. Необходимо задать себе следующие вопросы.
Когда появилась эта проблема?
Какой шлюз установлен по умолчанию?
Проблемы возникают не постоянно. DHCP в Лос-Анджелесе имеет шлюз по умолчанию 192.168.1.11 (т. е. брандмауэр). Все компьютеры в локальной сети Лос-Анджелеса сталкиваются с той же проблемой. Значит, вероятнее всего, мы имеем дело с глобальной проблемой маршрутизации в сети в Лос-Анджелесе.
Статическая маршрутизация брандмауэра маршрутизирует адреса 192.168.2.0 и с маской 255.255.255.0 на маршрутизатор 192.168.1.10. С помощью команды Route Print нужно проверить этот маршрут. Сервер в Лос-Анджелесе иногда успешно соединяется с сервером в Нью-Йорке, но не всегда. Запустив программу Tracert, получаем результаты, изображенные на Рисунке 2.
|
| Рисунок 2. Результаты выполнения команды Tracert. |
При просмотре журнала брандмауэра обнаруживается, что время от времени блокируется пересылка пакетов на адрес 192.168.1.10, даже несмотря на то, что правило для пересылки этих пакетов установлено. Брандмауэры бывают разные, но большинство из поставщиков отговаривают пользователей от применения его в качестве маршрутизатора. Если брандмауэр будет успешно атакован, взломщик сможет получить важную информацию о линиях WAN.
Необходимо переконфигурировать сеть, чтобы использовать шлюз по умолчанию 192.168.1.10 (маршрутизатор). Следует выполнить команду
Ip route 0.0.0.0 0.0.0.0 192.168.1.11
для того, чтобы установить маршрут по умолчанию на маршрутизаторе на перенаправление всего трафика на брандмауэр. Когда пользователи захотят получить доступ в Internet, они попадут на маршрутизатор и будут выходить через брандмауэр.
Как повлияет на доступ в Internet сбой на маршрутизаторе в Лос-Анджелесе (192.168.1.10)? Какие следует принять меры, если сеть frame relay «упадет», а Internet-соединение будет работать нормально? Если маршрутизатор в Лос-Анджелесе выйдет из строя, компания лишится Internet-соединения. Напомню, что в качестве шлюза по умолчанию установлен маршрутизатор. При сбое маршрутизатора пакеты не будут переправляться на брандмауэр. Можно будет восстановить Internet-соединение в Лос-Анджелесе, изменив настройку DHCP для шлюза по умолчанию на брандмауэр. Конечно, корпоративная линия WAN и доступ в Internet останутся отключенными для других городов, пока не будет восстановлен маршрутизатор в Лос-Анджелесе.
Проблема: рабочие станции не видят сеть
Рабочие станции на пятом этаже офиса с некоторых пор не видят сервер и не имеют связи с Internet. С проблемой они сталкиваются не всегда. Необходимо задать себе следующие вопросы.
Как давно возникла проблема?
Были ли сделаны какие-нибудь изменения?
Используя утилиту Pathping, вы замечаете ошибки в виде потери некоторых пакетов. Создается впечатление, что источник проблемы — на пятом этаже.
С помощью кабельного тестера вы прослеживаете сеть вплоть до коммутатора Ethernet на шестом этаже. Пятый и шестой этажи используют общий коммутатор. Предположив, что, возможно, испорчен порт коммутатора, вы меняете порты с одним из компьютеров на шестом этаже, но проблема остается локализованной на пятом этаже, следовательно, коммутатор, скорее всего, в порядке. В поисках разгадки вы решаете проверить физические соединения.
Вернувшись на пятый этаж, вы замечаете небольшой пятипортовый концентратор в одном из подсобных помещений. Приглядевшись повнимательнее, обнаруживаете четыре других маленьких концентратора, соединенных друг с другом. Вот и разгадка. Вы можете иметь только один переход Класса I (с временем запаздывания 0,7 мс) или два перехода Класса II (с временем запаздывания 0,46 мс) на сегмент с переключателем Ethernet типа 100Base-T. Именно поэтому я не рекомендую использовать маленькие концентраторы в корпоративных сетях. Удалите все маленькие концентраторы и протяните кабели прямо к коммутатору на шестом этаже. Проблема решена.
Не стоит думать, что решения распространенных проблем можно заучить наизусть. Более того, к каждой проблеме следует подходить творчески, задавая себе простые вопросы и пытаясь на каждом шаге максимально сузить область возможного возникновения проблемы. Помните: локализация проблемы — самое главное.
Базовые инструменты для устранения неполадок
Windows XP и Windows 2000 содержат несколько базовых инструментов, предназначенных для устранения проблем.
В дополнение к этим встроенным программным инструментам я держу под рукой кабельный тестер и вольтметр.
PathpingКоманда Pathping позволяет проверить, можете ли вы подключиться к компьютеру по сети. Введите в командной строке
pathping
Результаты дадут некоторую информацию о потере пакетов.
Ipconfig
Команда используется для получения информации об IP-конфигурации рабочей станции. Введите в командной строке
ipconfig /all
Вы можете изучить результаты, для того чтобы определить следующее.
- Проверить правильность IP-адреса и маски подсети рабочей станции. Неправильные IP-адрес и маска подсети могут вызвать проблемы соединения.
- Когда используется DHCP, проверить, выделен ли рабочей станции IP-адрес. Если вы не можете получить IP-адрес, возможно, имеет место проблема DHCP-сервера.
- Узнать, какой шлюз установлен по умолчанию. Неправильная установка шлюза по умолчанию может вызвать проблемы соединения с удаленными сетями и Internet.
- Проверить сервер DNS. Windows XP и Windows 2000 при разрешении имен полагаются только на DNS. Вообще, рабочая станция должна быть настроена на сервер Windows 2000 для нахождения DNS.
Nslookup
Утилита Name Server Lookup (Nslookup) используется для проверки записей на сервере DNS. В командной строке вводится
nslookup
Я использую Nslookup для проверки записей почтового сервера при устранении проблем доставки почты через Internet.
Route Print
Команда Route Print отображает динамические и статические маршруты на локальной машине. Эта утилита полезна при использовании вместе с командами Ping, Tracert и Pathping для определения маршрутов, по которым перемещаются пакеты. В командной строке вводится
route print
можно также задействовать команду Route Add для ввода статических маршрутов на серверы и рабочие станции.
Netdiag
Команда Netdiag возвращает полезную информацию о сетевых настройках компьютера, в том числе IP-конфигурацию, имя сервера, тест шлюза по умолчанию, тест Winsock, тест DNS и обратного разрешения. Для достижения наилучших результатов следует обязательно привязать TCP/IP к одному из сетевых адаптеров на сервере. Результаты выполнения этой утилиты выводятся в файл netdiag.log.
Алан Сугано — президент компании ADS Consulting Group, специализирующейся на предоставлении сетевых услуг и разработке продуктов для Microsoft .NET Web и SQL Server. С ним можно связаться по адресу: asugano@adscon.com.