Устранение неполадок с подключением в сетях 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 в режиме реального времени