Устранение неисправностей TCP/IP: Структурный подход - <font><font color=

ОГЛАВЛЕНИЕ


Маршрутные таблицы для сервера 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 в текстовый файл, и таким образом записать выполненные тесты и их результаты.