Как бы то ни было, нельзя считать, что проблемы на самом деле не существует — что-то же заставило человека обратиться к вам. Иногда причиной неполадок может быть его собственная ошибка, неправильное использование приложения или оборудования, а может, просто неверные представления и ожидания в отношении той или иной системы. Небольшой инструктаж, проведенный для такого пользователя, облегчит в будущем жизнь вам обоим.

Прежде чем всерьез браться за диагностирование, проверьте, применялось ли приложение на рабочей станции раньше, был ли доступен сервер и тому подобные моменты. Если проблемы возникли в результате недавней инсталляции, то процесс диагностирования будет иным. Одно дело — восстановить работу уже установленного и успешно использовавшегося программного обеспечения, и совсем другое — внедрить новый сервис.

Далее перечислены три типа жалоб, которые чаще всего поступают от пользователей. Практически все обращения относятся к той или иной категории:

  • отсутствие доступа в сеть;
  • обрыв связи;
  • низкая скорость.

Некоторые сбои связаны с совместно используемыми сетевыми ресурсами (концентраторами), другие — с коммутируемой сетевой средой, а иногда — с обеими областями сразу.

Для каждого типа жалоб мы приводим общий порядок действий по устранению проблемы. Предпринимаемые действия зависят от результатов одного или большего количества тестов. Конечно, охватить все возможные варианты не удастся, но мы постараемся предложить общий подход к диагностированию и указать направление движения.

Описания действий довольно подробны и поясняют, почему тот или иной тест так важен и на что следует обратить внимание. Не воспринимайте это как рекомендацию к проведению всех тестов, какие только возможны. Здравый смысл поможет выбрать нужные и отказаться от бесполезных. Речь идет о своеобразном контрольном списке, в котором вы последовательно вычеркиваете пункты. Проводя диагностику, надо держать в уме все варианты, один за другим исключая из них неподходящие. Если для исключения пункта нет оснований, то необходимо запустить тест.

Примечание: если в ходе тестирования сменили коллизионный домен, то при подключении в новой точке всегда начинайте с тестирования коллизионного домена.

ЖАЛОБА: НЕ МОГУ ВОЙТИ В СЕТЬ

Перечисленные ниже процедуры подразумевают, что соответствующие сервер или служба раньше работали нормально, а вы уже выполнили следующие действия:

  • осуществили холодную перезагрузку проблемной рабочей станции (именно холодную, поскольку горячая перезагрузка не сбрасывает состояние всех адаптерных карт). В результате будут инсталлированы загруженные, но неустановленные программные исправления («заплаты»). Помните, что некоторые устройства Plug-and-Play для полной установки требуют двух, а иногда и трех перезагрузок;
  • убедились в исправности всех аппаратных компонентов рабочей станции;
  • удостоверились в наличии всех необходимых сетевых кабелей и их корректном подключении;
  • выяснили, что сетевая карта не отключена и имеет правильный адрес в рамках подсети (динамический, DHCP или статический). В отчетах операционной системы о статусе сетевой карты количество отправленных и полученных пакетов должно быть отличным от нуля (если хоть одно из этих значений нулевое, значит, надо разобраться, в чем дело);
  • проверили, не было ли изменений на самой рабочей станции, на сервере или в настройках, не устанавливалось ли новое программное или аппаратное обеспечение.

Проблемы при входе в сеть проявляются, когда пользователю не удается подключиться к серверу или службе. Обычно он не видит разницы между ситуациями, когда рабочая станция не может подключиться к сети или не получает доступ к конкретному серверу или сетевой службе. По сравнению с другими видами сетевых сбоев, этот относительно легко поддается локализации. Выясните, затрагивает ли проблема только данную рабочую станцию или небольшую группу станций (проблема коллизионного домена, включая отдельный порт на коммутаторе), либо большое количество станций (проблема широковещательного домена или даже сопряженных сетей).

Прежде чем приступать к диагностированию оборудования, попробуйте войти в сеть с данной станции под собственной учетной записью или попросите пользователя выполнить ту же операцию с соседнего ПК, работающего нормально. Это самый простой способ отличить проблемы, связанные с учетной записью пользователя, от неполадок с сетью. Если подключение с другой станции оказывается неудачным, значит, надо проверять учетную запись. Кстати, наблюдение за тем, как пользователь пытается выполнить операцию, вызывающую сбой, поможет выяснить, нет ли ошибки в последовательности его действий. В этом случае несколько минут, потраченных на обучение, избавят от неприятностей в будущем.

Проблемы в коллизионном домене влияют на локальную среду и препятствуют надежной связи с инфраструктурным устройством второго или третьего уровня либо с локальным сервером или службой, к которым вы пытаетесь подключиться. Как правило, причины следующие:

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

Сбои в коллизионном домене можно идентифицировать с помощью тестера, подключенного в разрыв между рабочей станцией и портом устройства. Тестер следит за попыткой подключения после холодной перезагрузки ОС, выполнить которую необходимо, поскольку многие проблемы, связанные с операционными системами, крайне сложно (иногда невозможно) воссоздать и точно идентифицировать. Перезагрузка позволяет избавиться от ошибок непонятной природы, хотя бы временно.

Многие пользователи имеют как проводную, так и беспроводную сетевые карты, причем зачастую активированы обе. Если персональный компьютер пытается использовать беспроводную карту вместо проводного соединения, то необходимо разбираться с местоположением рабочей станции, а порой даже с ее ориентацией в пространстве. Во многих беспроводных сетях есть «слепые зоны», но нередко они очень небольшие, и перемещение компьютера на десяток сантиметров или разворот в ту или иную сторону позволяет успешно восстановить соединение. Случается, что прохождению беспроводного сигнала мешают люди, столпившиеся вокруг компьютера.

Проблемы в широковещательном домене начинаются только после установления надежного соединения на уровне MAC. Типичный пример — невозможность создать логическое соединение через мост. Сюда же относятся и проблемы на сетевом уровне, которые могут препятствовать обмену пакетами с серверами и маршрутизаторами, входящими в этот широковещательный домен:

  • находящийся в пограничном или сбойном состоянии порт для каскадирования (uplink port), расположенный в любом месте маршрута. Как правило, причина заключается в использовании некачественного кабеля;
  • широковещательный шторм или чрезмерный трафик другого типа в широко-вещательном домене (причем такой трафик вовсе не обязательно наблюдается на локальном порту);
  • ошибки протокола ICMP либо неправильное назначение IP-адресов в локальной подсети; дублирующиеся IP-адреса;
  • сбои серверов или служб DNS и DHCP;
  • рабочая станция или сервер некоррект-но объявляют маршруты.

Ошибки с присвоением адресов и некоторые другие проблемы может выявить тест, применяемый для проверки коллизионного домена, — с помощью прибора, подключаемого в разрыв. Переместившись на новое место внутри широковещательного домена, не забудьте снова протестировать коллизионный домен. Если адрес получен и/или он правильный, то придется либо собрать с помощью анализатора протоколов и посмотреть трассировочный файл, либо использовать программное обеспечение управления сетью, чтобы опросить инфраструктурные устройства в широковещательном домене.

Проблемы с сопряженными сетями начинаются только после установления надежного соединения с маршрутизатором, через который данные отправляются за пределы широковещательного домена. Сложность диагностирования возрастает, а уровень доступа снижается, если сервер или служба расположены по другую сторону глобальной сети, а не в соседней локальной сети. Однако симптомы в целом схожие:

  • неустойчивая маршрутизация из-за пограничного или сбойного состояния порта за пределами широковещательного домена; вероятная причина – плохой кабель;
  • невозможность выполнить Trace Route, малочисленные ответы на запросы Ping;
  • неправильные настройки маршрутизации, включая конфигурацию перенаправления запросов DHCP в тех случаях, когда сервер находится за пределами локальной подсети и отдельных виртуальных сетей VLAN;
  • неполадки в виртуальной сети VPN, в том числе с максимальным размером пакета MTU;
  • проблемы с брандмауэром (firewall) или другими блокирующими средствами безопасности, включая проблемы с учетными записями или паролями.

Использование запросов Ping и функции отслеживания Trace Route, как правило, позволяет выявить узел, с которого следует начать диагностирование проблемы отсутствия соединения. Как только подозрительный удаленный узел выявлен, опросите соответствующее сетевое устройство и устройство, предшествующее ему, с помощью системы управления сетью. Либо то, либо другое будут выдавать ошибки какого-то типа или показывать чрезмерный уровень загруженности. Надежное сквозное соединение на сетевом уровне снимает большинство проблем. При перемещении в новое место не забывайте начинать проверку с тестирования коллизионного и широковещательного домена.

Если ответы на запрос Ping приходят, а соединение так и не возобновилось, попробуйте увеличить размер пакета Ping. Это поможет обнаружить проблему с размером пакетов MTU по трассируемому маршруту. Виртуальные сети VPN добавляют к пакету заголовок, поэтому пользовательское значение MTU должно быть меньше на соответствующую величину. Если сквозная доставка пакетов на сетевом уровне осуществляется надежно, то остается одно – использовать анализатор протоколов. Необходимо собрать и проанализировать данные при попытке установить соединение. Иногда приходится проводить захват пакетов еще и со стороны сервера или службы, чтобы убедиться, что запросы до них доходят, а отклики своевременно отправляются.

Если и отправка запросов Ping, и запуск функции Trace Route проходят успешно, попробуйте установить с тестируемым портом соединение через Telnet. В случае успеха соединение появится, хотя никаких внешних проявлений может и не быть. Отказ в соединении по Telnet означает, что эта служба недоступна, и тогда невозможность соединения становится очевидной.

Два других основных вида пользовательских жалоб будут рассмотрены в следующих статьях цикла.

Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.