Базовая диагностика сетевых подключений

Содержание:

Основы протокола ICMP

1. Проверка доступности удаленной системы с помощью команды ping
2. Трассировка маршрута с помощью команды traceroute
3. Статистика интерфейсов с помощью команды netstat.

Основы протокола ICMP

Протокол ICMP (Internet Control Message Protocol) используется для диагностики сетевых подключений, а также для передачи удаленным системам сообщений об исключительных ситуациях, возникающих в процессе работы стека TCP/IP. ICMP работает на сетевом уровне модели сетевого взаимодействия; при этом ICMP инкапсулирует свои сообщения в IP-пакеты; реализация ICMP является обязательной для стека TCP/IP. ICMP-сообщение состоит из заголовка (содержит идентификаторы типа и кода сообщения, а также контрольную сумму) и поля данных, содержимое которого зависит от назначения сообщения [ 7 ] .

Условно ICMP -сообщения можно разделить на две группы [ 30 ] : сообщения об ошибках и информационные сообщения. Первая группа включает такие типы сообщений как: направление недоступно ( Destination Unreachable ); подавление источника ( Source Quench ); истечение времени ( Time Exceeded ); проблема параметров ( Parameter Problem ) и т.д. Примером сообщений второй группы являются сообщения перенаправление ( Redirect ); эхо-запроса ( Echo ) и эхо-ответа ( Echo Reply ). Всего известно около 40 типов ICMP -сообщений.

Большинство типов сообщений содержат наборы уточняющих кодов, конкретизирующих проблему. Так сообщение "Направление недоступно" информирует о недоступности удаленного узла по той или иной причине: недоступность узла, протокола или порта; большой размер пакета по сравнению с MTU передающей среды при невозможности фрагментации пакетов; отсутствие у промежуточного шлюза маршрутов к удаленному узлу или сети; активные фильтры пакетов на шлюзе и т.д.

Пусть на узле A установлен IP-адрес из сети 192.168.1.0/24 и шлюз по умолчанию 192.168.1.1. Если, например шлюз "не знает" маршрута до сети 192.168.2.0/24, то при попытке взаимодействия узла А с узлом 192.168.2.10 (например, с помощью утилиты ping ), узел А будет получать от шлюза ICMP -сообщения о недоступности сети назначения ( Destination Net Unreachable ).

# ping 192.168.2.10
PING 192.168.2.10 (192.168.2.10) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Net Unreachable
From 192.168.1.1 icmp_seq=2 Destination Net Unreachable
^C
--- 192.168.2.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1023ms

В данном примере один из шлюзов фильтрует доступ к сети Интернет и отправляет соответствующие ICMP-сообщения узлу локальной сети.

$ ping www.yandex.ru
PING www.yandex.ru (213.180.204.3) 56(84) bytes of data.
From 10.31.46.1 icmp_seq=1 Packet filtered
From 10.31.46.1 icmp_seq=2 Packet filtered
^C
--- www.yandex.ru ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 10074ms

Проверка доступности удаленной системы с помощью команды ping

Самый простой способ тестирования связи между двумя системами заключается в проверке возможности отправки системами сообщений друг другу. Для этого первый узел отправляет второму узлу тестовое сообщение, получив которое второй узел должен отправить ответное сообщение. В протоколе ICMP для отправки тестового сообщения используется сообщение типа эхо-запрос ( Echo ), для отправки ответа на тестовое сообщение — эхо-ответ ( Echo Reply ). Функция ответа на эхо-запросы интегрирована в сетевой стек операционной системы и в большинстве случаев включена по умолчанию. Для реализации данного типа проверки используется утилита ping, которая в Debian устанавливается по умолчанию (пример 6.3.). Основным параметром ping является доменное имя удаленной системы или ее IP-адрес.

$ ping www.yandex.ru
PING www.yandex.ru (87.250.250.3) 56(84) bytes of data.
64 bytes from www.yandex.ru (87.250.250.3): icmp_req=1 ttl=52 time=42.8 ms
64 bytes from www.yandex.ru (87.250.250.3): icmp_req=2 ttl=52 time=42.5 ms
64 bytes from www.yandex.ru (87.250.250.3): icmp_req=3 ttl=52 time=50.0 ms
^C
--- www.yandex.ru ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 42.514/45.124/50.044/3.481 ms

В Linux команда ping по умолчанию отправляет эхо-запросы до тех пор, пока пользователь не прервет ее работу, например комбинацией клавиш Ctrl+C (можно использовать параметр -с с указанием количества отправляемых запросов, например: ping -c 3 www.yandex.ru - будут отправлены 3 запроса). Если ответ на запрос получен, то на экран выводится информация о размере эхо-ответа (в данном случает 64 байт), доменное имя узла и(или) IP-адрес, порядковый номер запроса, параметры TTL и RTT (см. ниже). При завершении своей работы команда ping выводит статистику: количество отправленных ( transmitted ) и полученных ( received ) пакетов, процент потерь ( packet loss ), а также статистику RTT.

Параметр TTL (Time-To-Live) определяет время "жизни" пакета и на узле-источнике устанавливается в целое число (максимальное количество маршрутизаторов, которое может быть пройдено пакетом - скачков). При каждом скачке значение TTL уменьшается на единицу. Когда значение становится равным нулю, пакет уничтожается. Данный подход позволяет избежать петель маршрутизации (бесконечного перемещения пакета между двумя узлами маршрутизации), возникающих, например, при ошибках конфигурации.

Параметр RTT (Round Trip Time) — время между отправкой запроса и получением ответа на данный запрос.

Информация, предоставляемая командой ping, позволяет сделать определенные выводы о качестве канала связи между двумя узлами. Например, высокий процент потерь пакетов или меняющееся в больших пределах значение RTT являются указанием на наличи проблем со связью. В тоже время на основе хороших показателей потерь пакетов и RTT не всегда можно сделать заключение о пригодности канала связи для использования данным транспортным или прикладным протоколом, т. к. они могут предъявлять более высокие требования к качеству канала связи. Сравните, например, значение параметр RTT для коротких пакетов и пакетов, размер которых близок к максимальному возможному (пример 6.4.) в сегменте сети Ethernet.

# ping -s 1400 -c 3 10.31.16.103
PING 10.31.16.103 (10.31.16.103) 1400(1428) bytes of data.
1408 bytes from 10.31.16.103: icmp_seq=1 ttl=64 time=2.17 ms
1408 bytes from 10.31.16.103: icmp_seq=2 ttl=64 time=1.90 ms
1408 bytes from 10.31.16.103: icmp_seq=3 ttl=64 time=1.26 ms
--- 10.31.16.103 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 1.260/1.779/2.171/0.384 ms

Для сравнения ping в тех же условиях с малым размером сообщения:

# ping -c 3 10.31.16.103
PING 10.31.16.103 (10.31.16.103) 56(84) bytes of data.
64 bytes from 10.31.16.103: icmp_seq=1 ttl=64 time=0.328 ms
64 bytes from 10.31.16.103: icmp_seq=2 ttl=64 time=0.231 ms
64 bytes from 10.31.16.103: icmp_seq=3 ttl=64 time=0.583 ms
--- 10.31.16.103 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.231/0.380/0.583/0.150 ms

Выбор исходного IP-адреса для отправки пакетов в системах с несколькими IP-адресами зависит от настроек таблиц маршрутизации и особенностей операционной системы. Для явного указания исходного IP-адреса в команде ping следует использовать ключ -I с указанием IP-адреса (в данном случае 192.168.1.11):

# ping -c 1 -I 192.168.1.11 192.168.1.1
PING 192.168.1.1 (192.168.1.1) from 192.168.1.11 : 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.09 ms
--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.091/3.091/3.091/0.000 ms

Следует отметить, что отсутствие ответа от удаленной системы на эхо-запросы не является гарантированным признаком ее неработоспособности: протокол ICMP может фильтроваться на каком-нибудь промежуточном узле или отключен на удаленном узле. В тоже время доступность удаленной системы по протоколу ICMP не означает работоспособность прикладных сетевых служб на ней: доступ к сервису может блокироваться межсетевым экраном или сервис может быть отключен и т.д.