Устранение неполадок с подключением в сетях Windows (часть 3)

• Устранение неполадок с подключением в сетях Windows (часть 1)

• Устранение неполадок с подключением в сетях Windows (часть 2)

• Устранение неполадок с подключением в сетях Windows (часть 4)

• Устранение неполадок с подключением в сетях Windows (часть 5)

подпишитесь на информационный бюллетень обновления статей WindowsNetworking.com в режиме реального времени

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

Первый тест, который вам нужно выполнить, — это пропинговать локальный адрес хоста. Есть несколько различных способов добиться этого. Один из способов — ввести следующую команду:

Когда вы вводите эту команду, Windows пропингует адрес 127.0.0.1. Независимо от IP-адреса вашего компьютера Windows всегда будет использовать 127.0.0.1 в качестве адреса локального хоста. Таким образом, альтернативой приведенной выше команде является простой ввод следующей команды:

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

Рисунок A: Вы должны получить успешный эхо-запрос при попытке пропинговать локальный адрес хоста.

Проверка связи с адресом локального хоста не помогает диагностировать проблемы связи с удаленным хостом. Однако это позволяет вам убедиться, что ваш локальный стек TCP/IP работает правильно. Если вы пингуете адрес локального хоста и получаете сообщение об ошибке «Недоступность хоста назначения», это почти всегда указывает на то, что TCP/IP настроен неправильно или что какая-то часть локального стека TCP/IP повреждена. По моему опыту, обычно эту проблему можно обойти, удалив протокол TCP/IP с компьютера, а затем снова установив его с нуля.

Пропингуйте шлюз по умолчанию

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

Если предположить, что хосты, с которыми вы пытаетесь установить связь, находятся в удаленной сети или в другом сегменте вашей корпоративной сети, то следующее, что вам нужно сделать, это пропинговать шлюз по умолчанию. Этого можно добиться, просто добавив IP-адрес шлюза по умолчанию к команде ping. Например, если вы посмотрите на рисунок B, вы заметите, что в моей конфигурации TCP/IP мой адрес шлюза по умолчанию указан как 147.100.100.100. Я тогда просто пропинговал этот адрес. Это подтверждает, что локальный компьютер может обмениваться данными со шлюзом по умолчанию. Он также сообщает вам, что связь в локальной сети работает должным образом, по крайней мере, на уровне IP-адреса.

Рисунок B: Пинг шлюза по умолчанию подтверждает, что IP-пакеты могут достичь шлюза вашей сети по умолчанию

Пинг DNS-сервера

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

Вы можете увидеть пример этого, показанный на рисунке E.

Важно иметь в виду, что то, что кеш DNS содержит неточные IP-адреса, не всегда означает, что имело место отравление DNS. Иногда узлам назначаются новые IP-адреса, и кэшу DNS требуется некоторое время, чтобы узнать об изменениях.

Рисунок E: Если вы подозреваете, что ваш кеш DNS может содержать неточную информацию, вы должны очистить его

Вывод

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

• Устранение неполадок с подключением в сетях Windows (часть 1)

• Устранение неполадок с подключением в сетях Windows (часть 2)

• Устранение неполадок с подключением в сетях Windows (часть 4)

• Устранение неполадок с подключением в сетях Windows (часть 5)

подпишитесь на информационный бюллетень обновления статей WindowsNetworking.com в режиме реального времени