Устранение неисправностей TCP/IP: Структурный подход

О чем вы думаете, когда слышите фразу "устранение неисправностей с TCP/IP"? Люди, которые обладают хорошим воображением могут сразу представить блок-схему. Люди более прямолинейного склада ума могут увидеть последовательность определенных шагов. А все остальные почувствуют себя потерянно и неадекватно. Устранение неисправностей, связанных с TCP/IP, должно быть просто, верно? Ведь кроме всего, это всего лишь протокол—серия определенных действий по передачи битов по сети. Но что это за протокол – четыре уровня, и несколько протоколов на каждом из уровней.

Традиционный подход

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

• Напечатать команду ipconfig для проверки правильности вашего IP адреса, маски подсети (subnet mask) и шлюза по умолчанию (default gateway).
• Затем запустить команду ping 127.0.0.1. для того, чтобы убедиться, что ваш сетевой адаптер (network adapter) находится в рабочем состоянии.
• Затем запустить команду ping для IP адреса вашего собственного компьютера.
• Затем запустить команду ping для IP адреса другого компьютера, находящегося в той же самой подсети (subnet).
• Затем попытаться запустить команду ping для вашего шлюза по умолчанию (default gateway) (ближний интерфейс маршрутизатора (router), который подключает вашу подсеть (subnet) к остальной сети).
• Затем попытаться запустить команду ping для IP адреса компьютера в другой подсети.
• И так далее.

Я называю этот подход безмозглым, или "brain-dead approach", т.к. он настолько методичен, что вы можете просто отключить свои мозги и просто выполнять последовательность шагов. Он также в некотором роде неэффективен, т.к. он автоматически подразумевает, что ваша проблема наиболее вероятно связана с ваши собственным компьютером и тем, что близко к вам расположено (ваше сетевая карта, конфигурация IP адреса вашего компьютера, ваша локальная подсеть), а не с тем, что находится подальше (другие посети). И вероятнее всего, этот метод был разработан до того, как появился интернет, до того, как DNS стал повсеместным для определения имени, и до того, как брандмауэры (firewalls) и VPN стали необходимой частью большинства корпоративных сетей (corporate networks).

За примером далеко ходить не надо – один из ваших пользователей заявляет: «Я сейчас не могу подключиться к серверу". В чем может быть проблема? Достаточно проанализировать это простое предложение, чтобы попробовать понять, в чем может заключаться проблема. Например:

"Я не могу…"

Это единственный пользователь, который сообщил о проблемах в сети? Есть еще пользователи, которые столкнулись с подобными проблемами? Если есть, то вы не должны использовать безмозглый подход (brain-dead approach) и начинать устранение неисправностей с компьютера пользователя. Вместо этого наиболее вероятно, что проблема где-то дальше, например, может быть, выключен ваш сервер DNS server, или же ваш поставщик услуг DNS испытывает временные трудности. Или может быть, маршрутизатор вашей внутренней сети сошел с ума и не пропускает пакеты. Или может быть сервер, к которому пытаются подключиться пользователи, сломался.

Вам стоит также остановиться и подумать о схожести проблем, которые возникли у пользователей. Например, находятся ли их компьютеры в одной подсети? Если да, то, может быть, шлюз по умолчанию для этой подсети неправильно настроен, или сломался маршрутизатор. Или может быть, случайно был поврежден сетевой кабель, который подключает подсеть к основному Ethernet маршрутизатору сети. Или, может быть, некий злоумышленник установил нестандартный DHCP сервер в этой подсети, который переназначил компьютерам новые адреса, для создания атаки типа отказ в обслуживании.

Если это единственные пользователь, у которого возникла такая проблема, то, вероятней всего, пришло время применить безмозглый подход и начать задавать вопросы типа: "Хорошо, а ваш компьютер включен? Сетевой кабель подключен к задней части вашего компьютера?". И все в таком духе.

"…подключиться к …"

Неплохо бы задать также пользователю такой вопрос: "А что вы подразумеваете под словом подключиться?" Это необходимо сделать потому, что слово "подключиться" – это техническое слово, которое пользователи часто используют для того, чтобы впечатлить специалиста службы поддержки своими знаниями в этой области. Но, как показывает практика, эти знания обычно отсутствуют. Почему? Потому, что существуют различные типы подключений, включая соединения на уровне MAC, сессии TCP, аутентификация с помощью пароля (password-authentication), права и привилегии на доступ, соединения NAT-traversal, прохождение брандмауэра (firewall pass-through), сессии прикладного уровня (application-level sessions), и так далее. С каким из типов соединения у вас обычно возникают проблемы? Что они обычно пытаются сделать, когда говорят, что хотят подключиться к серверу? Пытаются ли они получить доступ к общей папке на этом сервере? Получают ли они при этом в ответ сообщение "Access denied (доступ запрещен)"? Или же у них появляется окно, требующее ввести имя пользователя и пароль? Или же не подходит их имя пользователя и парольs? Или у них возникли проблемы с поиском общей папки в Active Directory? Может быть у них возникли проблемы с диском (mapped drive)? Может быть у них не получается найти сервер в сетевом окружении (My Network Places)? И так далее.

Возникли ли у них проблемы с подключением к серверу, или они пытаются подключиться к чему-либо еще в сети (network)? Определение границ проблемы здесь очень важно: не удается подключиться к одному серверу или же к нескольким?

"…сервер…"

У вас есть пользователь, сервер и сеть между ними. Они не могут подключиться друг к другу. Почему? Хорошо, а где точно находится сервер? Находится ли он в подсети пользователя? В смежной подсети? В другом структурном подразделении? На другом этаже? В другом здании? На другом континенте? Какой тип сети связывает пользователя с соответствующим сервером? Проводная Ethernet LAN? Беспроводная wireless LAN (WLAN)? Обычная линия T1 line? Frame Relay? Туннель VPN tunnel через Интернет (Internet)? Телефонное модемное (dial-up modem) соединение? Кабельный модем или DSL? Сперва определите тип соединения (возможно несколько типов) между пользователем и сервером, а затем уже начинайте думать, что и где могло сломаться. Может быть, сломался CSU/DSU пытаясь соединиться с поставщиком услуг (service provider), который контролирует его. Может быть, уборщица наводила порядок серверной комнате и случайно выключила Ethernet переключатель (switch). Проверьте поступление сообщений тревоги от вашего программного обеспечения по управлению сетью (network management software), в этом случае мы предполагаем, что вы используете управляемые переключатели (managed switches). Может быть, возникли перебои с питанием в удаленном дочернем офисе, в котором располагается сервер. Позвоните им по телефону и спросите, что случилось.

И это сервер или сервера? У пользователя возникли проблемы с подключением к этому серверу или же к другим серверам тоже? У других пользователей возникли подобные проблемы с подключением к другим серверам? Какие есть взаимосвязи (если они есть) между всеми проблемными серверами? (или вероятно проблемными - помните, что проблема может быть с компьютером пользователя или с самой сетью, что более вероятно.)

"…в настоящий момент."

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

Время может также помочь вам связать проблему с другими обстоятельствами, касающимися вашей сети. Возникла ли эта проблема сегодня утром в 10 часов? Что еще случилось с вашей сетью network? Устанавливались ли новые обновления на WSUS сервер? Была ли запланирована поддержка контролера домена? Производились ли ремонтные работы в здании в этот момент времени?

Структурный подход

Мой собственный подход в устранении неисправностей TCP/IP (troubleshooting) – это структурный подход, который охватывает три важных области:

1. Определение проблемных единиц. Это означает:
• Сторона клиента: клиент или клиенты, у которого возникли трудности или трудность.
• Сторона сервера: сервер, принтер или другие сетевые ресурсы (например, интернет), с которым возникли трудности у клиента.
• Сеть между ними (Network): проводная (wires) или беспроводная (wireless), маршрутизаторы (hubs), переключатели (switches), роутеры (routers), брандмауэры (firewalls), прокси сервера (proxy servers) и любая другая инфраструктура (infrastructure) между стороной клиента и стороной сервера.
• Окружение: внешние обстоятельства, которые могут влиять на вашу сеть, например, перебои с питанием, ремонтные работы по зданию и т.д.
• Область: может быть вовлечен один или несколько клиентов и серверов.
• Временной фактор: повторяющиеся, временные, случайные; время начала и т.д.
• Тип проблемы с соединением: физическая (Physical), сетевая (network), на транспортном или прикладном уровне (transport or application layer), проблема с аутентификацией или контролем доступа и т.д.
• Признаки: сообщения об ошибках на клиентских компьютерах; меню для входа и т.д.

1. Определение необходимых этапов отладки, для решения проблем с вышеперечисленными элементами. Это включает в себя:
• Проверка физического соединения для аппаратного обеспечения клиента, сервера и сетевой инфраструктуры. Это означает проверку кабелей, установки сетевых адаптеров проверка других соединений.
• Проверка конфигурации TCP/IP аппаратного обеспечения клиента, сервера и сетевой инфраструктуры. Для клиентов и серверов это означает проверку IP адреса, маски подсети, шлюза по умолчанию, параметров DNS и так далее. Для сетевой инфраструктуры это обычно означает проверку таблиц маршрутов на маршрутизаторах и интернет шлюзах .
• Проверка соединения между клиентом и сервером. Это означает использование инструментов ping, pathping, tracert, и других аналогичных средств для проверки end-to-end TCP/IP соединения на сетевом уровне; сетевой анализ пакетов (packet sniffing) для проверки сессий на транспортном уровне; использование nslookup, telnet и других инструментов для устранения неисправностей на прикладном уровне, устранения проблем, связанных с распознаванием имен и аутентификацией.

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

Маршрутные таблицы для сервера Single-Homed Server с одним IP адресом

Следующая маршрутная таблица предназначена для сервера, у которого один IP адрес 172.16.11.30 в сети 172.16.11.0/24:

 

C:\>route print

 

IPv4 Route Table

===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x10003 ...00 03 ff 25 88 8c ...... Intel 21140-Based PCI Fast Ethernet Adapter

(Generic)

===========================================================================

===========================================================================

Active Routes:

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 172.16.11.1 172.16.11.30 20

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

172.16.11.0 255.255.255.0 172.16.11.30 172.16.11.30 20

172.16.11.30 255.255.255.255 127.0.0.1 127.0.0.1 20

172.16.255.255 255.255.255.255 172.16.11.30 172.16.11.30 20

224.0.0.0 240.0.0.0 172.16.11.30 172.16.11.30 20

255.255.255.255 255.255.255.255 172.16.11.30 172.16.11.30 1

Default Gateway: 172.16.11.1

===========================================================================

Persistent Routes:

None

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

Каждая запись в маршрутной таблице разбивается на пять полей:

• Network Destination. (Конечная сеть) IP адрес или подсеть (subnet), отображающая возможный пункт назначения, куда будут передаваться IP пакетов.
• Netmask. (Маска сети) Битовая маска, используемая для соответствия поля пункта назначения в пакете IP адресу одной из возможных сетей, упомянутых выше.
• Gateway. (шлюз) IP адрес, на который будут передаваться пакеты, для того чтобы достигнуть пункта назначения.
• Interface. (интерфейс) Интерфейс (next-hop interface), который необходимо использовать для передачи пакета в пункт назначения (destination network).
• Metric. (метрика) Отражает стоимость маршрута.

Пример 1: Пункт назначения находится в локальной подсети

Для нашего первого примера предположим, что наш сервер (172.16.11.30) должен послать пакет на другой компьютер с IP адресом 172.16.11.80, который находится в той же самой подсети. Поэтому этот пакет будет иметь адрес источника (source address) 172.16.11.30 и адрес приемника (destination address) 172.16.11.80. Ниже приведено описание, как Windows использует маршрутную таблицу для определения используемого маршрута:

1. Сперва, Windows берет каждый маршрут из таблицы и выполняет побитовое сравнение адреса приемника (destination address) в пакете (172.16.11.80) с маской сети (Netmask) выбранного маршрута. Ниже приведены результаты, где каждому маршруту в таблице определен пункт назначения (network destination):

Route (маршрут)	Netmask (маска сети)	172.16.11.80 AND Netmask
0.0.0.0	0.0.0.0	0.0.0.0
127.0.0.0	255.0.0.0	172.0.0.0
172.16.11.0	255.255.255.0	172.16.11.0
172.16.11.30	255.255.255.255	172.16.11.80
172.16.255.255	255.255.255.255	172.16.11.80
224.0.0.0	224.0.0.0	160.0.0.0
255.255.255.255	255.255.255.255	172.16.11.80

1. Затем для каждого маршрута результат такого объединения сравнивается с полем Network Destination (пункт назначения) маршрута, и соответствие означает, что маршрут можно использовать для передачи пакета на место назначения. Если было найдено более одного маршрута, то Windows использует маршрут, с наиболее длинным совпадением (маршрут, у которого значение Netmask имеет наибольшее значение 1 бита). Если такого совпадения не находится, то Windows использует маршрут с наименьшей стоимостью или метрикой (Metric). Наконец, если несколько маршрутов имеют одинаковую стоимость, то Windows произвольно выбирает один из них для использования. Из таблицы выше вы можете увидеть, что результатом этого процесса объединения стало два совпадения (маршруты 1 и 3), поэтому Windows выбирает тот, который имеет наиболее длинное совпадение, т.е. 3. Результатом этого является то, что теперь Windows знает, какой маршрут нужно использовать для того, чтобы доставить пакет в место назначения. Ниже представлено, как выглядит этот маршрут в маршрутной таблице сервера:

Network Destination Netmask Gateway Interface Metric

172.16.11.0 255.255.255.0 172.16.11.30 172.16.11.30 20

Далее Windows использует следующий алгоритм, чтобы определить, что делать дальше:

A. Если поле Gateway (шлюз) в маршруте соответствует адресу одного из сетевых интерфейсов (network interface) на сервере (или если шлюз на задан), то Windows посылает пакет напрямую в место назначения, используя интерфейс, указанный в маршруте.

B. Если поле Gateway (шлюз) в маршруте не соответствует адресу ни одного из сетевых интерфейсов на сервере, то Windows посылает пакет по адресу, который указан в поле Gateway в маршруте.

Понятно, что в нашем случае будет использоваться вариант A, т.к. поле Gateway (шлюз) в маршруте (172.16.11.30) – это адрес, назначенный единственной сетевой карте сервера. Поэтому Windows определяет, что адрес места назначения принадлежит локальной подсети, а это значит, что Windows может послать пакет напрямую, не пересылая его никаким маршрутизаторам. Поэтому в этом случае, Windows просто посылает пакет на адрес 172.16.11.80 с помощью сетевого интерфейса сервера 172.16.11.30 network interface, а получающий компьютер получает его.

Пример 2: Пункт назначения находится в удаленной подсети

Теперь давайте проведем тот же самый эксперимент, только в этот раз предположим, что сервер пытается послать пакет на компьютер, который находится в другой подсети, например, компьютер имеет адрес 172.16.10.200. Другими словами, у пакета адрес источника (source address) 172.16.11.30, а адрес приемника (destination address) 172.16.10.200. Ниже представлено, как Windows использует маршрутную таблицу для определения маршрута для пакета:

1. Windows берет каждый маршрут из таблицы и выполняет побитовое сравнение AND между адресом места назначения (destination address) в пакете (172.16.10.200) и маской подсети маршрута. Результаты будут выглядеть примерно так:

Route (маршрут)	Netmask (маска сети)	172.16.11.80 AND Netmask
0.0.0.0	0.0.0.0	0.0.0.0
127.0.0.0	255.0.0.0	172.0.0.0
172.16.11.0	255.255.255.0	172.16.10.0
172.16.11.30	255.255.255.255	172.16.10.200
172.16.255.255	255.255.255.255	172.16.10.200
224.0.0.0	224.0.0.0	160.0.0.0
255.255.255.255	255.255.255.255	172.16.10.200

1. Для каждого маршрута результат объединения AND сравнивается с полем Network Destination (место назначения), а соответствие означает, что данный маршрут (route) можно использовать для передачи пакета. Из нашей второй таблицы, которая изображена выше, вы можете увидеть, что в этот раз имеется только одно соответствие, т.е. у нас только одна строка, в которой поле Network Destination (место назначения) 0.0.0.0 соответствует результату сравнения AND. Поэтому путь, который Windows будет использовать для передачи пакета будет следующим:

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 172.16.11.1 172.16.11.30 20

1. Затем Windows использует алгоритм, который был описан выше, для того, чтобы принять решения, что делать далее. И в этот раз нам подходит условие B, т.к. поле шлюз Gateway в маршруте (172.16.11.1) не соответствует адресу, который присвоен единственной сетевой карте сервера, который в нашем случае 172.16.11.30. Поэтому Windows определяет, что адрес места назначения находится в удаленной подсети (remote subnet), а, следовательно, Windows не может послать пакет напрямую, а должен передать пакет маршрутизатору, который позаботится о том, что бы передать его дальше по цепочке. Поэтому в этом случае Windows посылает пакет по адресу, который находится в поле Gateway в выбранном маршруте (172.16.11.1) с помощью сетевого интерфейса сервера 172.16.11.30. После того, как маршрутизатор по адресу 172.16.11.1 получит пакет, он определит, какие действия необходимо предпринять для того, чтобы дальше передать пакет в конечный пункт назначения по адресу 172.16.10.200, а это, конечно, зависит от того, является ли сеть 172.16.11.10/24 соседней для подсети 172.16.11.11/24 (т.е. подключена к ней через один маршрутизатор) или удаленной подсетью, т.е. подключена с помощью нескольких маршрутизаторов, с промежуточными сетями.

Подсказки для устранения неисправностей

Что же может случиться в описанном выше процессе? Во-первых, есть вероятность того, что Windows не сможет выбрать маршрут, у которого поле Network Destination (место назначения) соответствует результату побитового сравнения AND поля Netmask (маска сети) маршрута и места назначения в пакте. Если такое произойдет, то у вас возникнет ошибка маршрутизации, результатом которой, вероятно, будет ошибка в сетевом приложении, запущенном на вашем сервере. Это происходит обычно, когда Windows использует TCP для уведомления верхнего уровня сетевого стека, что пакет не может быть послан.

В такой ситуации, у вас, вероятно, поврежденная маршрутная таблица (corrupt routing table) или несуществующий маршрут, который находится в вашей маршрутной таблице. Постоянные маршруты – это маршруты, которые вы добавляете в таблицу с помощью команды route -p add, и который остается после перезагрузки, т.к. эго параметры хранятся в реестре. Если вы добавляете неправильный маршрут, то могут появляться весьма странные ошибки, в результате которых трафик может загадочным образом исчезать.

С другой стороны, если пункт назначения находится в удаленной сети, а Windows передает пакет маршрутизатору (адрес шлюза по умолчанию), а этот маршрутизатор не может выбрать маршрут, то в этом случае маршрутизатор вернет ошибку ICMP "Destination Unreachable – Host Unreachable" (компьютер не найден) компьютеру, который послал пакет. В этом случае, TCP уведомит верхние слои (upper layers) и возникнет сообщение об ошибке.

В любой ситуации лучшим способом для устранения ошибки будет проверка маршрутных таблиц на передающем компьютере, а также на промежуточных маршрутизаторах, вдоль всего пути следования пакета на место назначения. Поврежденные маршрутные таблицы можно восстановить (по крайней мере на компьютерах с Windows) путем перезапуска стека TCP/IP с помощью команды netsh int ip reset. Для получения более подробной информации на эту тему смотрите статью KB299357. Обратите внимание, что эта операция перезапуска не удаляет постоянные маршруты, которые вы добавили в маршрутную таблицу.

Инструмент Repair – это мощный инструмент, который очень редко используется из-за непонимания. Получить доступ к этому инструменту очень легко – просто щелкните правой кнопкой мыши на сетевом соединении (network connection) в вашей папки Networking Connections (сетевые подключения) или на иконке в области уведомлений и выберите пункт Repair (восстановление из выпадающего меню). После этого откроется диалоговое окно, и появится серия сообщений, отображающих процесс выполнения восстановления. В результате такого действия выполнится набор команд, и каждое из сообщений отображает выполнение одной из этих команд. Давайте рассмотрим каждую из этих команд, чтобы лучше понять, как работает инструмент Repair, что делают эти команды, и для чего они запускаются.

Шаг 1: Обновление DHCP

Этот этап появится лишь в том случае, если сетевое соединение настроено на автоматическую передачу адресе с помощью DHCP. Если вы настроили соединение вручную и сами задавали статический (static) IP адрес и другие настройки TCP/IP, то это шаг пропускается. Команда, которую необходимо выполнить на этом этапе, и которая запускается из командной строки, похожа но не идентична следующей знакомой команде:

ipconfig /renew

Эта команда пытается обратится к серверу DHCP server, от которого ранее был получен адрес для компьютера. Если можно обратиться к серверу DHCP server, то компьютер проверяет свою текущую конфигурацию TCP/IP на сервере, чтобы убедиться, что эта конфигурация правильная. Однако, когда эта команда выполняется с помощью инструмента Repair (восстановление), она ведет себя немного по-другому, чем в случае, когда вы запускаете ее из командной строки (command line). Вместо того, чтобы послать однонаправленное (unicast) DHCP сообщение об обновлении (Renew message) на сервер DHCP, от которого компьютер получил свою конфигурацию DHCP, команда посылает широковещательное (broadcast) DHCP сообщение об обновлении (Renew message) на все доступные сервера DHCP в сети. Причина, по которой это происходит, заключается в том, что если текущая конфигурация TCP/IP на компьютере неверная, компьютер пытается получить новые настройки TCP/IP от любого доступного DHCP сервера, запрашивая новые данные. В результате выполнения такого действия в процессе восстановления (Repair process) достигается двойной эффект: обнаруживаются проблемы с конфигурацией DHCP на клиенте, либо обнаруживаются проблеме с невозможностью соединения с определенным сервером DHCP в сети.

Подсказка: Вы можете избежать сетевых проблем, связанных с недоступностью сервера DHCP, реализовав избыточность (redundancy) для сервера DHCP в вашей сети (network).

Шаг 2: Очистка кэша ARP

Команда, которая выполняется на этом этапе, выглядит так:

arp –d *

Эта команда очищает содержимое кэша протокола преобразования адреса (Address Resolution Protocol - ARP) на локальном компьютере. ARP – это протокол, который используется для того, чтобы преобразовывать IP адреса в адреса МАС, которые жестко прописаны в сетевых LAN адаптерах. Кэш ARP содержит недавние преобразованные MAC адреса для узлов IP в сети. Эти MAC адреса кэшируются на компьютере таким образом, что соединения с этими узлами IP, может происходить без из повторного преобразования. Если одна или несколько записей в кэше протокола ARP неверна, то сетевое соединение с одним из узлов IP в сети может быть нарушено. Если запись в кэше является неверной для узла в локальной подсети, то может быть нарушено соединение с этим узлом. Если запись в кэше является неверной для шлюза по умолчанию, то может быть нарушено соединение с узлами в удаленной подсети. Тип ошибки при невозможности установить соединение (либо с узлами в локальной подсети, либо с узлами в удаленной подсети) может отобразить, какая запись в кэше ARP неверна.

Шаг 3: Очистка кэша NetBIOS

На этом этапе выполняется следующая команда:

nbtstat –R

Эта команда позволяет очистить содержимое кэша NetBIOS на локальном компьютере. После запуска этой команды также все записи из файла LMHOSTS загружаются в кэш. Для большинства сетей Windows, включая те, в которых установлен Active Directory, а для преобразования имен используется DNS, функции NetBIOS по преобразованию имен по-прежнему используются для определенных функций. Т.к. названия NetBIOS удаленных компьютеров (remote hosts) преобразуются в назначенные им IP адреса, при обращении к серверу WINS или при использовании широковещательного NetBIOS, эти отображения названия компьютеров в IP адреса добавляются в кэш NetBIOS на локальном компьютере, и таким образом соединения с удаленными компьютерами могут быть установлены без необходимости их повторного преобразования. Если одна или более записей в кэше NetBIOS неверны, то соединение по сети с одним из компьютеров нарушается. Если запись в кэше является неверной для компьютера в локальной сети, то нарушается соединение с этим компьютером. Если запись в кэше неверна для шлюза по умолчанию, то нарушается соединение с компьютерами в удаленной подсети. По типу ошибки возникающей при нарушении соединения (либо с компьютером в локальной сети, либо с компьютером в удаленной сети) можно определить неверную запись в кэше NetBIOS.

Неверная запись в кэше NetBIOS иногда может быть вызвана устаревшей записью в базе данных WINS database на серверах WINS. Это происходит потому, что WINS имеет более высокий приоритет по сравнению с широковещательным преобразованием имен NetBIOS, при использовании WINS, поэтому поврежденные и устаревшие записи WINS могут попасть в кэш NetBIOS, даже после очистки кэша, и тем самым привести к его неправильной работе. Решение проблемы в данном случае заключается в удалении неверных записей из базы данных WINS, очистки кэша NetBIOS и дальнейшем мониторинге кэша с помощью команды nbtstat –c, чтобы убедиться, что эти неверные записи снова не попали в кэш.

Шаг 4: Очистка кэша DNS Resolver

Команда, выполняемая на этом этапе, выглядит следующим образом:

ipconfig /flushdns

В результате этой команды происходит очистка кэша DHS resolver на локальном компьютере. При запуске этой команды также происходит загрузка всех записей из файла HOSTS в кэш. Т.к. полностью квалификационный названия DNS удаленных компьютеров преобразуются в IP адреса, назначенные компьютеру, при обращении к серверу (DNS server), то результат этих преобразований (FQDN-to-IP-address mappings) добавляются в кэш DNS resolver на локальном компьютере, поэтому нет необходимости в постоянном таком преобразовании. Если одна или более записей в кэше DNS resolver неверны, то нарушается сетевое соединение с одним или несколькими компьютерами в сети. Для того, чтобы увидеть текущее содержимое кэша DHS resolver, наберите команду ipconfig /displaydns в командной строке.

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

Шаг 5: Регистрация в WINS

На этом этапе выполняется следующая команда:

nbtstat –RR

Эта команда пытается заново зарегистрировать локальный компьютер в базе данных WINS на серверах WINS. Это означает, что все названия NetBIOS для локального компьютера сперва извлекаются, а затем обновляются в базе данных. Это может использоваться конечно лишь в том случае, если в вашей сети используются сервера WINS, но как показывает практика, в большинстве корпоративных сетей, в которых установлен Active Directory, а также сервер Exchange Server, по-прежнему используют WINS, смотрите статью KB 837391 для получения более подробной информации.

Когда компьютер с операционной системой Windows выключается корректно, он должен удалять свою запись из базы данных WINS. Если ваш компьютер был выключен неправильно, то записи WINS о компьютере не удаляются из базы данных. Неверные записи в базе данных WINS database могут привести к возникновению проблем с сетью, особенно для портативных компьютеров типа ноутбук, которые можно удалять из одной сети и подключать к другой. Часто с благодаря использованию инструмента Repair (восстановление) эти проблемы можно избежать благодаря новой регистрации в WINS.

Шаг 6: Регистрация в DNS

Последняя команда, которая выполняется на шестом этапе выглядит следующим образом:

ipconfig /registerdns

Эта команда пытается заново зарегистрировать локальный компьютер в базе данных DNS на DNS серверах. Это значит, что все DNS имена для локального компьютера сначала извлекаются, а затем обновляются в базе данных DNS database (предполагается, что вы используете сеть Active Directory с динамическим Dynamic DNS или DDNS для регистрации названий DNS в базе данных).

Все эти ограничения можно обойти благодаря использованию инструмента Netdiag.exe, сетевого средства для отладки, которое входит в состав средств поддержки Windows Support Tools. Netdiag позволяет запустить более широкий набор тестов, чем инструмент Repair. Вы также можете перенаправить поток результатов выполнения Netdiag.exe в текстовый файл, и таким образом записать выполненные тесты и их результаты.

 

Установка Netdiag

ить инструмент Netdiag путем установки средств поддержки Windows Support Tools, что в свою очередь можно сделать двойным нажатием на файл \Support\Tools\SUPTOOLS.MSI. По умолчанию средства поддержки Support Tools устанавливаются в папку %SystermDrive%\Program Files\Support Tools, но лично для меня гораздо удобнее установить их в папку %SystemDrive%\Tools, т.к. эти инструменты необходимо запускать из командной строки (command-line), а второй путь гораздо проще для их запуска. Альтернативно, если вы хотите установить лишь Netdiag, и не хотите устанавливать другие инструменты поддержки Support Tools, то вы можете дважды щелкнуть левой кнопкой мыши на папке \Support\Tools\Support.cab, а затем запустить файл Netdiag.exe.

Описание Netdiag

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

Инструмент Netdiag сперва выполняет следующие тесты на сетевых адаптерах локальной системы:

• Ndis
• Ipconfig
• Autonet
• DefGw
• NbtNm
• WINS

После выполнения этих тестов, Netdiag выполняет следующий набор глобальных тестов соединения:

• Member
• NetBTTransports
• Autonet
• IpLoopBk
• DefGw
• NbtNm
• Winsock
• DNS
• Browser
• DsGetDc
• DcKust
• Trust
• Kerberos
• Ldap
• Bindings
• WAN
• Modem
• IPSec

Подробности, относящиеся к каждому из этих тестов приведены в следующей таблице:

Название теста	Описание
Autonet	Проверяет, используется ли APIPA на сетевых адаптерах или нет.
Bindings	Отображает список привязок, включая название интерфейса (interface name), нижнее (lower) и верхнее (upper) название модуля, отображает, подключена ли в настоящий момент связка или нет, отображает владельца связки.
Browser	Отображает список всех сетевых протоколов (network protocol), связанных со службой Browser service.
DcList	Позволяет получить список контроллеров домена (domain controller) для домена (domain).
DefGw	Проверяет связь с каждым настроенным шлюзом по умолчанию (default gateway).
DNS	Проверяет доступность настроенных DNS серверов и проверяет DNS регистрацию клиента.
DsGetDc	Позволяет получить название любого контроллера домена (domain controller) из службы директорий (directory service), а затем получить название PDC Emulator. Проверяет, совпадает ли domain GUID, хранящийся в Local Security Authority (LSA), с domain GUID, хранящимся на DC.
IpConfig	Перечисляет настройки TCP/IP для каждого сетевого адаптера (network adapter).
IpLoopBk	Пингует адрес 127.0.0.1 для каждого адаптера.
IPSec	Проверяет подключен ли Ipsec, и если да, то отображает список всех активных политик IPsec для компьютера.
IPX	Показывает статистику для IPX (если установлен).
Kerberos	Проверяет обновления для пакета аутентификации Kerberos authentication.
Ldap	Связывается со всеми доступными контроллерами домена и определяет какой протокол аутентификации LDAP authentication используется в настоящий момент.
Member	Проверяет настройки основного домена (primary domain), включая роль компьютера (computer role), название домена (domain name), и domain GUID. Проверяет, запущена ли служба NetLogon, добавляет основной домен в список доменов, и запрашивает у основного домена идентификатор безопасности (security identifier SID).
Modem	Получает информацию о конфигурации для каждого модема в системе.
NbtNm	Выполняет действия, аналогичные команде nbtstat –n, т.е. проверяет, что название службы рабочей станции Workstation Service <00> такое же, что и название компьютера, и проверяет, что название службы сообщений Messenger Service <03> и название службы сервера Server Service <20> присутствует на всех интерфейсах и что нет конфликтов.
Ndis	Отображает информацию относительно конфигурации каждого сетевого адаптера, включая название адаптера (adapter name), конфигурацию (configuration), media, GUID и статистику.
NetBTTransports	Отображает список всех транспортных протоколов (transport protocol), связанных с NetBIOS по TCP/IP (NetBT).
Netstat	Отображает текущие соединения TCP/IP и статистику протокола.
Netware	Запрашивает у ближайшего сервера Netware (если таковой используется) информацию о текущем входе.
Route	Отображает список всех статических маршрутов в маршрутной таблице (routing table).
Trust	Проверяет доверительные отношения с доменом и проверяет, что идентификатор безопасности SID основного домена правильный.
WAN	Обобщает все настройки и состояние для каждого COM порта, используемого в настоящий момент.
WINS	Проверяет доступность настроенных серверов WINS и проверяет клиентские регистрации WINS.
Winsock	Отображает протоколы и порты, доступные для службы WinSock service.

Дополнительно к этим тестам, инструмент Netdiag.exe также позволяет получить отчеты по следующей информации, касающейся системы:

• Название NetBIOS системы
• Название DNS системы
• Общую информацию о системе
• Установленные обновления

Запуск Netdiag

Самый простой способ запустить Netdiag без параметров, в результате чего он произведет проверку всех локальных сетевых адаптеров в системе, а затем выполнит серию глобальных тестов на соединение. Пример вывода, полученного после запуска такой команды на Windows Server 2003 приведен ниже (список установленных обновлений был отброшен):

C:\tools\netdiag
...................................

Computer Name: SRV
DNS Host Name: SRV.contoso.com
System info : Microsoft Windows Server 2003 R2 (Build 3790)
Processor : x86 Family 15 Model 4 Stepping 1, GenuineIntel
List of installed hotfixes :
KB890046
KB893756
KB896358
…
KB925486
Q147222

Netcard queries test . . . . . . . : Passed

Per interface results:

Adapter : Local Area Connection

Netcard queries test . . . : Passed

Host Name. . . . . . . . . : SRV

IP Address . . . . . . . . : 172.16.11.31
Subnet Mask. . . . . . . . : 255.255.255.0
Default Gateway. . . . . . : 172.16.11.1
Dns Servers. . . . . . . . : 172.16.11.32

AutoConfiguration results. . . . . . : Passed

Default gateway test . . . : Passed

NetBT name test. . . . . . : Passed
[WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing.

WINS service test. . . . . : Skipped
There are no WINS servers configured for this interface.

Global results:
Domain membership test . . . . . . : Passed

NetBT transports test. . . . . . . : Passed

List of NetBt transports currently configured:
NetBT_Tcpip_{64B5D4FF-0014-4CC2-BB8D-9FB0C67CB75E}
1 NetBt transport currently configured.

Autonet address test . . . . . . . : Passed

IP loopback ping test. . . . . . . : Passed

Default gateway test . . . . . . . : Passed

NetBT name test. . . . . . . . . . : Passed
[WARNING] You don't have a single interface with the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names defined.

Winsock test . . . . . . . . . . . : Passed

DNS test . . . . . . . . . . . . . : Passed

Redir and Browser test . . . . . . : Passed
List of NetBt transports currently bound to the Redir
NetBT_Tcpip_{64B5D4FF-0014-4CC2-BB8D-9FB0C67CB75E}
The redir is bound to 1 NetBt transport.

List of NetBt transports currently bound to the browser
NetBT_Tcpip_{64B5D4FF-0014-4CC2-BB8D-9FB0C67CB75E}
The browser is bound to 1 NetBt transport.

DC discovery test. . . . . . . . . : Passed

DC list test . . . . . . . . . . . : Passed

Trust relationship test. . . . . . : Passed
Secure channel for domain 'CONTOSO' is to '\\DC-1A.contoso.com'.

Kerberos test. . . . . . . . . . . : Passed

LDAP test. . . . . . . . . . . . . : Passed

Bindings test. . . . . . . . . . . : Passed

WAN configuration test . . . . . . : Skipped
No active remote access connections.

Modem diagnostics test . . . . . . : Passed

IP Security test . . . . . . . . . : Skipped

Note: run "netsh ipsec dynamic show /?" for more detailed information

The command completed successfully

Обратите внимание, что тест NbtNm привел к получению следующих результатов:

NetBT name test. . . . . . : Passed
[WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing.

Такое предупреждение не является проблемой, т.к. по умолчанию служба сообщений Messenger service не запущена на сервере Windows Server 2003, поэтому для нее не будет зарегистрировано ни одного названия <20>.

Существуют другие способы запуска Netdiag, а именно:

• Netdiag /q запускает тест в тихом режиме и сообщает только об ошибках.
• Netdiag /v запускает тест в расширенном режиме (verbose mode), в результате чего мы получим дополнительную информацию.
• Netdiag /test:test_name(s) запускает стандартный тест, а затем выполняется только определенный тест.
• Netdiag /skip:test_name(s) запускает стандартный тест, за которым следует глобальный тест, за исключением одного указанного. (Определенные тесты можно опустить, включая Member, Ndis и NetBTTransports.)
• Netdiag /fix выполняет все стандартные и глобальные тесты, а также пытается устранить найденные в результате проблемы.

Например, запуск Netdiag с ключом /q на той же самой системе приведет к следующему результату:

C:\tools\netdiag /q
...................................

Computer Name: SRV
DNS Host Name: SRV.contoso.com
System info : Microsoft Windows Server 2003 R2 (Build 3790)
Processor : x86 Family 15 Model 4 Stepping 1, GenuineIntel
List of installed hotfixes :
KB890046
KB893756
KB896358
…
KB925486
Q147222

Per interface results:

Adapter : Local Area Connection

Host Name. . . . . . . . . : SRV
IP Address . . . . . . . . : 172.16.11.31
Subnet Mask. . . . . . . . : 255.255.255.0
Default Gateway. . . . . . : 172.16.11.1
Dns Servers. . . . . . . . : 172.16.11.32

WINS service test. . . . . : Skipped

Global results:
[WARNING] You don't have a single interface with the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names defined.

IP Security test . . . . . . . . . : Skipped

The command completed successfully

Примеры использования Netdiag

Лучший способ научиться понимать результаты, полученные с помощью Netdiag, заключается в том, чтобы попробовать запустить его в различных сценариях. Ниже приведено несколько примеров различных сценариев, а также результаты, которые были получены благодаря использованию этого инструмента. Эти сценарии выполнены при запуске Netdiag на сервере Windows Server 2003, который является членом домена, а полученные результаты были немного урезаны, чтобы указать лишь сообщения об ошибках.

 

1. Результаты выполнения netdiag /q в случае, когда контроллер домена выключен.
2. Результат выполнения netdiag /q в случае, когда неправильно настроен шлюз по умолчанию (default gateway) в системе.
3. Результат выполнения netdiag /q в случае, когда служба браузера Browser service не запущена на компьютере.
4. Результат выполнения netdiag /q в случае, когда учетная запись компьютера (computer account) для системы отключена в Active Directory при загрузке компьютера.