headermask image
Рекомендую: Фриланс-биржа | Кэшбэк-сервис | Интернет-бухгалтерия

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

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

Проверка возможности соединения

Первое, что нужно сделать, когда возникают проблемы в связи одного узла с другим, – это собрать некоторую информацию о проблеме. Конкретнее, вам нужно задокументировать конфигурацию узла, выяснить, нет ли проблем в связи с какими-нибудь другими машинами в сети, и влияет ли проблема на функционирование других узлов.

Например, предположим, что проблема в связи рабочей станции с конкретным сервером. Сам по себе этот факт не дает достаточно информации для принятия решения. Однако если вы углубитесь в проблему и выясните, что связь рабочей станции прервана со всеми серверами сети, то станет понятно, что надо проверить работоспособность кабелей, порт коммутатора, а, возможно, что проблема в конфигурации сети.

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

Если у нескольких рабочих станций проблема со связью с конкретным сервером, то ее причина, скорее всего, не в рабочих станциях (разве что они были только что переконфигурированы). В первую очередь нужно проверить сам сервер на корректность функционирования.

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

Опрос (PING)

Опрос – возможно, самое простое диагностическое средство для TCP/IP из всех, но информация, получаемая с его помощью, иногда бывает просто неоценимой. Суть его проста: опрос говорит о том, может ли ваша рабочая станция взаимодействовать с другой машиной.

Я рекомендую начать с того, чтобы открыть окно командной строки, ввести команду ping с IP адресом машины, при взаимодействии с которой возникают проблемы. После этого указанная машина должна дать четыре отклика (Рисунок A).

winerr1.jpg

Рисунок A: указанная машина должна дать четыре отклика

Отклики по существу говорят вам о том, сколько времени требуется удаленной машине, чтобы ответить 32 байтами данных. Например, из Рисунка A мы видим, что каждый из четырех откликов был получен менее чем через 4 миллисекунды.

Обычно результатом выполнения команды ping является одно из четырех возможных событий.

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

Второй вариант – для всех четырех запросов превышен интервал ожидания (Рисунок B). Если вы посмотрите на Рисунок A, вы увидите, что каждая строка, уведомляющая об отклике, заканчивается на «TTL=128». TTL обозначает Time To Live – Время жизни. Это значит, что каждый из четырех запросов и откликов должен завершаться за 128 миллисекунд. TTL также уменьшается на единицу для каждого очередного прыжка на обратном пути. Прыжок происходит, когда пакет переходит из одной сети в другую. В дальнейших статьях я много буду про них рассказывать.

winerr2.jpg

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

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

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

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

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

winerr3.jpg

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

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

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

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

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

winerr4.jpg

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

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

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

Заключение

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

Автор: Брайн Позей (Brien Posey)

Постовой

Открылся автосалон Субару в Пензе. Доступные цены, качественное обслуживание и сервис.

В блоге Zebrum вы можете подробно ознакомится с возможностями Zebrum CMS для создания сателлитов и СДЛ.

Похожие посты
  • Решение проблем с соединениями в сетях Windows (часть 6)
  • Ошибка при добавление второго узла в DAG Exchange 2010
  • Решение проблем с соединениями в сетях Windows (часть 2)
  • Решение проблем с соединениями в сетях Windows (часть 3)
  • Решение проблем с соединениями в сетях Windows (часть 5)
  • В domU Xen указатель мыши в консоли VNC показывает неверное положение
  • Решение проблем с соединениями в сетях Windows (часть 4)
  • Ошибка 0x8004FE2F при активации Windows в сети защищенной Forefront TMG 2010
  • Решение ошибки аутентификации клиентов при подключении к Remote Desktop Gateway
  • Настраиваем 2003 Server на обмен маршрутами RIP с роутерами Cisco. Часть 1
  • 5 комментов оставлено (Add 1 more)

    1. TTL определяется первым запросом, и может быть разным. То есть время жизни пакета определяется когда пакет уходит и возвращается, и фигурирует далее в запросе. Так что дословный перевод скорее верен, чем нет. А количество “межсетевых переходов для пакета” значения не имеет.

      1. Kot on September 22nd, 2010 at 12:57 pm
    2. В тексте статьи есть слова: “…каждая строка, уведомляющая об отклике, заканчивается на «TTL=128». TTL обозначает Time To Live – Время жизни. Это значит, что каждый из четырех запросов и откликов должен завершаться за 128 миллисекунд.”
      Нет ли ошибки в утверждении “каждый из четырех запросов и откликов должен завершаться за 128 миллисекунд”?
      Когда я давал команду “ping yandex.ru”, то в зависимости от условий прохождения запроса по сетям получал самые разные значения задержек вплоть до 3999 миллисекунд. И ничего.
      Я полагал, и так пишут в учебниках, что TTL – Time To Live хотя дословно и переводится как “время жить”, но дословный перевод в данном случае неадекватен, а единственным правильным толкованием параметра TTL является “максимально допустимое количество межсетевых переходов для пакета”
      Не так ли?

      2. Александр on October 15th, 2009 at 11:48 pm
    3. Не, даже если ты это все это знаешь, это ещё не значит что ты не чайник :) Слишком тут все элементарно

      3. molse on October 22nd, 2008 at 10:49 pm
    4. Ха! А если я всё это давно знаю, то я уже не чайник!!!? :)

      4. Ксюшка on October 22nd, 2008 at 10:25 pm
    5. :)) прекольна. Для чайникоФФ самый раз :)

      5. Yasha on October 22nd, 2008 at 4:22 pm