В первой части этой статьи, я рассказал о структурном подходе при устранении сетевых неполадок, связанных с TCP/IP, в сетях Windows. Основой этого структурного подхода являлись три вещи:

• Понимание сетевых технологий и протоколов, лежащих в основе проблемы.
• Определение различных проблемных элементов и их параметров.
• Определение мер и инструментов, которые необходимо использовать для решения проблемы.

Я отобразил эти три пункта в виде обычного списка, а не в виде нумерованного списка, т.к. устранение неполадок с сетью обычно не так просто, как 1-2-3. Другими словами, гораздо чаще это больше интуиция, чем методология.

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

• Они используются для хранения информации о других подсетях, а также о том, как вы можете передать информацию на компьютеры в этих сетях.
• Они также используются для определения маршрута, который проделает каждый пакет для того, чтобы попасть в место своего непосредственного назначения.
• Они также используются для определения сетевого интерфейса (network interface, который также называется next-hop interface), который будет использоваться для передачи этого пакета на место назначения.

Понимание принципа работы маршрутных таблиц очень важно, если вы хотите иметь возможность эффективно устранять неисправности, связанные с маршрутизацией в сетях TCP/IP network. Давайте посмотрим, как работают маршрутные таблицы, как они выглядят в различных сценариях, и какие этапы по отладке необходимо выполнить в различных сценариях. Мы начнем изучение маршрутных таблиц с сервера single-homed server (сервер с одним сетевым интерфейсом), которому назначен один IP адрес. Я выбрал этот пример, т.к. он наиболее прост для понимания, а в будущих статьях мы увидим более сложные сценарии, включая сервера с несколькими IP адресами (например web сервера) и сервера с несколькими сетевыми интерфейсами (например, сервера, которые подключены как к LAN, так и отдельной сети, используемой для выполнения работ по резервному копированию).

Маршрутные таблицы для сервера 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):

2. Затем для каждого маршрута результат такого объединения сравнивается с полем 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) и маской подсети маршрута. Результаты будут выглядеть примерно так:

2. Для каждого маршрута результат объединения 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

3. Затем 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. Обратите внимание, что эта операция перезапуска не удаляет постоянные маршруты, которые вы добавили в маршрутную таблицу.

Заключение

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

Источник: apocalypse.moy.su