Destination net prohibited что это
Маленькие секреты сетевых утилит. Интерпретируем вывод ping, traceroute и whois для отладки
Содержание статьи
Команда ping example.com известна каждому, даже далекому от сетей человеку. Она отправляет удаленному хосту пакеты ICMP echo, на которые, по идее, он должен ответить таким же пакетом.
Однако этот протокол не просто так называется Internet Message Control Protocol. Его функции далеко не только диагностические, а диагностические функции куда шире, чем «ответил — не ответил».
Что может сказать ping?
Зачастую, если хост назначения недостижим, от ping действительно можно получить только request timeout и ничего больше. Если успешный ответ всегда исходит от самого хоста назначения, то сообщения об ошибках доставки — от промежуточных маршрутизаторов. По стандарту промежуточные маршрутизаторы могут, но не обязаны уведомлять отправителя. Часто и не уведомляют — по соображениям производительности, и обвинить их не в чем.
Такой ответ может прийти только от последнего маршрутизатора на пути к хосту.
А вот network unreachable говорит об отсутствии маршрута к указанной сети у одного из хостов на пути. Эта ошибка может возникнуть в любом месте пути, поэтому нужно обратить внимание на отправителя.
Чаще всего эта проблема у тебя самого: слетели настройки маршрутов или хост не получил маршрут от сервера DHCP. Но такой ответ может прийти и от промежуточного маршрутизатора:
Если ты видишь такую картину, что-то серьезно пошло не так. Если хост достижим из других сетей, вполне возможно, что у провайдера проблема с настройками BGP. Я как минимум один раз сталкивался с тем, что крупный провайдер ошибочно фильтровал маршруты из сети, которую он считал зарезервированной для использования в будущем, хотя на тот момент IANA уже полгода как передала ее RIPE NCC и многие люди получили адреса из нее.
Если не хочешь быть как тот провайдер, можно воспользоваться автоматически обновляемыми списками несуществующих адресов вроде Cymru Bogon Reference
Но это все о простом ping без опций. Некоторые проблемы лучше всего выявляются дополнительными опциями.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Сайт ARNY.RU
Troubleshooting часть 1 — углубляемся в ping и traceroute, разбираем малоизвестные факты об этих популярных инструментах траблшутинга.
Всем знакомые ping и traceroute. Все их используют и не особо обращают внимание. А что там знать? Ведь команды эти крайне простые. Всё ли так просто на самом деле? Проверь себя. Рассказ как всегда в контексте устройств CISCO.
Для начала неплохо будет ознакомиться с базовыми концепциями траблшутинга из курса CCNA. Вот эта запись и там Урок 9.
Traceroute
Сначала traceroute, здесь поинтереснее. Самое первое тут: traceroute может использовать разные протоколы передачи данных и конкретно в CISCO это не ICMP. Да, вот в CISCO так. Здесь UDP, поэтому в настройках расширенного traceroute есть пункт выбора порта. Порт по умолчанию 33434, его можно поменять.
Тем не менее traceroute всё равно задействует ICMP в своей работе. И механизм этой работы такой: пакеты с UDP начинкой отправляются с различным TTL (от 1 до 30). Для первого пакета TTL равен единице, для второго двум и так далее.
На каждом хопе TTL уменьшается на 1 и когда он обнуляется, то устройство где это произошло, отправляет ICMP собщение отправителю о данном событии (ICMP Time Exceeded Message, TEM). Из этого сообщения извлекается информация (IP адрес отправителя) и выводится на экран. Каждый следующий пакет уходит на один хоп дальше. Когда наконец пакет достигает хоста назначения, то оказывается что нет приложения прослушивающего UDP порт, указанный в пакете, и хост отправляет об этом сообщение (ICMP Port Unreachable Message). Всё, трассировка завершена.
Вывод команды traceroute
Теперь подробнее, обращаю внимание что для ping и traceroute есть одинаковые инфомационные сообщения в выводе, только с разным значением. Разберём и вот эти непонятки проясним.
Character | Description |
---|---|
U | Port unreachable |
H | Host unreachable |
N | Network unreachable |
P | Protocol Unreachable |
T | Timeout |
? | Unknown packet type |
XX msec | For each node, the round-trip time in milliseconds for the specified number of probes |
* | The probe timed out |
A | Administratively prohibited (example access-list) |
Q | Source quench (destination too busy) |
I | User interrupted test |
Расшифровка вывода traceroute
Запомним первые два: «крышечка» U недоступен порт, H недоступен хост.
Параметры команды traceroute
Тут зависит от модели устройства и IOS, может быть и вот так:
Описание основных параметров:
Пример
Расширенная трассировка, адрес 192.168.3.1 находится в двух хопах от нашего роутера R1:
Какие здесь моменты? В пункте Source address or interface имя интерфейса нельзя сокращать. Команда traceroute вываливает все свои параметры, не спрашивая нас (для пинга по-другому). Loose, Strict, Record, Timestamp, Verbose рассмотрим в разделе про пинг. Для второй пробы к 10.20.3.3 превышено время ожидания ответа (*).
Debug команды traceroute
Включим дебаг и будем ещё смотреть с помощью Wireshark:
Посмотрим пакет в Wireshark, очистим вывод с помощью фильтра:
Что мы здесь видим? Было отправлено 6 пакетов, это имено пакеты UDP, в IP заголовке номер протокола 17. Пакеты высылались на порт 33434 для первого пакета и +1 для каждого следующего. Поэтому для шестого 33439. В ответ получено 5 ICMP ответов, 3 Time exceeded, 2 Port unreachable. Все эти ответы видны в дебаге роутера.
Служит для проверки доступности узла сети. С успешным пингом всё понятно — узел доступен. С неуспешным сложнее, как правило этого недостаточно чтобы сделать какой-то вывод. Требуются дополнительные инструменты и нужно выяснить что там с устройством случилось. Или ничего не случилось. Допустим, узел находится где-то в интернете и администратор закрыл ICMP запросы из интернета. Устройство нормально работает, при этом пропинговать его невозможно.
Внутри локальной сети попроще. Если известно что узел должен пинговаться и вот он не пигуется, значит что-то не в порядке. Опять же нужны дополнительные инструменты. Топ 3 причин неудачного пинга: нет элетричества или сбой ИБП, «добрый самаритянин» выдернул провода (сетевые или электрические) или повредили кабель при ремонтных работах (экскаватор перебил оптику), устройство ушло в ребут (в циклический ребут).
Вывод команды ping
Character | Description |
---|---|
! | The exclamation point indicates receipt of a single reply. The ping successfully reached the destination, the destination replied, and the reply made it back to the originator. This is an ICMP Type 0 message. |
. | The period indicates that the ping timed out. Normally this indicates that the distant end received the ping, but could not reply for some reason. |
U | The destination of the ping was unreachable. Although not visible in the router output, there are 16 sub-codes to the unreachable message that describe exactly what was unreachable. |
M | An intermediate device could not fragment the packet, and so could not forward it. |
? | Unknown packet received. |
& | Packet lifetime exceeded. |
Расшифровка вывода ping
Для ping и tracerote U в выводе имеет разное значение, для пинга U то же самое что H для traceroute. Не знаю как сейчас, но раньше CISCO просто обожала на своих экзаменах бомбить вопросами на знание подобных мелочей.
Пример
Пусть роутер R1 не знает о сети 192.168.10.0/24, то есть её нет в его таблице маршрутизации. И нет маршрута по умолчанию, значит R1 не знает куда отсылать пакеты для этой сети. Тут всё ясно, точки и звёздочки:
Теперь добавим на R1 маршрут по умолчанию, указывающий на IP адрес роутера R2 (адрес следующего перехода). Роутер R2 также не знает о сети 192.168.10.0/24. R1 будет отправлять пакеты на R2 и ждать ответа от R2:
Теперь поподробнее что же такое unreachable. Если поднимем на R2 ещё дополнительный интерфейс и назначим ему 192.168.10.2/24, то интерфейс UP и таблице маршрутизации появится связанный маршрут:
Снова запустим пинг и traceroute к 192.168.10.1 с R1. Снова будут точки и звёздочки, таймаут. Другими словами, unreachable — это когда роутер (его адрес будет в строчке вывода traceroute) по пути следования пакета (но не локальный роутер) не знает куда дальше пересылать пакет.
Параметры команды ping
Опять же набор параметров может отличаться, основные параметры:
Пример
Если мы принудительно не включим расширенные команды, то они и недоступны, в отличие от traceroute. Sweep range of sizes будет увеличивать размер пакета от начального значения до конечного с указанным шагом.
Прервал выполение команды (для этого есть удобная комбинация клавиш Ctrl-Shift-6). Можно использовать Sweep range для проверки MTU (при установленном бите DF в расширенных командах). Ну и собственно сами расширенные команды:
Тут подробнее про Loose, Strict, Record, Timestamp, Verbose.
На мой взгляд самое полезное здесь это Record, поможет выявить ассиметричный роутинг. Недостаток, пишет всего 9 хопов.
Debug команды ping
Для сокращения вывода использовал один пакет. Мы один запрос отправили, один ответ получили. Смотрим Wireshark:
Ходовой вопрос на собеседованиях: для пинга какой порт используется? Никакой. Почему? Чтобы был порт, должен быть заголовок транспортного уровня (TCP/UDP). Для ICMP такого заголовка просто нет в пакете, ICMP цепляется непосредственно к IP заголовку. При этом в IP заголовке номер протокола 1. Самые ходовые протоколы, на собеседовании бывает спрашивают:
Список номеров всех протоколов тут. Ну вот, надеюсь что-то полезное рассказал. Не стал специально переводить описание к параметрам, так как лучше прочитать в оригинале, чем мой неточный перевод. Кому сложно в оригинале, переводчик в помощь. А вообще пора учить английский.
7 сетевых Linux-команд, о которых стоит знать системным администраторам
Существуют Linux-команды, которые всегда должны быть под рукой у системного администратора. Эта статья посвящена 7 утилитам, предназначенным для работы с сетью.
Этот материал — первый в серии статей, построенных на рекомендациях, собранных от множества знатоков Linux. А именно, я спросил у наших основных разработчиков об их любимых Linux-командах, после чего меня буквально завалили ценными сведениями. А именно, речь идёт о 46 командах, некоторые из которых отличает тот факт, что о них рассказало несколько человек.
В данной серии статей будут представлены все эти команды, разбитые по категориям. Первые 7 команд, которым и посвящена эта статья, направлены на работу с сетью.
Команда ip
Команда ip — это один из стандартных инструментов, который необходим любому системному администратору для решения его повседневных задач — от настройки новых компьютеров и назначения им IP-адресов, до борьбы с сетевыми проблемами существующих систем. Команда ip может выводить сведения о сетевых адресах, позволяет управлять маршрутизацией трафика и, кроме того, способна давать данные о различных сетевых устройствах, интерфейсах и туннелях.
Синтаксис этой команды выглядит так:
Самое важное тут — это (подкоманда). Здесь можно использовать, помимо некоторых других, следующие ключевые слова:
Вывод IP-адресов, назначенных интерфейсу на сервере:
Назначение IP-адреса интерфейсу, например — enps03 :
Удаление IP-адреса из интерфейса:
Изменение статуса интерфейса, в данном случае — включение eth0 :
Изменение статуса интерфейса, в данном случае — выключение eth0 :
Изменение статуса интерфейса, в данном случае — изменение MTU eth0 :
Изменение статуса интерфейса, в данном случае — перевод eth0 в режим приёма всех сетевых пакетов:
Добавление маршрута, используемого по умолчанию (для всех адресов), через локальный шлюз 192.168.1.254, который доступен на устройстве eth0 :
Добавление маршрута к 192.168.1.0/24 через шлюз на 192.168.1.254:
Добавление маршрута к 192.168.1.0/24, который доступен на устройстве eth0 :
Удаление маршрута для 192.168.1.0/24, для доступа к которому используется шлюз 192.168.1.254:
Вывод маршрута к IP 10.10.1.4:
Команда ifconfig
Команда mtr
Синтаксис команды выглядит так:
Если вызвать эту команду, указав лишь имя или адрес хоста — она выведет сведения о каждом шаге маршрутизации. В частности — имена хостов, сведения о времени их ответа и о потерянных пакетах:
А следующий вариант команды позволяет выводить и имена, и IP-адреса хостов:
Так можно задать количество ping-пакетов, которые нужно отправить системе, маршрут к которой подвергается анализу:
А так можно получить отчёт, содержащий результаты работы mtr :
Вот — ещё один вариант получения такого отчёта:
Для того чтобы принудительно использовать TCP вместо ICMP — надо поступить так:
А вот так можно использовать UDP вместо ICMP:
Вот — вариант команды, где задаётся максимальное количество шагов маршрутизации:
Так можно настроить размер пакета:
Для вывода результатов работы mtr в формате CSV используется такая команда:
Вот — команда для вывода результатов работы mtr в формате XML:
Команда tcpdump
Утилита tcpdump предназначена для захвата и анализа пакетов.
Установить её можно так:
Прежде чем приступить к захвату пакетов, нужно узнать о том, какой интерфейс может использовать эта команда. В данном случае нужно будет применить команду sudo или иметь root-доступ к системе.
Если нужно захватить трафик с интерфейса eth0 — этот процесс можно запустить такой командой:
▍ Захват трафика, идущего к некоему хосту и от него
Можно отфильтровать трафик и захватить лишь тот, который приходит от определённого хоста. Например, чтобы захватить пакеты, идущие от системы с адресом 8.8.8.8 и уходящие к этой же системе, можно воспользоваться такой командой:
Для захвата трафика, идущего с хоста 8.8.8.8, используется такая команда:
Для захвата трафика, уходящего на хост 8.8.8.8, применяется такая команда:
▍ Захват трафика, идущего в некую сеть и из неё
Трафик можно захватывать и ориентируясь на конкретную сеть. Делается это так:
Ещё можно поступить так:
Можно, кроме того, фильтровать трафик на основе его источника или места, в которое он идёт.
Вот — пример захвата трафика, отфильтрованного по его источнику (то есть — по той сети, откуда он приходит):
Вот — захват трафика с фильтрацией по сети, в которую он направляется:
▍ Захват трафика, поступающего на некий порт и выходящего из некоего порта
Вот пример захвата трафика только для DNS-порта по умолчанию (53):
Захват трафика для заданного порта:
Захват только HTTPS-трафика:
Захват трафика для всех портов кроме 80 и 25:
Команда netstat
Если в вашей системе netstat отсутствует, установить эту программу можно так:
Ей, в основном, пользуются, вызывая без параметров:
В более сложных случаях её вызывают с параметрами, что может выглядеть так:
Можно вызывать netstat и с несколькими параметрами, перечислив их друг за другом:
Для вывода сведений обо всех портах и соединениях, вне зависимости от их состояния и от используемого протокола, применяется такая конструкция:
Для вывода сведений обо всех TCP-портах применяется такой вариант команды:
Если нужны данные по UDP-портам — утилиту вызывают так:
Список портов любых протоколов, ожидающих соединений, можно вывести так:
Список TCP-портов, ожидающих соединений, выводится так:
Так выводят список UDP-портов, ожидающих соединений:
А так — список UNIX-портов, ожидающих соединений:
Вот — команда для вывода статистических сведений по всем портам вне зависимости от протокола:
Так выводятся статистические сведения по TCP-портам:
Для просмотра списка TCP-соединений с указанием PID/имён программ используется такая команда:
Для того чтобы найти процесс, который использует порт с заданным номером, можно поступить так:
Команда nslookup
Команда nslookup используется для интерактивного «общения» с серверами доменных имён, находящимися в интернете. Она применяется для выполнения DNS-запросов и получения сведений о доменных именах или IP-адресах, а так же — для получения любых других специальных DNS-записей.
Рассмотрим распространённые примеры использования этой команды.
Получение A-записи домена:
Просмотр NS-записей домена:
Выяснение сведений о MX-записях, в которых указаны имена серверов, ответственных за работу с электронной почтой:
Обнаружение всех доступных DNS-записей домена:
Проверка использования конкретного DNS-сервера (в данном случае запрос производится к серверу имён ns1.nsexample.com ):
Проверка A-записи для выяснения IP-адресов домена — это распространённая практика, но иногда нужно проверить то, имеет ли IP-адрес отношение к некоему домену. Для этого нужно выполнить обратный просмотр DNS:
Команда ping
Команда ping — это инструмент, с помощью которого проверяют, на уровне IP, возможность связи одной TCP/IP-системы с другой. Делается это с использованием эхо-запросов протокола ICMP (Internet Control Message Protocol Echo Request). Программа фиксирует получение ответов на такие запросы и выводит сведения о них вместе с данными о времени их приёма-передачи. Ping — это основная команда, используемая в TCP/IP-сетях и применяемая для решения сетевых проблем, связанных с целостностью сети, с возможностью установления связи, с разрешением имён.
Эта команда, при простом способе её использования, принимает лишь один параметр: имя хоста, подключение к которому надо проверить, или его IP-адрес. Вот как это может выглядеть:
Обычно, если запустить команду ping в её простом виде, не передавая ей дополнительные параметры, Linux будет пинговать интересующий пользователя хост без ограничений по времени. Если нужно изначально ограничить количество ICMP-запросов, например — до 10, команду ping надо запустить так:
Или можно указать адрес интерфейса. В данном случае речь идёт об IP-адресе 10.233.201.45:
Применяя эту команду, можно указать и то, какую версию протокола IP использовать — v4 или v6:
В процессе работы с утилитой ping вы столкнётесь с различными результатами. В частности, это могут быть сообщения о нештатных ситуациях. Рассмотрим три таких ситуации.
▍ Destination Host Unreachable
Вероятной причиной получения такого ответа является отсутствие маршрута от локальной хост-системы к целевому хосту. Или, возможно, это удалённый маршрутизатор сообщает о том, что у него нет маршрута к целевому хосту.
▍ Request timed out
Если результат работы ping выглядит именно так — это значит, что локальная система не получила, в заданное время, эхо-ответов от целевой системы. По умолчанию используется время ожидания ответа в 1 секунду, но этот параметр можно настроить. Подобное может произойти по разным причинам. Чаще всего это — перегруженность сети, сбой ARP-запроса, отбрасывание пакетов фильтром или файрволом и прочее подобное.
▍ Unknown host/Ping Request Could Not Find Host
Такой результат может указывать на то, что неправильно введено имя хоста, или хоста с таким именем в сети просто не существует.
О хорошем качестве связи между исследуемыми системами говорит уровень потери пакетов в 0%, а так же — низкое значение времени получения ответа. При этом в каждом конкретном случае время получения ответа варьируется, так как оно зависит от разных параметров сети. В частности — от того, какая среда передачи данных используется в конкретной сети (витая пара, оптоволокно, радиоволны).
Итоги
Надеемся, вам пригодятся команды и примеры их использования, о которых мы сегодня рассказали. А если они вам и правда пригодились — возможно, вам будет интересно почитать продолжение этого материала.
Электронная библиотека
Как видно из табл. 3.5, в ICMP определено множество различных типов сообщений, включая пять типов сообщений об ошибках.
Сообщения об ошибках «пункт назначения недоступен»
Изначально ICMP требовался для того, чтобы маршрутизатор мог сообщить о проблемах при доставке пакета. Если маршрутизатор не в состоянии направить пакет по нужному пути, он генерирует сообщение об ошибке типа 3 и посылает его компьютеру-источнику. Поскольку генерация такого рода сообщений была основной задачей ICMP, сообщения «пункт назначения недоступен» имеют наибольшее количество вариантов. Шестнадцать (0—15) кодов ошибок сообщения «пункт назначения недоступен» приведены в табл. 3.6.
Сообщения об ошибках ICMP типа пункт назначения недоступен
Сеть недоступна (network unreacnable)
Компьютер недоступен (host unreachable)
Протокол недоступен (protocol unreachable)
Порт недоступен (port unreachable)
Фрагментация необходима, но запрещена (fragmentation needed and DF set)
Маршрутизация на заказ не удалась (source route failed)
Сеть назначения неизвестна (destination network unknown)
Компьютер назначения неизвестен (destination host unknown)
Компьютер-источник изолирован (устарело) (source host isolated)
Доступ в сеть назначения запрещен (destination network administratively prohibited)
Доступ в компьютер назначения запрещен (destination host administratively prohibited)
Для этого типа службы компьютер недоступен (host unreachable for type-of-service, TOS)
Связь запрещена из-за фильтрации (communication administratively prohibited by filtering)
He соблюдается приоритет хоста (host precedence violation)
Снижение приоритета (precedence cutoff in effect)
Протокол IP не гарантирует доставку данных. С другой стороны, он почти всегда успешно справляется с доставкой. Если IP не удается доставить датаграмму, значит, возникла сетевая проблема, например ошибки при маршрутизации. Если вы внимательно изучили табл. 3.6, то, наверное, заметили, что большинство сообщений об ошибках относятся либо к компьютеру, либо к сети. Как правило, сообщения, относящиеся к компьютеру, означают проблему с доставкой, а сообщения, относящиеся к сети, — проблему с маршрутизацией. Так, например, код ошибки «сеть недоступна» означает проблему с маршрутизацией. На рис. 3.13 изображен формат ICMP-сообщения «пункт назначения недоступен».
Формат сообщения подобен общему формату, изображенному на рис. 3.12. Тип сообщения в поле типа равен трем, а поле кода (Code) соответствует коду ошибки от 0 до 15. Кроме того, в ICMP-сообщении содержится заголовок IР-датаграммы, вызвавшей его появление, и первые 64 бита (восемь байт) ее данных.
Не используется (заполняется нулями)
IP-заголовок, включая опции и первые 64 бита данных их первоначальной датаграммы
Рис. 3.13. Формат ICMP-сообщения «пункт назначения недоступен»
Пункт назначения может быть недоступен, если IP-заголовок содержит неправильный адрес назначения, либо если какое-нибудь промежуточное сетевое устройство выключено, либо, что менее вероятно, в таблице маршрутизации отсутствует путь к сети назначения. Все маршрутизаторы обязаны сообщать о сбое при доставке пакета источнику этого пакета. К сожалению, сами эти сообщения могут теряться. Существующая вероятность потери сообщения об ошибке делает протокол ICMP ненадежным.
Сообщения об ошибках перенаправления
Чтобы выяснить, по какому маршруту послать пакет, переключатели пакетов TCP/IP пользуются таблицами маршрутизации. Маршрутизация пакета основывается на номере сети назначения, а идентификатор сети назначения — это часть IP-адреса. Каждый маршрутизатор знает своего соседа, то есть следующую «остановку», которых может быть несколько, на пути пакета данных. В некоторых случаях к определенной сети могут вести несколько маршрутов. Для постоянного слежения за состоянием сети маршрутизаторы периодически обмениваются сообщениями. Тем не менее таблицы маршрутизации обновляются не очень часто. Исходные данные для них хранятся в местных файлах конфигурации — это минимально необходимая для начала работы маршрутизатора информация, как правило, адрес другого маршрутизатора или шлюза.
Компьютеры обновляют свои таблицы, основываясь на информации от маршрутизаторов и сообщения о перенаправлении ICMP — один из способов решать эту задачу.
Предположим, что ваш компьютер посылает датаграмму на компьютер коллеги, расположенный, как показано на рис. 3.14, в другой физической сети. Чтобы послать датаграмму, необходимо обратиться к маршрутизатору. Предположим, что датаграмма посылается маршрутизатору номер 2. Исследовав свою таблицу, маршрутизатор обнаружит, что компьютер коллеги находится на расстоянии одного «прыжка» от маршрутизатора номер 1 и что именно ему следует послать датаграмму. В результате датаграмма отправляется к маршрутизатору номер 1.
Кроме того, маршрутизатор номер 2 знает (из содержимого датаграммы и собственной таблицы), что ваш компьютер подсоединен к маршрутизатору номер 1 напрямую, а следовательно, датаграмму можно слать сразу ему — это будет оптимальный маршрут. Как только маршрутизатор определит, что существует лучший маршрут, он отправит ICMP-сообщение о перенаправлении компьютеру-источнику датаграммы. На рис. 3.15 показан формат сообщения о перенаправлении.
IP-заголовок, включая опции и первые 64 бита данных их первоначальной датаграммы
3.15. ICMP-сообщение о перенаправлении (тип 5)
Компьютер-передатчик выясняет, что следующие датаграммы лучше слать маршрутизатору, IP-адрес которого содержится в ICMP-сообщении. Другими словами, получив ICMP-сообщение о перенаправлении, ICMP-модуль компьютера должен исследовать содержимое заголовка IP-датаграммы (в теле сообщения) и IP-адрес маршрутизатора (второе 32-битное слово в заголовке сообщения). IP-заголовок даст адрес, по которому датаграммы шли неверным маршрутом, а IP-адрес маршрутизатора — тот маршрутизатор, который нужно использовать следующим. Эта информация может потребоваться для обновления таблицы маршрутизации сетевого компьютера. В табл. 3.7 приведены четыре кода сообщений о перенаправлении (тип 5). В примере на рис. 3.14 маршрутизатор пошлет сообщение типа 5 с кодом 1 (перенаправление для хоста).
ICMP-сообщения об ошибках перенаправления (тип 5)
Перенаправление для сети
Перенаправление для хоста (сетевого компьютера)
Перенаправление для сети по типу сетевой службы (TOS)
Перенаправление для хоста по типу сетевой службы (TOS)
Как видим, маршрутизатор может перенаправить сообщение, основываясь на содержимом поля «тип сетевой службы» (TOS) IP-заголовка датаграммы. Поле TOS заголовка датаграммы определяет ее приоритет. Хотя это поле применяется редко, в будущем, несомненно, его значение возрастет. Поэтому в ICMP заложена возможность помогать сетевым компьютерам обновлять таблицы маршрутизации, в зависимости от типа сетевой службы, которой принадлежит та или иная датаграмма. Протокол ICMP ограничивает сферу применения сообщений о перенаправлении. Каждый сетевой компьютер, в принципе, может работать маршрутизатором. Однако только системы, сконфигурированные как маршрутизаторы, могут посылать ICMP-сообщения о перенаправлении. Обыкновенный сетевой компьютер сделать этого не может. Далее, маршрутизаторы не обновляют свои таблицы, основываясь на сообщениях о перенаправлении. Вместо этого маршрутизаторы используют специальные протоколы.
Ошибки типа «лимит времени исчерпан»
Как известно, ошибки в таблицах маршрутизации могут привести к зацикливанию пакета между двумя маршрутизаторами. Это может случиться, когда каждый из них считает, что соседний маршрутизатор — наилучшее место для передачи пакета по назначению. Заголовок IP-датаграммы содержит специальное поле «время существования» (Time-to-Live, TTL), в котором время существования датаграммы ограничивается. Каждый маршрутизатор на пути пакета уменьшает время его существования. Время существования также уменьшается каждую секунду, которую пакет проводит во входной или выходной очереди маршрутизатора.
Как только время существования в поле TTL IP-датаграммы сравняется с нулем, сетевые программы уничтожат пакет и вышлют ICMP-сообщение «лимит времени исчерпан» (тип 11) компьютеру-источнику пакета. Формат ICMP-сообщения «лимит времени исчерпан» такой же, как у сообщения «пункт назначения недоступен», но поле Туре равно 11 вместо 3. Сообщения «лимит времени исчерпан» бывают двух видов, как показано в табл. 3.8. Код 0 устанавливается в случае, если датаграмма исчерпала время существования во время пересылки (например, из-за описанного выше зацикливания). Код 1 устанавливается, если произошел сброс таймера сборки фрагментов датаграммы до того, как все фрагменты прибыли.
ICMP-сообщения об ошибках «лимит времени исчерпан» (тип 11)
Поле время существования (TTL) сравнялось с нулем во время передачи датаграммы
Таймер сборки фрагментов истек
Когда компьютер-получатель принимает датаграмму с установленным флагом «фрагмент-продолжение», запускается таймер сборки фрагментов. Все фрагменты обязаны появиться до того, как этот таймер истечет. Если таймер истек, а датаграмма все еще не собрана, она уничтожается. В этом случае генерируется ICMP-сообщение типа 11 с кодом 1.
Ошибки «неверный параметр»
Компьютеры и маршрутизаторы высылают такое сообщение, если источник проблемы с маршрутизацией или доставкой неизвестен. Существуют два типа таких ICMP-сообщений, как показано в табл. 3.9.
ICMP-сообщение об ошибке «неверный параметр» (тип 12)
Необходимая опция отсутствует
Сообщение с кодом 1 генерируется, если датаграмма не содержит всех необходимых для нормальной работы TCP/IP атрибутов (опций). Предположим, вы разработали криптозащищенный протокол для работы с приложениями государственной важности. Если программа-клиент попытается передать запрос к серверу и не приложит специального секретного ключа к датаграмме, сервер ответит сообщением об ошибке типа «необходимая опция отсутствует». Сообщение типа «неверный IP-заголовок» генерируется во всех остальных случаях, когда источник ошибки невозможно распознать. На рис. 3.16 приведен формат сообщения ICMP «неверный параметр». Поле указателя (pointer) идентифицирует тот байт датаграммы, который привел к возникновению ICMP-сообщения. Для сообщений с кодом 1 («необходимая опция отсутствует») поле указателя равно нулю.
Не используется (заполняется нулями)
IP-заголовок, включая опции и первые 64 бита данных их первоначальной датаграммы
Сообщение об ошибке «столкновение данных»
Механизм контроля потока данных гарантирует, что передатчик не будет передавать быстрее, чем приемник в состоянии принять и обработать. Другими словами, гарантируется, что входной буфер приемника не переполнится. Протокол TCP обеспечивает механизм управления потоком в качестве одной из сетевых служб. К сожалению, управление потоком возможно лишь тогда, когда протокол ориентирован на соединение. Поскольку IP не ориентирован на соединение, он не умеет управлять потоком данных. Поскольку маршрутизаторы работают на уровне IP, в их входных очередях может создаваться аналог транспортной пробки в часы пик в результате слишком большого количества вновь приходящих IP-пакетов. Если маршрутизатор не успевает обработать все приходящие пакеты, то «лишние» пакеты уничтожаются, а компьютеру-источнику пакета направляется ICMP-сообщение об ошибке «столкновение данных» (тип 4). Сообщение «столкновение данных» указывает компьютеру на необходимость снизить скорость передачи. На самом деле, механизм сообщений «столкновение данных» является некоторым подобием управления потоком данных на уровне IP. Для каждого уничтоженного в результате столкновения пакета, маршрутизатор высылает ICMP-сообщение. Как только компьютер получает его, он тут же снижает скорость передачи.
Если маршрутизатор продолжает передавать ICMP-сообщения «столкновение данных», компьютер продолжает снижать скорость передачи. Как только ICMP-сообщения перестают появляться, компьютер вновь начинает увеличивать скорость. И так до тех пор, пока не будет достигнута оптимальная скорость. Формат сообщения
ICMP «столкновение данных» тот же, что и у сообщения «пункт назначения недоступен», только поле типа имеет значение 4. Сообщение «столкновение данных» бывает только единственного вида, то есть поле кода у него всегда имеет значение 0 — других кодов не бывает.
Срочно?
Закажи у профессионала, через форму заявки
8 (800) 100-77-13 с 7.00 до 22.00