Устранение неисправностей 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)? Определение границ проблемы здесь очень важно: не удается подключиться к одному серверу или же к нескольким?

"…сервер…"

У вас есть пользователь, сервер и сеть между ними. Они не могут подключиться друг к другу. Почему? Хорошо, а где точно находится сервер? Находится ли он в подсети пользователя? В смежной подсети? В другом структурном подразделении? На другом этаже? В другом здании? На другом континенте? Какой тип сети связывает пользователя с соответствующим сервером? Проводная 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, и инструментов, которые можно использовать для их проверки. Если вы никогда не пытались понять результаты сетевого мониторинга, то у вас возникнут проблемы определенного типа.
• Правильные вопросы также существенно помогут в устранении неисправностей. Научитесь быть методичными и тогда вы сможете существенно облегчить себе жизнь и использовать, как логический подход, так и интуитивный.
• Наконец, очень важно не забывать о тестировании, и попытаться изолировать проблему, а для этого необходимо уметь работать с инструментами для устранения неисправностей. При решении сложных проблем вам сможет помочь ваш личный опыт.