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

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

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам

В предыдущей части этой серии я показывал, как определять, какой 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.

Dns имя должно разрешаться на IP

Рисунок 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 адреса.

Команда nslookup

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

Опрос DNS сервера

Итак, к настоящему моменту мы убедились в том, что коммуникация на уровне IP между локальным компьютером и основным шлюзом работает. Однако это не гарантирует того, что имена узлов разрешаются в IP адреса. В первой части этой серии я показывал, как можно использовать полное доменное имя (FQDN) в сочетании с командой ping для проверки того, что DNS сервер выполняет свою работу. Существует пара других способов, с помощью которых вы легко можете проверить разрешение DNS имен.

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

Команда nslookup

Рисунок C: Следует убедиться в том, что узел может взаимодействовать с вашим DNS сервером

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

Команда nslookup

Рисунок 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 КЭШу требуется определенное время, чтобы узнать о внесенных изменениях.

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

Заключение

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

www.windowsnetworking.com


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

Tags:

Readers Comments (Комментариев нет)




Да человек я, человек! =)




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