На сегодняшний день и аппаратное, и программное обеспечения надежнее, чем когда-либо, но даже сейчас иногда возникают неполадки. В этой серии статей я хочу обсудить некоторые техники решения проблем, которые вы можете использовать при возникновении проблем при соединении одного узла в сети Windows с другими. Для тех, у кого мало опыта работы с протоколом TCP/IP, я начну с основ, а затем перейду к более передовым техникам.
Проверка возможности соединения
Первое, что нужно сделать, когда возникают проблемы в связи одного узла с другим, - это собрать некоторую информацию о проблеме. Конкретнее, вам нужно задокументировать конфигурацию узла, выяснить, нет ли проблем в связи с какими-нибудь другими машинами в сети, и влияет ли проблема на функционирование других узлов.
Например, предположим, что проблема в связи рабочей станции с конкретным сервером. Сам по себе этот факт не дает достаточно информации для принятия решения. Однако если вы углубитесь в проблему и выясните, что связь рабочей станции прервана со всеми серверами сети, то станет понятно, что надо проверить работоспособность кабелей, порт коммутатора, а, возможно, что проблема в конфигурации сети.
В другом случае, если бы рабочая станция соединялась бы только с некоторыми серверами сети, но не со всеми, это также дало бы вам сведения о том, где именно следует искать источник проблемы. В такой ситуации необходимо было бы выяснить, что общего у тех серверов, связь с которыми прервана. Может быть, они все находятся в одной подсети? Если это так, то, скорее всего, у вас проблема с маршрутизатором.
Если у нескольких рабочих станций проблема со связью с конкретным сервером, то ее причина, скорее всего, не в рабочих станциях (разве что они были только что переконфигурированы). В первую очередь нужно проверить сам сервер на корректность функционирования.
Все дело в том, чтобы с помощью нескольких основных тестов быстро получить полезные сведения о рассматриваемой проблеме. Тесты, которые я собираюсь вам сейчас показать, редко смогут точно указать на причину возникшей проблемы, но они всегда помогут ограничить область поиска этой причины.
Опрос(PING)
Опрос – возможно, самое простое диагностическое средство для TCP/IP из всех, но информация, получаемая с его помощью, иногда бывает просто неоценимой. Суть его проста: опрос говорит о том, может ли ваша рабочая станция взаимодействовать с другой машиной.
Я рекомендую начать с того, чтобы открыть окно командной строки, ввести команду ping с IP адресом машины, при взаимодействии с которой возникают проблемы. После этого указанная машина должна дать четыре отклика (Рисунок A).
Рисунок A: указанная машина должна дать четыре отклика
Отклики по существу говорят вам о том, сколько времени требуется удаленной машине, чтобы ответить 32 байтами данных. Например, из Рисунка A мы видим, что каждый из четырех откликов был получен менее чем через 4 миллисекунды.
Обычно результатом выполнения команды ping является одно из четырех возможных событий.
Во-первых, указанная машина может сгенерировать все четыре отклика. Это означает, что с указанным узлом возможно полноценное взаимодействие на уровне TCP/IP.
Второй вариант – для всех четырех запросов превышен интервал ожидания (Рисунок B). Если вы посмотрите на Рисунок A, вы увидите, что каждая строка, уведомляющая об отклике, заканчивается на «TTL=128». TTL обозначает Time To Live – Время жизни. Это значит, что каждый из четырех запросов и откликов должен завершаться за 128 миллисекунд. TTL также уменьшается на единицу для каждого очередного прыжка на обратном пути. Прыжок происходит, когда пакет переходит из одной сети в другую. В дальнейших статьях я много буду про них рассказывать.
Рисунок B: Если для всех запросов превышено время ожидания, это может означать, что взаимодействие не будет осуществляться
Так или иначе, если время ожидания для всех четырех запросов превышается, это значит, что время TTL закончилось до получения ответа. Это может означать один вариант из трех возможных:
- Проблемы с соединением, которые не дают возможности передачи пакетов между двумя машинами. Такие проблемы возникают из-за отключения кабеля, ошибок в таблице маршрутизации или тому подобных проблем.
- Передача информации есть, но она слишком медленная для получения ответа по команде ping. Это может происходить из-за перегрузки сети, неисправного сетевого оборудования или проводки.
- Передача информации идет, но брандмауэр блокирует ICMP трафик. В таких ситуациях опрос не работает, пока на брандмауэре на целевой машине (а также на всех брандмауэрах на пути к ней) не будут разрешены ICMP эхо-сигналы.
Третье, что может произойти при выполнении команды ping, - ситуация, когда некоторые отклики получены, а некоторые – нет. Это может указывать на неисправности в сетевых кабелях, сетевом оборудовании или на чрезмерную нагрузку сети.
И, наконец, четвертое – когда вы получаете ошибку вроде той, что показана на Рисунке C.
Рисунок C: этот тип ошибки указывает на то, что TCP/IP неверно настроен
Ошибка PING: Transmit Failed (передача не удалась) указывает на то, что TCP/IP неверно настроен на той машине, на которой вы пытаетесь выполнить команду ping. Эта ошибка специфична для Vista. В более старых версиях Windows при неверной настройке TCP/IP ошибка также происходит, но сообщение в таком случае выглядит так: «Destination Host Unreachable» (Заданный узел недоступен)
Что если опрос прошел успешно?
Вообще-то, успешный опрос – вещь совсем нередкая, даже в том случае, когда есть проблемы в соединении двух машин. Такая ситуация означает, что сетевая инфраструктура в полном порядке, и что машины в состоянии взаимодействовать на уровне TCP/IP. Чаще всего это хорошо, так как означает, что проблема не слишком серьезна.
Если обычные соединения между двумя машинами не удаются, но они опрашивают друг друга успешно (необходимо выполнить команду ping на обеих машинах), вы можете попробовать что-нибудь другое. Вместо опроса сетевого узла по IP адресу можно попробовать использовать полное доменное имя узла (Рисунок D).
Рисунок D: попытка опроса узла по полному доменному имени
Если опрос по IP адресу проходит, а по доменному имени – нет, значит, проблема, скорее всего, с DNS. На рабочей станции может быть настроен неправильный DNS, или сервер DNS может не содержать корректной записи для машины, с которой вы пытаетесь наладить связь.
Если вы посмотрите на Рисунок D, вы увидите, что IP адрес узла назначения указан справа от его полного доменного имени. Это доказывает, что машине удалось преобразовать полное доменное имя. Также нужно убедиться в том, что полученный IP адрес верен. Если вы видите IP адрес, отличный от ожидаемого, значит, у вас, видимо, неверна запись об узле в DNS.
Прежде чем начать
Как я объяснял в первой части этой серии статей, моей целью является создание руководства по диагностированию, которому любой пользователь с базовыми знаниями может следовать. В таком случае, я начинаю с базовых приемов диагностики, и по мере написания серии я буду постепенно переходить к более сложным приемам.
Подтверждение наличия соединения
В предыдущей части я показывал основы использования команды PING для тестирования сетевого соединения. Однако если у вас есть проблемы с подключением к другим узлам в сети, или узлам в удаленной сети, то существует еще несколько PING тестов, которые вы можете выполнить, чтобы получить более подробную картину того, что происходит.
Однако прежде чем я покажу вам эти приемы, важно понять, как узел, у которого проблемы с подключением, настроен. Процедура для осуществления этой задачи варьируется от одной версии Windows к другой, поэтому я покажу вам, как проверять конфигурацию сети на машине, на которой используется Windows Server 2003
Первое, что вам нужно сделать, это определить, использует ли проблемная машина конфигурацию статичного или динамичного IP адреса. Для этого откройте панель управления и выберите опцию Сетевые подключения. Теперь правой клавишей нажмите на подключении, которое собираетесь диагностировать, затем выберите опцию Свойства в появившемся меню быстрого доступа. По мере выполнения этих шагов вы увидите страницу свойств, как показано на рисунке A.
Рисунок A: Страница свойств сетевого подключения
Теперь переходите по спискам элементов, используемых подключением, пока не дойдете до TCP/IP протокола (выбран на рисунке A). Выберите этот протокол, нажмите на кнопке Свойства, чтобы открыть страницу свойств для Internet Protocol (TCP/IP), как показано на рисунке B.
Рисунок B: Страница свойств Internet Protocol (TCP/IP) используется для настройки TCP/IP протокола
Как только вы находитесь в этом окне, важно записать IP конфигурацию машины. Особенно важно сделать заметки следующих элементов:
- Использует ли машина статичную или динамичную конфигурацию?
- Если используется статичная конфигурация, запишите значение IP адреса, маски подсети и основного шлюза?
- Получает ли машина адрес DNS сервера автоматически?
- Если адрес DNS сервера вводится вручную, то какой адрес используется?
Прежде чем я продолжу, я также хочу отметить, что если на компьютере установлено несколько сетевых адаптеров, то в панели управления будут перечислены несколько сетевых подключений. Очень важно, чтобы вы знали, какое подключение соответствует какому адаптеру, иначе прием, который я вам собираюсь показать, работать не будет.
Если у вас есть сомнения на счет соответствия определенных подключений определенным адаптерам, то проверьте тип адаптера. Если вы смотрите на рисунок A, вы заметите тип адаптера, записанного в верхней части окна. При необходимости, вы можете открыть корпус и посмотреть, к какому адаптеру подключен кабель, чтобы быть абсолютно уверенным в том, что вы работаете с правильным сетевым подключением.
Теперь, когда вы знаете, как TCP/IP настраивается для сетевого адаптера, нужно определить, принимает ли Windows такую конфигурацию. Для этого откройте окно командной строки и введите следующую команду:
IPCONFIG /ALL
Может показаться странным необходимость в проверке того, понимает ли Windows вашу конфигурацию, но IPCONFIG может на самом деле сказать многое о том, что происходит. Например, посмотрите на рисунок C. Когда вы вводите команду IPCONFIG /ALL, первое, что вам нужно сделать, это определить правильный сетевой адаптер. В этом случае определение нужного адаптера довольно простое, поскольку в списке есть всего лишь один адаптер. Однако обратите внимание, что IPCONFIG предоставляет вам номер подключения (в данном случае это будет Ethernet адаптер, подключение по локальной сети 2). Если вы еще раз взгляните на рисунок A, вы заметите, что заголовок страницы свойств имеет ту же цифру в своем названии. Это вместе с описанием физической сетевой карты говорит вам о том, на какое конкретно подключение вы смотрите.
Рисунок C: Команда IPCONFIG /ALL показывает вам IP конфигурацию машины, как ее видит Windows
Конечно первое, что вы, возможно, заметите на рисунке C, это то, что на нем перечислено много различных IP адресов для подключения. Причина тому кроется в том, что я создал скриншот на веб сервере. Веб сервер размещает несколько веб сайтов, каждый из которых имеет свой собственный IP адрес. Я использовал этот сервер с тем, чтобы показать вам, что конфигурация IP адреса, которую вы видите, когда смотрите на страницу свойств TCP/IP, не всегда такая же, как та, что используется Windows. В этом случае, информация IP конфигурации показанная на рисунке B будет действительной. Она служит в качестве первичного IP адреса машины. Однако есть множество других IP адресов, которые также используются.
Следующий шаг процесса диагностики изменяется в зависимости от того, использует ли машина динамичную или статичную конфигурацию IP адреса. Если машина использует статичную конфигурацию, тогда просто проверьте соответствие IP адреса, маски подсети, основного шлюза и адреса DNS сервера в списке соответствующим компонентам, записанным в странице свойств TCP/IP.
Если машина использует динамичный IP адрес, тогда вам нужно будет посмотреть на адрес и убедиться, что он входит в определенный диапазон адресов. Если вы решаете проблему в незнакомой сети, то вы можете не знать, каков должен быть диапазон адресов. Если дела обстоят именно так, есть несколько значений, на которые следует обратить внимание, и которые имеют определенное значение.
Самым очевидным признаком того, что что-то не так будет IP адрес со значением 0.0.0.0. Наличие такого адреса обычно означает одно из трех:
Сетевой адаптер не подключен к сети (возможно из-за проблем с кабелем или с портом коммутатора)
IP адрес был отпущен
Возник конфликт IP адресов.
Если у вас появился этот адрес, попытайтесь ввести следующие три команды:
IPCONFIG /RELEASE IPCONFIG /RENEW IPCONFIG /ALL
Эти три команды последовательно скажут компьютеру отпустить текущий адрес, попытаться получить новый адрес и покажут вам информацию новой конфигурации. Иногда этот процесс исправляет проблему, а иногда нет. Однако зачастую он может указать вам причину проблемы.
Еще одной ключевой подсказкой о том, что что-то пошло не так, может быть IP адрес, входящий в диапазон 169.254.x.x с маской подсети 255.255.0.0. Некоторые версии Windows будут автоматически использовать этот адрес, если IP адрес невозможно получить с DHCP сервера.
В предыдущей части этой серии я показывал, как определять, какой IP адрес использует ваша система в качестве основного адреса. Следующим шагом в этом процессе будет проверка того, что конфигурация IP адреса работает корректно, и что отсутствуют проблемы с стеком локального протокола TCP/IP.
Первый тест, который вам необходимо выполнить, это отправить ping запрос на адрес локального узла. Существует два различных способа того, как это сделать. Одним способом является ввод команды:
PING LOCALHOST
Когда вы вводите эту команду, Windows отправит ping запрос на адрес 127.0.0.1. Независимо от IP адреса вашей машины, Windows всегда будет использовать 127.0.0.1 в качестве адреса локального хоста. Таким образом, альтернативой вышеприведенной команде является команда:
Ping 127.0.0.1
После ввода этой команды вы должны увидеть результаты успешно выполненного запроса ping, равно как и для других ping команд. Пример использования данной команды показан на рисунке A.
Рисунок A: Вы должны увидеть результат успешно выполненного запроса ping, когда опрашиваете адрес локального хоста
Опрос адреса локального хоста ничего не дает для диагностирования проблем взаимодействия с удаленным узлом. Однако он позволяет убедиться в том, что локальный стек TCP/IP работает корректно. Если вы опросите адрес локального хоста и получите отчет об ошибке, говорящий о том, что с опрашиваемым узлом нет связи, это практически всегда означает неправильную настройку TCP/IP, или что определенная часть локального TCP/IP стека повреждена. На собственном опыте могу сказать, что обычно эту проблему можно решить путем удаления существующего TCP/IP протокола с компьютера, и повторного введения этого протокола.
Опрос основного шлюза
В предыдущей части этой серии я упоминал о том, что существует несколько аспектов TCP/IP настройки, которые вам нужно запомнить или записать и иметь под рукой во время исправления проблем. К этой информации относятся IP адреса основного шлюза или предпочитаемого DNS сервера.
Предположив, что узлы, с которыми вы хотите связаться, расположены в удаленной сети или другом сегменте вашей корпоративной сети, то в этом случае вам нужно попробовать опросить основной шлюз. Это можно выполнить простым добавлением IP адреса основного шлюза в команду ping. К примеру, если вы посмотрите на рисунок B, вы заметите, что в моей конфигурации TCP/IP адрес основного шлюза будет 147.100.100.100. После этого я просто опрашиваю (ping) этот адрес. В результате этого проводится проверка того, что локальная машина может связаться с основным шлюзом. Это также говорит вам о том, что коммуникации на локальном узле работают, как должно, по крайней мере, на уровне IP адреса.
Рисунок B: Опрос основного шлюза проверяет, что IP пакеты могут достичь основного шлюза сети
Опрос DNS сервера
Итак, к настоящему моменту мы убедились в том, что коммуникация на уровне IP между локальным компьютером и основным шлюзом работает. Однако это не гарантирует того, что имена узлов разрешаются в IP адреса. В первой части этой серии я показывал, как можно использовать полное доменное имя (FQDN) в сочетании с командой ping для проверки того, что DNS сервер выполняет свою работу. Существует пара других способов, с помощью которых вы легко можете проверить разрешение DNS имен.
Во-первых, вы можете опросить IP адрес DNS сервера, как показано на рисунке C. Это не гарантирует того, что разрешение имен работает корректно, однако это позволяет убедиться в том, что локальная машина корректно взаимодействует с DNS сервером.
Рисунок C: Следует убедиться в том, что узел может взаимодействовать с вашим DNS сервером
Во-вторых, вы можете использовать команду Nslookup, чтобы убедиться в том, что разрешение имен работает корректно. Для этого просто введите команду Nslookup, за которой должно идти полное доменное имя удаленного узла. Команда Nslookup должна суметь разрешить полное доменное имя в IP адрес, как показано на рисунке D.
Рисунок D: Команда Nslookup говорит вам, способен ли ваш DNS сервер разрешать имя хоста
Вышеприведенный рисунок сначала может ввести в заблуждение, если вы не привыкли к работе с командой Nslookup. Изначально, кажется, что в этом окне есть отчет об ошибке. Однако если присмотреться, видно, что первая часть вернувшейся информации относится к локальному DNS серверу. Это можно сказать, так как указанный IP адрес совпадает с IP адресом DNS сервера. Однако, нижний раздел вернувшейся информации предоставляет вам IP адреса того узла, который вы запрашивали. Если этот IP адрес есть в списке, DNS запрос был успешным.
Если процесс разрешения имени был неудачным, то возникла проблема с DNS. Действительная проблема может быть любой из ряда проблем, связанных с DNS сервером. К примеру, адрес ретрансляции сервера DNS может быть неверным или у DNS сервера может отсутствовать доступ к интернету, который ему необходим для связи с DNS серверами более высокого уровня. Также DNS служба сервера DNS могла быть остановлена. Однако, как правило, такой тип проблем влияет и на других клиентов, поскольку несколько клиентов зависят от одного DNS сервера.
Если DNS разрешение имен успешно, очень важно проверить вернувшийся во время процесса разрешения имени IP адрес. Это можно сделать путем сравнения вернувшегося IP адреса с действительным IP адресом, используемым удаленным узлом. Эти IP адреса должны совпадать, но существуют условия, при которых может возникать несовпадение, в результате чего имеет место сбой коммуникации.
Если вы встретитесь с несовпадением IP адреса, это может указывать на заражение клиента вредоносным ПО, либо это может указывать на заражение DNS. DNS заражение – это процесс, в котором кэш DNS наполняется недействительными или неправильными IP адресами.
Если вы столкнетесь с такой проблемой, то я рекомендовал бы вам просканировать клиентскую машину на предмет вредоносного ПО. Очень важно сканировать на предмет вирусов и шпионских программ, поскольку оба этих типа вредоносного ПО могут вызывать такую проблему. Если на машине не обнаружено вредоносного ПО, попытайтесь сбросить DNS кэш. Вы можете сбросить кэш DNS путем ввода следующей команды:
IPCONFIG /FLUSHDNS
Пример выполнения этой команды показан на рисунке E.
Очень важно помнить, что только тот факт что DNS кэш содержит неточные IP адреса не означает, что имеет место DNS заражение. Иногда узлам присваиваются новые IP адреса, а DNS КЭШу требуется определенное время, чтобы узнать о внесенных изменениях.
Рисунок E: Если подозреваете, что ваш DNS кэш может содержать неточную информацию, то его нужно сбросить
Итак, я показал вам все хитрости, которые вы можете использовать при работе с командой ping для диагностики проблем подключения. В этой части мы продолжим разговор рассмотрением некоторых вариаций этих приемов.
Потеря пакетов
Итак, пока мы использовали команду ping, она была либо успешной, либо безуспешной. В этой ситуации не было третьего варианта. Как вы, возможно, помните, команда ping создана для возврата четырех различных ответов. Иногда, один или более ответов могут не дойти, в то время как остальные остаются успешными. Когда такое случается, этой означает, что произошла потеря пакетов.
В такой ситуации локальный хост или удаленный хост (или оба) функционирует правильно, однако существует условие, вызывающее потерю пакетов во время передачи. Протокол TCP/IP создан так, что может повторять попытку передачи, когда возникает потеря пакета, но потеря пакетов значительно снижает производительность. Низкоскоростное подключение без потери пакетов будет превосходить по производительности высокоскоростное подключение, в котором возникает потеря пакетов.
Коварным в потере пакетов является то, что иногда ее очень трудно обнаружить. Конечно, вы знаете, что была потеря пакетов, если один из ответов ping оказался неудачным, но ICMP пакеты, используемые в командах ping, настолько малы, что могут успешно возвращаться, даже если в сети существует условие, которое способно вызвать потерю пакетов в реальности.
Если вы подозреваете, что потеря пакетов имеет место, однако команда ping не показывает никаких ошибок, вы можете попытаться увеличить размер ICMP пакетов. Пакеты больших размеров более подвержены потерям, если в сети есть проблемы. Вы можете сказать команде ping использовать пакеты больших размеров c помощью переключателя ‘L.
Использование параметра ‘L довольно простое. Все что вам нужно сделать, это ввести команду ping, за которой должен идти адрес, который вы будете опрашивать, а затем нужно поставить параметр ‘L и количество байтов, которое вы хотите отправить. К примеру, ваша сеть испытывает проблемы производительности при подключении к определенному узлу. Вы подозреваете, что имеет место потеря пакетов, но ping постоянно успешен. Следовательно, вы говорите команде ping использовать пакеты размерами по 1024 байт. Для этого нужно использовать следующую команду:
Ping 192.168.1.1 ‘L 1024
Реальный пример использования этой команды показан на рисунке A.
Рисунок A: Добавление переключателя ‘L к команде позволяет увеличивать размер ICMP пакета
Срок жизни пакета (Time To Live)
Следующим понятием, которое я хочу обсудить в связи с командой ping, является срок жизни пакета (Time To Live – TTL). Если вы посмотрите на рисунок A, то обратите внимание, что каждый ping ответ оканчивается на TTL=64.
Как вы, вероятно, знаете, Интернет состоит из огромного количества маршрутизаторов, которые соединены друг с другом. Каждый маршрутизатор подключен как минимум к двум другим маршрутизаторам. Суть такой архитектуры заключается в том, что если соединение дает сбой, должен быть еще как минимум один путь к месту назначения. Проблема такого типа архитектуры заключается в том, что при определенных обстоятельствах сбои соединения могут вызывать ситуацию, в которой пакеты будут ходить по кругу до бесконечности, так и не достигая своей цели назначения.
Именно здесь в игру вступает значение TTL. Подумайте о значении TTL, как о механизме самоуничтожения пакета. Изначально TTL имеет довольно высокое значение, хотя это значение изменяется в зависимости от используемой ОС. Всякий раз, когда пакет проходит через маршрутизатор, он выполняет прыжок. При каждом прыжке значение TTL определяется единицей. Если TTL значение достигает нуля, пакет уничтожается. Это не позволяет потерянным пакетам циркулировать в интернете вечно.
Трассировка маршрута
Еще одна причина, по которой значение TTL так полезно, заключается в том, что инструмент диагностики под названием tracert основывается на нем. Использование команды ping отлично подходит для малых сетей, в которых удаленный узел находится в непосредственной близости от узла отправки, но когда речь заходит о глобальной сети, удаленный узел может располагаться в тысячах миль. В этом случае ICMP пакет, сгенерированный командой ping, должен будет пройти через дюжину маршрутизаторов, чтобы достичь удаленного узла. Иногда можно столкнуться с ситуацией, в которой удаленный хост и локальный хост (или оба) работает корректно, но один из маршрутизаторов на пути имеет проблемы. К счастью, вы можете использовать команду tracert для диагностики такого типа проблем.
Команда tracert, по сути, основана на команде ping. Основная идея команды tracert заключается в том, что она отправляет ICMP пакет на удаленный узел, однако значение TTL установлено в единицу. Это заставляет первый попавшийся на пути маршрутизатор отправлять истекший срок TTL в транзитном сообщении. Это сообщение содержит информацию, идентифицирующую маршрутизатор, который произвел это сообщение. Идентификация маршрутизатора документируется, после чего ICMP снова отправляется, но на этот раз с TTL значением, установленным в два. На этот раз ICMP пакет достигает второго маршрутизатора, прежде чем срок значения TTL истекает. Этот процесс повторяется, каждый раз увеличивая значение TTL на единицу, до тех пор, пока удаленный узел не будет достигнут. Это позволяет просматривать отчет обо всех маршрутизаторах между локальным и удаленным узлом. Иногда можно использовать эту информацию для обнаружения проблем в маршруте, которые могут влиять на поток трафика.
Использование команды tracert очень похоже на использование команды ping. Для этого нужно просто ввести команду tracert, за которой вводится IP адрес или полное доменное имя удаленного узла. На рисунке B показана команда tracert в действии.
Рисунок B: Команду tracert можно использовать для обнаружения потока трафика.
Есть пара моментов, которые необходимо учитывать при использовании команды tracert. Во-первых, на некоторых узлах используются брандмауэры, блокирующие ICMP пакеты. В этом случае будет отображаться серия звездочек, указывающая на то, что трассировка маршрута не смогла получить информацию с определенного узла.
Вторым моментом, который следует учитывать, является то, что как и сами узлы, маршрутизаторы имеют присвоенные им IP адреса. Независимо от того, используются ли эти IP адреса для узлов или маршрутизаторов, они структурируются так, чтобы отражать свое географическое положение. На самом деле, иногда эта географическая информация или даже описание маршрутизатора предоставляется в tracert. Однако если вы хотите большего, существуют инструменты сторонних производителей, которые графически отслеживают команду tracert, основываясь на этой географической информации. Пример такого инструмента показан на рисунке C.
Рисунок C: Можно выполнять визуальную трассировку tracert для определения географического расположения хоста
В предыдущей части этой серии статей, я говорил, что команду TRACERT можно использовать для диагностирования проблем подключения между локальным узлом и узлами удаленной сети. В той части я показал вам, как использовать основную команду TRACERT, поэтому в этой части я продолжу разговор о ней и объясню, как расшифровывать результаты этой команды.
В целях демонстрации я выполнил команду TRACERT для www.espn.com. Единственной причиной, по которой я выбрал данный конкретный сайт, является то, что это один из тех сайтов, которые не блокируют ICMP трафик, и я знаю это наверняка. Результаты этой команды показаны ниже. Я буду ссылаться на эти результаты в течение всей оставшейся части статьи.
C:\Users\Administrator>TRACERT www.espn.com Tracing route to www.espn.com [199.181.132.250] over a maximum of 30 hops: 1 2 ms 1 ms <1 ms 147.100.100.100 2 10 ms 10 ms 9 ms 208.104.224.1 3 9 ms 9 ms 9 ms 208.104.1.13 4 9 ms 8 ms 9 ms 208.104.0.13 5 10 ms 9 ms 10 ms 208.104.0.1 6 11 ms 14 ms 10 ms 165.166.125.193 7 11 ms 10 ms 11 ms gig-1-1-3.core01.ncchrl.infoave.net [165.166.22.61] 8 31 ms 31 ms 30 ms 64.200.130.17 9 38 ms 39 ms 40 ms hrndva1wcx2-pos15-3-oc48.wcg.net [64.200.240.213] 10 31 ms 31 ms 31 ms 64.200.249.170 11 31 ms 30 ms 31 ms 4.68.110.5 12 48 ms 35 ms 35 ms vlan99.csw4.Washington1.Level3.net [4.68.17.254] 13 32 ms 31 ms 33 ms ae-92-92.ebr2.Washington1.Level3.net [4.69.134.157] 14 60 ms 53 ms 54 ms ae-2.ebr3.Chicago1.Level3.net [4.69.132.69] 15 86 ms 71 ms 70 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61] 16 137 ms 103 ms 102 ms ae-2.ebr2.Seattle1.Level3.net [4.69.132.53] 17 95 ms 95 ms 95 ms ae-23-52.car3.Seattle1.Level3.net [4.68.105.36] 18 94 ms 95 ms 95 ms WALT-DISNEY.car3.Seattle1.Level3.net [4.71.152.22] 19 * * * Request timed out. 20 97 ms 95 ms 98 ms 199.181.132.250 Trace complete.
Если вы посмотрите на вышеприведенные данные TRACERT, то заметите, что каждая строка результатов содержит несколько различных частей информации. Первая часть информации, расположенная с левой стороны показывает номер прыжка. Как я объяснял в предыдущей части, TRACERT работает путем отправки запроса ping на указанный хост. Изначально TTL значение запроса установлено на 1. Это обеспечивает сбой запроса после первого прыжка. Информация о прыжке предоставляется, после чего ICMP запрос передается снова, но на этот раз его TTL значение установлено на 2. Этот процесс повторяется снова и снова, каждый раз увеличивая TTL значение на 1 до тех пор, пока указанный узел не будет достигнут. Благодаря этому команда TRACERT способна давать информацию о том, сколько прыжков запросу пришлось сделать, чтобы достичь удаленного узла. Если вы посмотрите на данные выше, вы увидите, что последняя цифра в левом ряду будет 20. Это означает, что запросу потребовалось выполнить 20 прыжков, чтобы достичь указанного узла.
Следующие три части информации в каждой строке отображают количество времени, которое потребовалось, чтобы достичь маршрутизатора или узла, на который ссылается конкретная строка. Если вы просмотрите список, то заметите, что время соединения, как правило, увеличивается с каждым прыжком. Вам нужно знать две вещи об этом времени.
Во-первых, отображаются три различных временных промежутка для каждого прыжка. Как я уже говорил, трассировка маршрута основана на концепции отправки нескольких ICMP запросов. Когда мы работали с командой ping, вы видели, что она всегда возвращалась с различными значениями, как способом измерения потери пакетов. Эта же концепция применима и для трассировки маршрута, за исключением того, что длительность времени, необходимая запросу, измеряется три раза, а не четыре.
Второе, что вам нужно знать о времени ответа, это то, что звездочки указывают на то, что время запроса вышло. Это может указывать на проблему, а может и не указывать, в зависимости от того, как появляются звездочки. Если вы посмотрите на прыжок номер 19, то увидите, что все три времени ответа представлены звездочками. Когда вы видите три звездочки подряд, это обычно означает, что устройство, которое опрашивается во время прыжка, имеет файервол, настроенный на блокирование ICMP пакетов, что вызывает таймаут таймеров, а в последнем столбце будет надпись «Превышен интервал ожидания для запроса».
Следует учитывать, что, хотя это самый распространенный случай, он не единственный. Трассировка маршрута также выдает три звездочки, когда нужное устройство недоступно. Конечно, здесь возникает вопрос, как отличить сайт, блокирующий ICMP пакеты, от сбоя в соединении? На самом деле это может быть довольно сложным делом.
На первый взгляд сбой в соединении выглядит идентично ситуации, когда маршрутизатор или узел блокирует ICMP запросы. Когда возникает сбой, вы не увидите сообщений об ошибке. На самом деле процесс заканчивается стандартным сообщением «Трассировка завершена».
Существует два отличных знака, указывающих на сбой в соединении. Одним знаком будет результат, в котором по достижении определенной точки все последующие запросы будут возвращаться с превышенным интервалом ожидания. Другим знаком будет ситуация, в которой команда TRACERT выполняет все 30 прыжков. Ни один из этих знаков, однако, не гарантирует наличие сбоя соединения, даже если они встречаются вместе. К примеру, мой веб сайт (www.brienposey.com) отлично работает на данный момент, и все же, когда я запускаю команду TRACERT на нем, оба этих симптома присутствуют в результате:
C:\Users\Administrator>TRACERT www.brienposey.com Tracing route to www.brienposey.com [24.235.10.4] over a maximum of 30 hops: 1 1 ms 1 ms <1 ms 147.100.100.100 2 8 ms 12 ms 8 ms 208.104.224.1 3 9 ms 8 ms 9 ms 208.104.1.9 4 10 ms 9 ms 8 ms 208.104.0.9 5 10 ms 12 ms 11 ms 208.104.0.5 6 12 ms 10 ms 9 ms 165.166.18.1 7 15 ms 23 ms 13 ms gig2-2-1.c01.scclma.infoave.net [165.166.22.17] 8 13 ms 12 ms 13 ms 66.192.166.9 9 31 ms 30 ms * peer-01-ge-0-0-0-1.asbn.twtelecom.net [64.129.249.10] 10 56 ms 57 ms 55 ms bb2-p6-0.ipltin.sbcglobal.net [151.164.242.59] 11 55 ms 53 ms 55 ms ded2-g8-0.ipltin.sbcglobal.net [151.164.42.159] 12 59 ms 56 ms 56 ms Winnet-1148485.cust-rtr.ameritech.net [66.73.221.254] 13 64 ms 63 ms 68 ms 216-24-2-237.ip.win.net [216.24.2.237] 14 68 ms 68 ms 64 ms fa0-0.cust-gw2.noc.win.net [216.24.30.69] 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete.
Если вы видите результаты, подобные этим, они могут указывать на то, что возник сбой соединения, но они этого не гарантируют. Единственным способом убедиться в этом, является попытка выполнить команду TRACERT к нескольким сайтам. Следует помнить, что каждый последующий прыжок находится все дальше от вас. Чем дальше от вас находится проблема, тем сложнее будет ее определить, поскольку тестирование других сайтов может включать другие маршруты. Когда вы выполняете TRACERT для различных сайтов, вам нужно обращать внимание на маршруты, по которым проходит запрос, чтобы определить, имеет ли место сбой в соединении.
Последняя часть информации, отображаемая в каждом ряду, - это данные о маршрутизаторе или узле, который ответил на ICMP запрос. TRACERT будет определять каждый узел или маршрутизатор по названию, когда это возможно, но вы не всегда будете получать полное разрешение имени. Например, если посмотреть на вышеприведенные результаты, видно, что половина маршрутизаторов определена по названию, а вторая половина нет. Это, как правило, не является проблемой.
Самое интересное то, что узел, для которого вы выполняете трассировку маршрута, не всегда будет определяться. Например, если взглянуть на самое начало первого примера, вы заметите, что мы ввели команду TRACERT WWW.ESPN.COM. Сразу же после этого TRACERT разрешила название www.espn.com в IP адрес 199.181.132.250. Но если вы посмотрите в самый конец этого примера, то обратите внимание на то, что TRACERT постепенно достигает места назначения, но не определяет место назначения по названию (по крайней мере, не в этом случае).
Такое поведение не является проблематичным, поскольку так и должно быть. Причина, по которой я показал вам это, заключается в том, что если вы выполняете команду TRACERT к сайту, вы не должны думать, что процесс был неудачным только потому, что узел назначения не был определен по названию.
Итак, в этой серии я рассказал вам, как диагностировать массу проблем, связанных с соединениями. Этой статьей я завершаю эту серию, рассказывая, как проблемы с таблицами маршрутизации Windows могут вызывать проблемы с соединениями.
Во всей серии я много говорил о маршрутизации. Специально для новичков в сетевых технологиях: маршрутизатор – это устройство, позволяющее пакетам путешествовать от одного сегмента сети к другому. Маршрутизатор всегда связан как минимум с двумя сегментами сети, но часто случается, что он связан с несколькими сегментами. И в этом случае маршрутизатор должен знать способ вычисления сегмента, которому нужно передавать пакет, чтобы тот достиг назначения. И тут в игру вступают таблицы маршрутизации.
Таблицы маршрутизации позволяют маршрутизаторам принимать решения о пересылке пакетов, но вы можете и не знать, что существуют также таблицы маршрутизации, встроенные в операционную систему Windows. Вы можете увидеть эти таблицы маршрутизации, открыв командную строку и введя команду ROUTE PRINT, как показано на Рисунке A.
Рисунок A: Таблицы маршрутизации Windows
На первый взгляд, изображение экрана выше может показаться пугающим. Но вы должны помнить, что я сделал его в Windows Vista. В Windows Vista информация о маршрутизации IPv6 смешана со стандартной информацией IPv4. Если бы вы попробовали команду Route Print в одной из предыдущих версий Windows, информация IPv6 отсутствовала бы, поэтому все выглядело бы проще.
Однако и в нашем варианте с IPv6, информация о маршрутизации не так сложна, как кажется на первый взгляд. Как видно из рисунка, информация о маршрутизации разделена на три раздела: интерфейсный список, таблица маршрутизации IPv4 и таблица маршрутизации IPv6. В данной статье я не буду рассматривать таблицу IPv6, так как пока еще немногие используют IPv6 в данный момент.
Список интерфейсов
Список интерфейсов создан, чтобы показать вам все сетевые интерфейсы, которые видит Windows. Я изолировал секцию списка интерфейсов на выходе на Рисунке B.
Рисунок B: В списке интерфейсов перечислены все сетевые адаптеры машины
Если вы посмотрите на рисунок выше, вы увидите, что первые два элемента списка соответствуют физическим сетевым адаптерам. Тот факт, что эти адаптеры присутствуют в списке, указывает на то, что:
- Windows видит адаптер.
- Для адаптера установлен драйвер.
- Windows считает адаптер возможным путем для трафика IPv4.
Третий элемент, показанный в списке, - это адаптер обратной связи. Это не физический сетевой адаптер, а логический механизм, используемый Windows для внутренних взаимодействий. Адаптер обратной связи обязан присутствовать всегда для нормальной работы Windows. Если он отсутствует, я бы предложил удалить различные сетевые компоненты и переустановить их.
Четвертый элемент в списке на Рисунке B – это адаптер 6TO4. Это логический механизм, используемый Windows для маршрутизации трафика IPv6 через сеть IPv4. Этот механизм присутствует только в Windows Vista.
Остальные элементы в списке указывают на то, что IPv6 связан с двумя физическими сетевыми адаптерами машины.
Таблицы маршрутизации
Хотя иногда бывает полезным иметь возможность проверить, признает ли Windows существование ваших сетевых адаптеров, именно таблицы маршрутизации полностью определяют, куда будет направлен трафик. На Рисунке C показано, как выглядят таблицы маршрутизации IPv4.
Рисунок C: Таблица маршрутизации IPv4
Таблицы маршрутизации, показанные выше, немного сложнее, чем те, с которыми вы будете обычно работать, так как машина, с которой брались снимки, содержит несколько сетевых адаптеров. Однако, вне зависимости от того, как настроена ваша машина, в таблице маршрутизации должны обязательно присутствовать некоторые записи. На схеме ниже перечислены все эти записи, а также указано их значение:
| Сетевой адрес | Описание |
| 0.0.0.0 | Это маршрут по умолчанию, используемый, когда не найдено других возможных маршрутов. |
| 127.0.0.0 | Это адрес обратной связи, используемый для внутренних взаимодействий. |
| 147.100.0.0 | Это адрес локальной подсети. В данном конкретном случае, этот адрес относится к моей сети, так как мои адреса находятся в адресном диапазоне 147.100.x.x. Если бы в моей сети использовался более привычный диапазон 192.168.1.x, тогда это значение было бы 192.168.1.0. |
| 147.100.100.40 | Это IP адрес, связанный с моей сетевой картой. Опять же, этот адрес относится только к моей подсети, но у вас также должны быть запись, отражающая ваш IP адрес. |
| 147.100.255.255 | Это адрес широковещательной рассылки для подсети. Опять же, этот адрес для конкретно моей подсети. Просто чтобы показать, как он может выглядеть, в случае, если вы используете более обычный диапазон 192.168.1.x, этот адрес был бы 192.168.1.255. |
| 224.0.0.0 | Это адрес групповой передачи Windows. |
| 255.255.255.255 | Это адрес ограниченной широковещательной рассылки Windows . |
Как вы видите, некоторые из адресов в таблице выше относятся к конкретной сети. Если вам нужна помощь в понимании предназначения этих адресов, вы можете использовать команду IPCONFIG /all, чтобы узнать, как настроен TCP/IP для каждого сетевого адаптера. Вы сможете использовать эту информацию, чтобы определить адреса, которые нужно использовать в таблицах маршрутизации.
Нужно помнить также, что если ваша система использует несколько сетевых адаптеров, вам нужно иметь несколько записей для каждого конкретного сетевого адаптера. К примеру, если вы посмотрите на рисунок выше, вы заметите несколько записей в диапазоне 196.254.x.x. Эти адреса соответствуют второму сетевому адаптеру моей системы.
Теперь, когда вы знаете, чего ожидать от таблиц маршрутизации, встает вопрос, что нужно делать в том случае, если информация в ваших таблицах маршрутизации неверна или неполна. В такой ситуации у вас два выхода. Вы можете либо удалить и переустановить сетевые компоненты Windows, либо вручную исправить таблицу маршрутизации.
Если вас заинтересовала реконструкция таблиц маршрутизации, или вам просто хочется узнать больше об этих таблицах, о том, что означают различные колонки в этих таблицах, я рекомендую прочитать мою статью Making Sense of Windows Routing Tables.
Заключение
В этой серии статей я объяснил, что, хотя много чего было предпринято Microsoft для упрощения сетевого взаимодействия, при этом все еще могут возникать ошибки. Затем я рассказал, как вы можете использовать встроенные в Windows средства для решения различного типа проблем с соединениями.