Это первая серия статей, посвященная устранению неисправностей TCP/IP, и все последующие статьи будут посвящены основным проблемах, описанных в этой статье.
Если вы хотите ознакомиться с остальными частями статьи, то, пожалуйста, пройдите по ссылкам:
О чем вы думаете, когда слышите фразу «устранение неисправностей с TCP/IP»? Люди, которые обладают хорошим воображением могут сразу представить блок-схему. Люди более прямолинейного склада ума могут увидеть последовательность определенных шагов. А все остальные почувствуют себя потерянно и неадекватно.
Устранение неисправностей, связанных с TCP/IP, должно быть просто, верно? Ведь кроме всего, это всего лишь протокол—серия определенных действий по передачи битов по сети. Но что это за протокол – четыре уровня, и несколько протоколов на каждом из уровней.
Несколько лет назад, когда я впервые узнал о сетевом протоколе TCP/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) – это структурный подход, который охватывает три важных области:
Устранение неисправностей в сетях TCP/IP может быть сложным, но вместе с тем и занимательным. В следующих статьях мы подробно сфокусируемся на этапах отладки и инструментах, которые необходимы для успешного решения проблем, возникающих в вашей сети. До новых встреч и оставайтесь на связи!
www.windowsnetworking.com
Tags: dns, mac, nat, proxy, tun, tunnel, vpn