Какая утилита пытается обнаружить маршрутизаторы на пути следования пакета
Обновлено: 06.07.2024
Рассмотрим основные программы, позволяющие читать и изменять сетевые параметры, диагностировать и выявлять ошибки при работе сети.
В различных ОС существуют свои наборы утилит. Сравним их для двух систем, например, Microsoft Windows NT и Sun Solaris. Какими бы разными ни были эти ОС, в каждой из них реализована модель OSI . Естественно, программная и аппаратная реализация стека этой модели у них различается, но взаимодействие всех уровней осуществляется по установленному стандарту.
IPCONFIG (IFCONFIG)
Начнем с утилиты, которая позволяет просматривать, проверять и изменять сетевые настройки. Обычно эти настройки включают в себя информацию 3-го (сетевого) уровня – IP-адрес, маску подсети и т.д. Для работы с ними в ОС Windows можно использовать команду ipconfig . Она выдает информацию об IP- адресе, маске подсети (netmask), роутере по умолчанию ( default gateway ). Задав дополнительный параметр -all , можно получить более подробную информацию – имя компьютера, имя домена, тип сетевой карты , MAC-адрес и т.д.
В ОС Solaris для получения IP-адреса и прочих сетевых настроек используется команда ifconfig . Она также показывает название интерфейса, IP-адреса, маску подсети, MAC-адрес.
Как уже было сказано ранее, в оперативной памяти компьютера находится ARP-таблица. В ней содержатся MAC-адрес удаленной машины и соответствующий ему IP-адрес. Для просмотра этой таблицы используется команда arp . Например, arp –a выводит все известные MAC- адреса.
Существует два типа записей в ARP-таблице – статический и динамический. Статическая запись вносится вручную и существует до тех пор, пока вручную же не будет удалена, или компьютер (маршрутизатор) не будет перезагружен.
Для выявления различных неполадок в сети существует несколько утилит, которые позволяют определить, на каком уровне модели OSI произошел сбой, или указаны неверные настройки сетевых протоколов. Одна из таких утилит – ping .
Протокол ICMP находится на стыке двух уровней – сетевого и транспортного. Основной принцип действия этого протокола – формирование ICMP эхо-запроса (echo-request) и эхо-ответа (echo-reply). Запрос эха и ответ на него может использоваться для проверки достижимости хоста- получателя и его способности отвечать на запросы. Также прохождение эхо-запроса и эхо-ответа проверяет работоспособность основной части транспортной системы, маршрутизацию на машине источника, работоспособность и корректную маршрутизацию на роутерах между источником и получателем, а также работоспособность и правильность маршрутизации получателя.
Таким образом, если на посланный echo-request возвращается корректный echo-reply от машины, которой был послан запрос, можно сказать, что транспортная система работает корректно. И если браузер не может отобразить web-страницу, то проблема, по всей видимости, не в первых трех уровнях модели OSI.
Traceroute
Утилита traceroute также использует протокол ICMP для определения маршрута прохождения пакета. При отсылке traceroute устанавливает значение TTL последовательно от 1 до 30 . Каждый маршрутизатор, через который проходит пакет на пути к назначенному хосту, уменьшает значение TTL на единицу. С помощью TTL происходит предотвращение зацикливания пакета в "петлях" маршрутизации, иначе "заблудившиеся" пакеты окончательно перегрузили бы сеть. Однако, при выходе маршрутизатора или линии связи из строя требуется несколько дополнительных переходов для понимания, что данный маршрут потерян и его необходимо обойти. Чтобы предотвратить потерю датаграммы , поле TTL устанавливается на максимальную величину.
Рассмотрим пример выполнения утилиты traceroute .
Первая строка содержит имя и IP-адрес хоста назначения, максимальное значение TTL и размер посылаемого пакета (38 байт). Последующие строки начинаются с TTL, после чего следует имя хоста, или маршрутизатора и его IP-адрес. Для каждого значения TTL отправляются три датаграммы . Для каждой возвращенной датаграммы определяется и выводится время возврата. Если в течение 3-х секунд на каждую из 3-х датаграмм не был получен ответ, то посылается следующая датаграмма, а вместо значения времени выводится звездочка. Время возврата – это время прохождения датаграммы от источника (хоста, выполняющего программу traceroute ) до маршрутизатора. Если нас интересует время, потраченное на пересылку между, например, 5 и 6 узлом, необходимо вычесть из значения времени TTL 6 время TTL 5.
В каждой из операционных систем сетевая часть утилиты реализована практически одинаково, но реализация на уровне приложений различается.
В ОС Solaris используется утилита traceroute . В качестве параметра задается IP-адрес, или доменное имя удаленного хоста, связь до которого требуется проверить. В примере, приведенном выше, видно успешное выполнение traceroute и корректную работу сете- зависимых уровней (физический, канальный, сетевой).
Ошибка !P означает недоступность протокола (protocol unreachable).
Route
Для просмотра и редактирования таблицы маршрутов используется утилита route . Типичный пример таблицы маршрутизации на персональном компьютере:
Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.
Для операционных систем семейства Linux написано множество утилит, помогающих в диагностике и мониторинге. Познакомимся с наиболее часто используемыми из них.
Диагностика сетевой связности (ping, arp, traceroute)
В данной статье мы будем опираться на использование протокола IP версии 4. Согласно стандартам, определяющим работу этого протокола, каждое устройство, подключенное к сети, должно иметь как минимум IP-адрес и маску подсети — параметры, которые позволяют уникально идентифицировать устройство в пределах определенной сети. В такой конфигурации устройство может обмениваться сетевыми пакетами с другими устройствами в пределах той же самой логической сети. Если к этому набору параметров добавить адрес шлюза по умолчанию — наш сервер сможет связываться с хостами, находящимися за пределами локального адресного пространства.
В случае каких-либо сетевых проблем в первую очередь проверяем, не сбились ли настройки сетевого интерфейса. Например, команды ip addr или ifconfig выведут IP-адрес и маску сети:
В выводе команды виден перечень сетевых интерфейсов, распознанных операционной системой. Интерфейс lo — это псевдоинтерфейс (loopback). Он не используется в реальных взаимодействиях с удаленными хостами, а вот интерфейс с именем ens192 — то, что нам нужно (именование сетевых интерфейсов различается в разных ветках и версиях ОС Linux). IP-адрес и маска сети, назначенные этому интерфейсу, указаны в поле inet — /24 после адреса обозначают 24-битную маску 255.255.255.0.
Теперь проверим, указан ли шлюз по умолчанию. Команды ip route или route покажут имеющиеся маршруты:
В таблице маршрутизации мы видим, что имеется маршрут по умолчанию (обозначается либо ключевым словом default, либо адресом 0.0.0.0). Все пакеты, предназначенные для внешних сетей, должны направляться на указанный в маршруте адрес через обозначенный сетевой интерфейс.
Синтаксис команды ping IP/имя опции:
Скриншот №3. Синтаксис команды
В данном случае видим, что на оба сетевых пакета, отправленных на адрес нашего шлюза по умолчанию, получены ответы, потерь нет. Это значит, что на уровне локальной сети со связностью все в порядке. Помимо количества полученных/потерянных сетевых пакетов мы можем увидеть время, которое было затрачено на прохождение запроса и ответа – параметр RTT (Round Trip Time). Этот параметр может быть очень важен при диагностике проблем, связанных с нестабильностью связи и скоростью соединения.
Часто используемые параметры:
- ping –c количество — указать количество пакетов, которое будет отправлено адресату (по умолчанию пакеты отправляются до тех пор, пока пользователь не прервет выполнение команды. Этот режим можно использовать, чтобы проверить стабильность сетевого соединения. Если параметр RTT будет сильно изменяться в ходе проверки, значит где-то на протяжении маршрута есть проблема);
- ping –s количество — указать размер пакета в байтах. По умолчанию проверка производится малыми пакетами. Чтобы проверить работу сетевых устройств с пакетами большего размера, можно использовать этот параметр;
- ping –I интерфейс — указать сетевой интерфейс, с которого будет отправлен запрос (актуально при наличии нескольких сетевых интерфейсов и необходимости проверить прохождение пакетов по конкретному сетевому маршруту).
В случае, если при использовании команды ping пакеты от шлюза (или другого хоста, находящегося в одной локальной сети с сервером-отправителем) в ответ не приходят, стоит проверить сетевую связность на уровне Ethernet. Здесь для коммуникации между устройствами используются так называемые MAC-адреса сетевых интерфейсов. За разрешение Ethernet-адресов отвечает протокол ARP (Address Resolution Protocol) и с помощью одноименной утилиты мы можем проверить корректность работы на этом уровне. Запустим команду arp –n и проверим результат:
Команда выведет список IP-адресов (так как был использован аргумент –n), и соответствующие им MAC-адреса хостов, находящиеся в одной сети с нашим сервером. Если в этом списке есть IP, который мы пытаемся пинговать, и соответствующий ему MAC, значит сеть работает и, возможно, ICMP-пакеты, которые использует команда ping, просто блокируются файрволом (либо со стороны отправителя, либо со стороны получателя). Подробнее об управлении правилами файрвола рассказано здесь и здесь.
Часто используемые параметры:
- arp –n — вывод содержимого локального arp-кэша в числовом формате. Без этой опции будет предпринята попытка определить символические имена хостов;
- arp –d адрес — удаление указанного адреса из кэша. Это может быть полезно для проверки корректности разрешения адреса. Чтобы убедиться, что в настоящий момент времени адрес разрешается корректно, можно удалить его из кэша и снова запустить ping. Если все работает правильно, адрес снова появится в кэше.
Если все предыдущие шаги завершены корректно, проверяем работу маршрутизатора — запускаем ping до сервера за пределами нашей сети, например, 8.8.8.8 (DNS-сервис от Google). Если все работает корректно, получаем результат:
Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.
Часто используемые опции:
- traceroute –n — вывод результата в числовом формате вместо символических имен промежуточных узлов;
- traceroute –I — использование ICMP-протокола при отслеживании маршрута. По умолчанию используются UDP-датаграммы;
- traceroute –s адрес— указать адрес источника для исходящего сетевого пакета;
- traceroute –i интерфейс— указать сетевой интерфейс, с которого будут отправляться пакеты.
Диагностика разрешения имен (nslookup, dig)
Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.
Способы выяснения какой DNS-сервер использует наш сервер различаются в зависимости от используемой версии и дистрибутива ОС Linux. Например, если ОС используется Network Manager для управления сетевыми интерфейсами (CentOS, RedHat и др.), может помочь вывод команды nmcli:
В настройках сетевого интерфейса, в разделе DNS configuration, мы увидим IP-адрес сервера. В Ubuntu 18.04 и выше, использующих Netplan, используем команду systemd-resolve --status:
Используемый сервер также будет указан в настройках интерфейса, в разделе DNS Servers. В более старых версиях Ubuntu потребуется проверить содержимое файлов /etc/resolve.conf и /etc/network/interfaces. Если сервер не указан, воспользуйтесь статьей для ОС Ubuntu 18.04 или CentOS, чтобы скорректировать настройки.
Проверить работу сервиса разрешения имен нам помогут утилиты nslookup или dig. Функционально они почти идентичны: G-вывод утилиты dig содержит больше диагностической информации и гибко регулируется, но это далеко не всегда нужно. Поэтому используйте ту утилиту, которая удобна в конкретной ситуации. Если эти команды недоступны, потребуется доставить пакеты на CentOS/RedHat:
yum install bind-utils
sudo apt install dnsutils
После успешной установки сделаем тестовые запросы:
Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.
Скриншот №11. Отправка тестового запроса 1
Скриншот №12. Отправка тестового запроса 2
Если имена разрешаются публичным DNS-сервером корректно, а установленным по умолчанию в ОС нет, вероятно, есть проблема в работе этого DNS-сервера. Временным решением данной проблемы может быть использование публичного DNS-сервера в качестве сервера для разрешения имен в операционной системе. В том случае, если разрешение имен не работает ни через локальный, ни через публичный DNS сервер — стоит проверить не блокируют ли правила файрвола отправку на удаленный порт 53 TCP/UDP пакетов (именно на этом порту DNS-серверы принимают запросы).
Часто используемые параметры:
Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.
Microsoft Windows 2000 версия этой статьи 162326см.
Аннотация
В данной статье описывается TRACERT (Trace Route), служебная программа командной строки, который можно использовать для трассировки путь, который принимает пакет Internet Protocol (IP) до места назначения. В данной статье рассматриваются следующие вопросы:
Использование служебной программы TRACERT
Использование команды TRACERT для устранения неполадок
Сведения о параметрах команды TRACERT
Дополнительная информация
Использование служебной программы TRACERT
C:\>tracert 11.1.0.1В результате выполнения команды: Tracing route to 11.1.0.1 over a maximum of 30 hops --------------------------------------------------- 1 2 ms 3 ms 2 ms 157.54.48.1 2 75 ms 83 ms 88 ms 11.1.0.67 3 73 ms 79 ms 93 ms 11.1.0.1 Trace complete.
Использование команды TRACERT для устранения неполадок
TRACERT можно использовать, чтобы узнать в каком месте сети останавливаются пакеты. В следующем примере основной шлюз обнаружил, что существует не правильный путь для размещения на 22.110.0.1. Вероятно, либо маршрутизатор имеет проблемы конфигурации или 22.110.0.0 сети не существует, отражая неправильный IP-адрес. Команда:
C:\ > tracert 22.110.0.1В результате выполнения команды: Tracing route to 22.110.0.1 over a maximum of 30 hops ----------------------------------------------------- 1 157.54.48.1 reports: Destination net unreachable. Trace complete. TRACERT полезна для устранения неполадок в больших сетях, где несколько путей может привести к той же точке или где задействовано множество промежуточных компонентов (мосты или маршрутизаторы).
Сведения о параметрах команды TRACERT
Существует несколько параметров командной строки, которые можно использовать с помощью команды TRACERT, несмотря на то, что параметры не являются обычно требуются для стандартных неполадок. В следующем примере синтаксис команды показывает все возможные варианты:
Tracert -d -h максЧисло -j списокУзлов - w Таймаут target_hostЧто делают параметры: -d Specifies to not resolve addresses to host names -h maximum_hops Specifies the maximum number of hops to search for the target -j host-list Specifies loose source route along the host-list -w timeout Waits the number of milliseconds specified by timeout for each reply target_host Specifies the name or IP address of the target host
Интернет по сути состоит из глобальной сети маршрутизаторов, которая позволяет компьютерам и серверам со всего мира связываться друг с другом. Эти маршрутизаторы обмениваются данными друг с другом, чтобы направлять или передавать пакеты данных по назначению.
">Утилита командной строки Traceroute – это инструмент, который используется для определения точного маршрута, по которому пакет данных проходит в сети Интернет от отправителя до места назначения.
При помощи команды tracert (Windows) или traceroute (Linux и Mac OS) вы легко и быстро можете определить где находится проблема, узкое место в передаче данных, задержка соединения с сервером. Также вы можете использовать утилиту, если вам просто интересно узнать какой путь проделывает пакет данных до места назначения.
Чем Tracert отличается от Ping?
Широкоизвестная команда PING используется для проверки связи с сервером. Ваш компьютер отправляет четыре пакета данных в пункт назначения, и как только они прибудут туда, пакеты вернутся обратно на ваш компьютер.
Если вы получили все или только часть пакетов данных на свой компьютер, это говорит о наличии общего соединения между вашим ПК и конечным пунктом. Кроме этого, вы получите данные о том, сколько по времени (в миллисекундах) заняло путешествие пакетов данных туда-обратно.
Traceroute даст нам больше информации – утилита не только проверит наличие связи с конечным пунктом назначения, но и с каждым маршрутизатором на этом пути. Она измерит время приема-передачи пакетов данных от каждого встреченного на пути маршрутизатора.
Как пользоваться Tracert?
Как установить проблему при помощи трассировки?
Одна из основных вещей, на которую следует обратить внимание при выполнении трассировки – это постоянное время прохождение пакета туда-обратно. На скриншотах выше указано нормальное время – оно стабильно и имеет небольшое постепенное увеличение без значительных отклонений в пределах одного узла.
Предположим, что сайт google плохо открывается на нашем ПК. Запустив команду Ping мы обнаружим, что время прохождения туда-обратно очень высокое, в среднем около 210 миллисекунд.
Проблема есть, но на каком именно этапе прохождения пакетов данных она возникает команда Ping не показывает.
Утилита Tracert поможет определить корень проблемы. Проанализируем отчет трассировки:
Сбой, как мы видим, возникает на пятом хопе, и данный маршрутизатор негативно влияет на оставшийся путь данных к месту назначения. Таким образом мы быстро обнаружили, что причина задержки передачи данных не связана с нашей локальной сетью или сервером. Проблема в удаленном роутере сети Интернет.
Что означают звездочки в отчете?
Что такое TTL?
После запуска tracert в окне командной строки можно прочесть такую фразу: «с максимальным числом прыжков 30» (на русском или английском).
Количество таких прыжков (hops) определяет параметр TTL (Time To Live), или время жизни. Он задает то, как долго переданные пакеты данных могут жить прежде чем будут отброшены. По умолчанию задаётся 30 прыжков. Если пакеты не достигают цели через 30 переходов, они автоматически отбрасываются.
Читайте также: