Monday, December 11th, 2017

Устранение неисправностей TCP/IP: Структурный подход (Часть 1)

Published on Февраль 19, 2009 by   ·   Комментариев нет

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

Если вы хотите ознакомиться с остальными частями статьи, то, пожалуйста, пройдите по ссылкам:

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

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

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

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

  • Напечатать команду ipconfig для проверки правильности вашего IP адреса, маски подсети (subnet mask) и шлюза по умолчанию (default gateway).
  • Затем запустить команду ping 127.0.0.1. для того, чтобы убедиться, что ваш сетевой адаптер (network adapter) находится в рабочем состоянии.
  • Затем запустить команду ping для IP адреса вашего собственного компьютера.
  • Затем запустить команду ping для IP адреса другого компьютера, находящегося в той же самой подсети (subnet).
  • Затем попытаться запустить команду ping для вашего шлюза по умолчанию (default gateway) (ближний интерфейс маршрутизатора (router), который подключает вашу подсеть (subnet) к остальной сети).
  • Затем попытаться запустить команду ping для IP адреса компьютера в другой подсети.
  • И так далее.

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

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

«Я не могу…»

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

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

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

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

Неплохо бы задать также пользователю такой вопрос: «А что вы подразумеваете под словом подключиться?» Это необходимо сделать потому, что слово «подключиться» – это техническое слово, которое пользователи часто используют для того, чтобы впечатлить специалиста службы поддержки своими знаниями в этой области. Но, как показывает практика, эти знания обычно отсутствуют. Почему? Потому, что существуют различные типы подключений, включая соединения на уровне MAC, сессии TCP, аутентификация с помощью пароля (password-authentication), права и привилегии на доступ, соединения NAT-traversal, прохождение брандмауэра (firewall pass-through), сессии прикладного уровня (application-level sessions), и так далее. С каким из типов соединения у вас обычно возникают проблемы? Что они обычно пытаются сделать, когда говорят, что хотят подключиться к серверу? Пытаются ли они получить доступ к общей папке на этом сервере? Получают ли они при этом в ответ сообщение «Access denied (доступ запрещен)»? Или же у них появляется окно, требующее ввести имя пользователя и пароль? Или же не подходит их имя пользователя и парольs? Или у них возникли проблемы с поиском общей папки в Active Directory? Может быть у них возникли проблемы с диском (mapped drive)? Может быть у них не получается найти сервер в сетевом окружении (My Network Places)? И так далее.

Возникли ли у них проблемы с подключением к серверу, или они пытаются подключиться к чему-либо еще в сети (network)? Определение границ проблемы здесь очень важно: не удается подключиться к одному серверу или же к нескольким?

oem software store

«…сервер…»

У вас есть пользователь, сервер и сеть между ними. Они не могут подключиться друг к другу. Почему? Хорошо, а где точно находится сервер? Находится ли он в подсети пользователя? В смежной подсети? В другом структурном подразделении? На другом этаже? В другом здании? На другом континенте? Какой тип сети связывает пользователя с соответствующим сервером? Проводная Ethernet LAN? Беспроводная wireless LAN (WLAN)? Обычная линия T1 line? Frame Relay? Туннель VPN tunnel через Интернет (Internet)? Телефонное модемное (dial-up modem) соединение? Кабельный модем или DSL? Сперва определите тип соединения (возможно несколько типов) между пользователем и сервером, а затем уже начинайте думать, что и где могло сломаться. Может быть, сломался CSU/DSU пытаясь соединиться с поставщиком услуг (service provider), который контролирует его. Может быть, уборщица наводила порядок серверной комнате и случайно выключила Ethernet переключатель (switch). Проверьте поступление сообщений тревоги от вашего программного обеспечения по управлению сетью (network management software), в этом случае мы предполагаем, что вы используете управляемые переключатели (managed switches). Может быть, возникли перебои с питанием в удаленном дочернем офисе, в котором располагается сервер. Позвоните им по телефону и спросите, что случилось.

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

«…в настоящий момент.»

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

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

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

Мой собственный подход в устранении неисправностей TCP/IP (troubleshooting) – это структурный подход, который охватывает три важных области:

  1. Определение проблемных единиц. Это означает:
    • Сторона клиента: клиент или клиенты, у которого возникли трудности или трудность.
    • Сторона сервера: сервер, принтер или другие сетевые ресурсы (например, интернет), с которым возникли трудности у клиента.
    • Сеть между ними (Network): проводная (wires) или беспроводная (wireless), маршрутизаторы (hubs), переключатели (switches), роутеры (routers), брандмауэры (firewalls), прокси сервера (proxy servers) и любая другая инфраструктура (infrastructure) между стороной клиента и стороной сервера.
    • Окружение: внешние обстоятельства, которые могут влиять на вашу сеть, например, перебои с питанием, ремонтные работы по зданию и т.д.
    • Область: может быть вовлечен один или несколько клиентов и серверов.
    • Временной фактор: повторяющиеся, временные, случайные; время начала и т.д.
    • Тип проблемы с соединением: физическая (Physical), сетевая (network), на транспортном или прикладном уровне (transport or application layer), проблема с аутентификацией или контролем доступа и т.д.
    • Признаки: сообщения об ошибках на клиентских компьютерах; меню для входа и т.д.
  1. Определение необходимых этапов отладки, для решения проблем с вышеперечисленными элементами. Это включает в себя:
    • Проверка физического соединения для аппаратного обеспечения клиента, сервера и сетевой инфраструктуры. Это означает проверку кабелей, установки сетевых адаптеров проверка других соединений.
    • Проверка конфигурации TCP/IP аппаратного обеспечения клиента, сервера и сетевой инфраструктуры. Для клиентов и серверов это означает проверку IP адреса, маски подсети, шлюза по умолчанию, параметров DNS и так далее. Для сетевой инфраструктуры это обычно означает проверку таблиц маршрутов на маршрутизаторах и интернет шлюзах .
    • Проверка соединения между клиентом и сервером. Это означает использование инструментов ping, pathping, tracert, и других аналогичных средств для проверки end-to-end TCP/IP соединения на сетевом уровне; сетевой анализ пакетов (packet sniffing) для проверки сессий на транспортном уровне; использование nslookup, telnet и других инструментов для устранения неисправностей на прикладном уровне, устранения проблем, связанных с распознаванием имен и аутентификацией.
  1. Понять, спросить и протестировать.
    • Очень важно понимание принципов работы протокола, как передаются пакеты согласно маршрутным таблицам, как работают инструменты типа Netdiag.exe, и что они могут сообщить. Успешное устранение неисправностей для TCP/IP зависит от понимания принципов работы TCP/IP, и инструментов, которые можно использовать для их проверки. Если вы никогда не пытались понять результаты сетевого мониторинга, то у вас возникнут проблемы определенного типа.
    • Правильные вопросы также существенно помогут в устранении неисправностей. Научитесь быть методичными и тогда вы сможете существенно облегчить себе жизнь и использовать, как логический подход, так и интуитивный.
    • Наконец, очень важно не забывать о тестировании, и попытаться изолировать проблему, а для этого необходимо уметь работать с инструментами для устранения неисправностей. При решении сложных проблем вам сможет помочь ваш личный опыт.

Заключение

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

www.windowsnetworking.com

jfdghjhthit45


Смотрите также:

Tags: , , , , , ,

Readers Comments (Комментариев нет)

Comments are closed.

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]