Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам
В предыдущей части этой серии я показывал, как определять, какой 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.
Рисунок 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 адреса.
Рисунок B: Опрос основного шлюза проверяет, что IP пакеты могут достичь основного шлюза сети
Итак, к настоящему моменту мы убедились в том, что коммуникация на уровне IP между локальным компьютером и основным шлюзом работает. Однако это не гарантирует того, что имена узлов разрешаются в IP адреса. В первой части этой серии я показывал, как можно использовать полное доменное имя (FQDN) в сочетании с командой 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 путем ввода следующей команды:
IPCONFIG /FLUSHDNS
Пример выполнения этой команды показан на рисунке E.
Очень важно помнить, что только тот факт что DNS кэш содержит неточные IP адреса не означает, что имеет место DNS заражение. Иногда узлам присваиваются новые IP адреса, а DNS КЭШу требуется определенное время, чтобы узнать о внесенных изменениях.
Рисунок E: Если подозреваете, что ваш DNS кэш может содержать неточную информацию, то его нужно сброситьВ этой части я объяснил, как можно убедиться в том, что стек локального протокола TCP/IP работает корректно. Затем я рассказал о том, как тестировать способность локального узла связываться с DNS сервером и сервером основного шлюза, и как тестировать разрешение имени хоста. В следующей части этой серии статей я расскажу о других распространенных проблемах, которые можно обнаружить с помощью команды ping, а также начну разговор о проблемах маршрутизации.
www.windowsnetworking.com
Tags: dns