Решение проблем с соединениями в сетях Windows (часть 1)

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

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

compare internet security software

Проблемы с сетью и их решение

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

Так или иначе, если время ожидания для всех четырех запросов превышается, это значит, что время TTL закончилось до получения ответа. Это может означать один вариант из трех возможных:

  • Проблемы с соединением, которые не дают возможности передачи пакетов между двумя машинами. Такие проблемы возникают из-за отключения кабеля, ошибок в таблице маршрутизации или тому подобных проблем.
  • Передача информации есть, но она слишком медленная для получения ответа по команде ping. Это может происходить из-за перегрузки сети, неисправного сетевого оборудования или проводки.
  • Передача информации идет, но брандмауэр блокирует ICMP трафик. В таких ситуациях опрос не работает, пока на брандмауэре на целевой машине (а также на всех брандмауэрах на пути к ней) не будут разрешены ICMP эхо-сигналы.

Третье, что может произойти при выполнении команды ping, — ситуация, когда некоторые отклики получены, а некоторые – нет. Это может указывать на неисправности в сетевых кабелях, сетевом оборудовании или на чрезмерную нагрузку сети.

И, наконец, четвертое – когда вы получаете ошибку вроде той, что показана на Рисунке C.

Ping transmit failed

Рисунок C: этот тип ошибки указывает на то, что TCP/IP неверно настроен

Ошибка PING: Transmit Failed (передача не удалась) указывает на то, что TCP/IP неверно настроен на той машине, на которой вы пытаетесь выполнить команду ping. Эта ошибка специфична для Vista. В более старых версиях Windows при неверной настройке TCP/IP ошибка также происходит, но сообщение в таком случае выглядит так: «Destination Host Unreachable» (Заданный узел недоступен)

Что если опрос прошел успешно?

Вообще-то, успешный опрос – вещь совсем нередкая, даже в том случае, когда есть проблемы в соединении двух машин. Такая ситуация означает, что сетевая инфраструктура в полном порядке, и что машины в состоянии взаимодействовать на уровне TCP/IP. Чаще всего это хорошо, так как означает, что проблема не слишком серьезна.

Если обычные соединения между двумя машинами не удаются, но они опрашивают друг друга успешно (необходимо выполнить команду ping на обеих машинах), вы можете попробовать что-нибудь другое. Вместо опроса сетевого узла по IP адресу можно попробовать использовать полное доменное имя узла (Рисунок D).

Ttl и ошибки сети

Рисунок D: попытка опроса узла по полному доменному имени

Если опрос по IP адресу проходит, а по доменному имени – нет, значит, проблема, скорее всего, с DNS. На рабочей станции может быть настроен неправильный DNS, или сервер DNS может не содержать корректной записи для машины, с которой вы пытаетесь наладить связь.

Если вы посмотрите на Рисунок D, вы увидите, что IP адрес узла назначения указан справа от его полного доменного имени. Это доказывает, что машине удалось преобразовать полное доменное имя. Также нужно убедиться в том, что полученный IP адрес верен. Если вы видите IP адрес, отличный от ожидаемого, значит, у вас, видимо, неверна запись об узле в DNS.

Заключение

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

www.windowsnetworking.com

zp8497586rq


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

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 – часть ... [+]