Устранение неполадок TCP/IP: структурированный подход — часть 1: введение

• Устранение неполадок TCP/IP: структурированный подход. Часть 4. Использование Netdiag.exe

Это первая из серии статей об устранении неполадок TCP/IP, а последующие статьи будут посвящены ключевым вопросам, освещенным в этой статье.

Что вы представляете, когда слышите фразу «устранение неполадок TCP/IP»? Люди с визуальным воображением могут увидеть блок-схему. Люди с более линейным мышлением могут увидеть серию пронумерованных шагов. Другие (слишком распространенные) могут испытывать чувство неадекватности и разочарования.

Устранение неполадок TCP/IP должно быть простым, верно? В конце концов, это всего лишь протокол — последовательность шагов для передачи битов по сети. Но что за протокол — четыре уровня и несколько протоколов на каждом уровне.

Получите свою копию Windows Server Hacks!

Традиционный подход

Несколько лет назад, когда я впервые узнал о сетях TCP/IP, меня научили простому подходу к устранению неполадок, состоящему из следующих шагов. Метод выглядел примерно так:

• Введите ipconfig, чтобы проверить правильность вашего IP-адреса, маски подсети и шлюза по умолчанию.
• Теперь пропингуйте 127.0.0.1, чтобы проверить, работает ли ваш сетевой адаптер.
• Теперь пропингуйте IP-адрес вашего собственного компьютера.
• Теперь попробуйте пропинговать IP-адрес другого компьютера в той же подсети.
• Теперь попробуйте пропинговать шлюз по умолчанию (ближний интерфейс маршрутизатора, который соединяет вашу подсеть с остальной сетью).
• Теперь попробуйте пропинговать IP-адрес компьютера в другой подсети.
• И так далее.

Я называю это «подходом с мертвым мозгом», потому что он настолько методичен, что вы можете просто отключить свой мозг и просто следовать шагам. Это также несколько неэффективно, поскольку автоматически предполагает, что ваша проблема, скорее всего, начинается с вашего собственного компьютера и что проблема, скорее всего, находится ближе к вам (ваша сетевая карта, конфигурация IP-адреса вашего компьютера, ваша локальная подсеть), чем дальше ( другие подсети). И этот метод, вероятно, был разработан до того, как Интернет действительно начал развиваться, то есть до того, как DNS стал повсеместным для разрешения имен и до того, как брандмауэры и VPN стали реальностью для большинства корпоративных сетей.

Я имею в виду следующее: один из ваших пользователей говорит: «Я не могу подключиться к серверу прямо сейчас». В чем может быть проблема? Это помогает проанализировать это простое предложение, чтобы понять проблемы, которые могут быть затронуты. Например:

«Я не могу…»

Это единственный пользователь, который звонил и сообщал о проблемах с сетью? Если есть другие, есть ли у них аналогичные проблемы? Если это так, то сразу становится ясно, что вам не нужно применять безмозглый подход и начинать устранение неполадок на компьютере пользователя. Вместо этого проблема, скорее всего, где-то «где-то там», и это может означать, что ваш DNS-сервер отключен или службы вашего DNS-провайдера могут испытывать трудности. Или, может быть, маршрутизатор в вашей внутренней сети может сходить с ума и отбрасывать пакеты. Или, возможно, сервер, к которому пытаются подключиться ваши пользователи, вышел из строя.

Вы также должны остановиться и подумать о любых общих чертах, которые могут быть у этих пользователей, у которых возникли проблемы. Например, все ли их машины находятся в одной подсети? Если это так, то, возможно, шлюз по умолчанию для этой подсети неправильно настроен или произошел сбой маршрутизатора. Или, может быть, подрядчик, работающий в подсобном помещении, случайно перерезал сетевой кабель, соединяющий коммутатор рабочей группы подсети с главным магистральным Ethernet-коммутатором отдела. Или, может быть, кто-то злоумышленник установил мошеннический DHCP-сервер в этой подсети, и он крадет машины, когда их аренда подходит для продления, и назначает им немаршрутизируемые адреса, чтобы создать условие отказа в обслуживании.

Если проблема только у одного пользователя, то, вероятно, пришло время прикинуться мертвым мозгом и начать задавать вопросы типа «Хорошо, ваш компьютер включен? Надежно ли подключен сетевой кабель к задней части устройства?» и так далее.

"…подключиться к…"

Хороший вопрос, который можно задать этому пользователю: «Что вы подразумеваете под подключением?» Это связано с тем, что слово «подключение» звучит технически, и пользователи часто используют его, чтобы произвести впечатление на службу поддержки и показать, что они знают, о чем говорят. Обычно они этого не делают. Почему? Потому что существуют различные виды подключения, включая связь на уровне MAC, сеансы TCP, аутентификацию по паролю, права доступа и привилегии, подключение с обходом NAT, сквозное подключение к брандмауэру, сеансы на уровне приложений и так далее. Какие проблемы со связью у них на самом деле? Что они на самом деле пытаются сделать, когда говорят, что хотят «подключиться» к серверу? Пытаются ли они получить доступ к общему ресурсу на этом сервере? Получают ли они при этом сообщение «Отказано в доступе»? Получают ли они окно входа в систему с запросом учетных данных? Отклоняет ли он их верительные грамоты? Возникают ли у них проблемы с поиском общего ресурса в Active Directory? У них проблемы с подключенным диском? Они пытаются найти сервер в My Network Places? И так далее.

Проблемы с подключением только к этому серверу или проблемы с подключением к чему-либо в сети? Здесь важно определить масштаб проблемы: нарушается ли подключение только одним или многими способами?

"…сервер…"

У вас есть этот пользователь здесь, и этот сервер там, и сеть между ними. Они не могут подключиться. Почему? Ну и где вообще этот сервер? Это в подсети пользователя? В соседней подсети? В другом отделе? На другом этаже? В другом здании? На другом континенте? Какая сеть соединяет пользователя с этим конкретным сервером? Проводная локальная сеть Ethernet? Беспроводная локальная сеть (WLAN)? Дробная линия T1? Ретрансляция кадров? Туннель VPN через Интернет? Коммутируемое модемное соединение? Кабельный модем или DSL? Сначала определите тип соединения (возможно, несколько типов) между пользователем и сервером, а потом подумайте, где что может сломаться. Возможно, CSU/DSU вышел из строя, попробуйте восстановить его питание или обратитесь к поставщику услуг, который должен его контролировать. Может быть, дворник убирал серверную, он задел панель питания, и Ethernet-коммутатор отключился. Проверьте наличие предупреждающего сообщения от программного обеспечения для управления сетью, если вы используете управляемые коммутаторы. Возможно, в удаленном филиале, где расположен этот сервер, отключилось электричество. Позвоните им по телефону и узнайте, что происходит.

И это сервер или серверы? У пользователя возникают проблемы с подключением только к этому серверу или к другим серверам? Есть ли у других проблемы с подключением к другим серверам? Каковы общие черты (если они есть) между всеми затрагиваемыми серверами? (Или явно затронуты — помните, проблема может быть связана с компьютерами пользователей или, что более вероятно, с самой сетевой инфраструктурой.)

"…прямо сейчас."

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

Время также может помочь вам связать проблему с другими обстоятельствами, которые могут повлиять на вашу сеть. Проблема началась сегодня в 10 утра? Что еще произошло в вашей сети в то время? Были ли исправления применены сервером WSUS? Произошло ли плановое обслуживание контроллера домена? Строительная бригада в строительном комплексе использовала экскаватор для ремонта прорыва водопровода?

Структурированный подход

Мой собственный подход к устранению неполадок TCP/IP структурирован вокруг трех критических областей:

1. Определение элементов проблемы. Это означает:
   • Клиентская сторона: Клиент(ы), которые испытывают трудности (или трудности) (пользовательская сторона).
   • Конец сервера: сервер(ы), принтер(ы) или другие сетевые ресурсы (например, Интернет), с которыми у клиентов возникают проблемы.
   • Промежуточная сеть: провода (если не беспроводные), концентраторы, коммутаторы, маршрутизаторы, брандмауэры, прокси-серверы и любая другая сетевая инфраструктура между клиентской частью и серверной частью.
   • Окружающая среда: внешние обстоятельства, которые могут повлиять на вашу сеть, такие как перепады напряжения, техническое обслуживание здания и т. д.
   • Область применения: один или несколько задействованных клиентов/серверов.
   • Временные рамки: непрерывный, прерывистый, случайный; когда это началось; и так далее.
   • Тип проблемы с подключением: Физический, сетевой, транспортный или прикладной уровень; аутентификация или контроль доступа; и так далее.
   • Указатели: сообщения об ошибках на клиентских машинах; ящики входа; и так далее.

2. Определите, какие действия по устранению неполадок могут быть применимы с учетом вышеуказанных проблемных элементов. Это включает:
   • Проверка подключения физических носителей для задействованного оборудования клиентов, серверов и сетевой инфраструктуры. Это означает проверку кабелей, правильность установки сетевых адаптеров и поиск других причин, по которым сетевые подключения отображают состояние отключения носителя.
   • Проверка конфигурации TCP/IP клиента(ей), сервера(ов) и задействованного оборудования сетевой инфраструктуры. На клиентах и серверах это означает IP-адрес, маску подсети, шлюз по умолчанию, настройки DNS и т. д. Для оборудования сетевой инфраструктуры обычно используются таблицы маршрутизации на маршрутизаторах и интернет-шлюзах.
   • Проверка соединения маршрутизации между участвующим(и) клиентом(ами) и сервером(ами). Это означает использование ping, pathping, tracert и других подобных инструментов для проверки сквозного соединения TCP/IP на сетевом уровне; перехват пакетов для мониторинга сеансов транспортного уровня; использование nslookup, telnet и других инструментов для устранения неполадок прикладного уровня, связанных с разрешением имен, проблемами аутентификации и т. д.

3. Пойми это, спроси это, испытай это.
   • Понимание того, как работают протоколы, как пакеты пересылаются таблицами маршрутизации, что могут сказать такие инструменты, как Netdiag.exe, имеет решающее значение. Успешное устранение неполадок TCP/IP основано на хорошем понимании того, как работает TCP/IP, и инструментов, которые можно использовать для его тестирования. Если вы никогда не пытались понять трассировку сетевого монитора, у вас возникнут трудности с устранением определенных проблем.
   • Правильные вопросы также имеют решающее значение для правильного устранения неполадок. Научиться, когда быть методичным, а когда сделать мысленный скачок, — это суть искусства устранения неполадок, и оно включает в себя полное использование как вашего левого полушария (логика), так и правого полушария (интуиция).
   • Наконец, очень важно запачкать руки и на самом деле протестировать что-то, чтобы попытаться изолировать проблему, и для этого вам нужен набор инструментов для устранения неполадок, которые вы знаете, как использовать. Нет ничего лучше, чем большой опыт, который поможет вам решить сложную проблему, даже если вы никогда раньше с ней не сталкивались.

Вывод

Устранение неполадок в сетях TCP/IP может быть разочаровывающим, но также может быть и интересным. В будущих статьях мы подробно рассмотрим шаги и инструменты для устранения неполадок, которые вам необходимо использовать для успешного решения проблем, которые могут возникнуть в вашей сети. А пока оставайтесь на связи!

• Устранение неполадок TCP/IP: структурированный подход. Часть 4. Использование Netdiag.exe