Диагностика сетевого подключения (ping, arp, traceroute, dig, nslookup)
Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.
Для операционных систем семейства 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). Все пакеты, предназначенные для внешних сетей, должны направляться на указанный в маршруте адрес через обозначенный сетевой интерфейс.
Если в настройках интерфейса есть ошибки, их необходимо исправить — помогут в этом другие статьи, для ОС Ubuntu 18.04 или CentOS. Если же все верно — приступаем к диагностике с помощью утилиты ping. Данная команда отправляет специальные сетевые пакеты на удаленный IP-адрес (ICMP Request) и ожидает ответные пакеты (ICMP Reply). Таким образом можно проверить сетевую связность — маршрутизируются ли сетевые пакеты между IP-адресами отправителя и получателя.
Синтаксис команды ping IP/имя опции:
Скриншот №3. Синтаксис команды
В данном случае видим, что на оба сетевых пакета, отправленных на адрес нашего шлюза по умолчанию, получены ответы, потерь нет. Это значит, что на уровне локальной сети со связностью все в порядке. Помимо количества полученных/потерянных сетевых пакетов мы можем увидеть время, которое было затрачено на прохождение запроса и ответа – параметр RTT (Round Trip Time). Этот параметр может быть очень важен при диагностике проблем, связанных с нестабильностью связи и скоростью соединения.
Часто используемые параметры:
В случае, если при использовании команды ping пакеты от шлюза (или другого хоста, находящегося в одной локальной сети с сервером-отправителем) в ответ не приходят, стоит проверить сетевую связность на уровне Ethernet. Здесь для коммуникации между устройствами используются так называемые MAC-адреса сетевых интерфейсов. За разрешение Ethernet-адресов отвечает протокол ARP (Address Resolution Protocol) и с помощью одноименной утилиты мы можем проверить корректность работы на этом уровне. Запустим команду arp –n и проверим результат:
Команда выведет список IP-адресов (так как был использован аргумент –n), и соответствующие им MAC-адреса хостов, находящиеся в одной сети с нашим сервером. Если в этом списке есть IP, который мы пытаемся пинговать, и соответствующий ему MAC, значит сеть работает и, возможно, ICMP-пакеты, которые использует команда ping, просто блокируются файрволом (либо со стороны отправителя, либо со стороны получателя). Подробнее об управлении правилами файрвола рассказано здесь и здесь.
Часто используемые параметры:
Если все предыдущие шаги завершены корректно, проверяем работу маршрутизатора — запускаем ping до сервера за пределами нашей сети, например, 8.8.8.8 (DNS-сервис от Google). Если все работает корректно, получаем результат:
В случае проблем на этом шаге, нам может помочь утилита traceroute, которая используя ту же логику запросов и ответов помогает увидеть маршрут, по которому движутся сетевые пакеты. Запускаем traceroute 8.8.8.8 –n и изучаем вывод программы:
Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.
Часто используемые опции:
Диагностика разрешения имен (nslookup, dig)
Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.
Самый простой способ проверить работает ли разрешение имен — запустить утилиту ping с указанием доменного имени вместо IP-адреса (например, ping ya.ru). Если ответные пакеты от удаленного сервера приходят, значит все работает как надо. В противном случае нужно проверить прописан ли DNS-сервер в сетевых настройках и удается ли получить от него ответ.
Способы выяснения какой DNS-сервер использует наш сервер различаются в зависимости от используемой версии и дистрибутива ОС Linux. Например, если ОС используется Network Manager для управления сетевыми интерфейсами (CentOS, RedHat и др.), может помочь вывод команды nmcli:
Используемый сервер также будет указан в настройках интерфейса, в разделе 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
После успешной установки сделаем тестовые запросы:
В разделе Answer Section видим ответ от DNS сервера — IP-адрес для A-записи с доменным именем ya.ru. Разрешение имени работает корректно:
Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.
Что же делать, если в ответе отсутствует IP-адрес? Возможно, DNS-сервер недоступен. Для проверки можно отправить тестовый запрос на другой DNS-сервер. Обе утилиты позволяют эти сделать. Направим тестовый запрос на DNS-сервер Google:
Скриншот №11. Отправка тестового запроса 1
nslookup ya.ru 8.8.8.8
Скриншот №12. Отправка тестового запроса 2
Если имена разрешаются публичным DNS-сервером корректно, а установленным по умолчанию в ОС нет, вероятно, есть проблема в работе этого DNS-сервера. Временным решением данной проблемы может быть использование публичного DNS-сервера в качестве сервера для разрешения имен в операционной системе. В том случае, если разрешение имен не работает ни через локальный, ни через публичный DNS сервер — стоит проверить не блокируют ли правила файрвола отправку на удаленный порт 53 TCP/UDP пакетов (именно на этом порту DNS-серверы принимают запросы).
Часто используемые параметры:
Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.
Диагностика сетевых проблем с помощью Looking Glass
Для многих наших клиентов критерием выбора серверных услуг является сетевая связность. Под сетевой связностью понимается степень взаимодействия сети одного оператора с сетями других операторов и, как следствие, количество маршрутов и количество промежуточных узлов для интернет-трафика.
Проверку сетевой связности удобно осуществлять с помощью сервисов, называемых «Looking Glass» (в переводе с английского — зеркало). Они позволяют проверять маршрутизацию из удаленной сети. Такие сервисы есть у многих организаций (с информацией обо всех Looking Glass мира можно ознакомиться, например, здесь).
Свой сервис «Looking Glass» есть и у нашей компании. Он расположен по адресу: http://lg.selectel.ru. Диагностика с помощью «Looking Glass» позволяет конкретизировать возникшую неисправность и выдвинуть обоснованное предположение о ее причине. О диагностических процедурах, которые можно осуществить с помощью этого сервиса, пойдет речь ниже.
Интерфейс нашего «Looking Glass» предельно прост:
Все команды выполняются с двух маршрутизаторов, расположенных в Санкт-Петербурге и в Москве (выбрать маршрутизатор можно, установив флажок в поле Router; можно осуществлять проверку с двух маршрутизаторов одновременно).
Команда ping
С помощью этой команды можно проверить доступность указанного узла используя специальный протокол ICMP. Принцип ее работы заключается в следующем: получив команду ping, маршрутизатор отправляет запросы к указанному узлу, который, в свою очередь, отправляет его обратно (по тому адресу, откуда он пришел). Из результатов запроса ping можно узнать, (1) вернулись ли отправленные пакеты обратно и (2) сколько времени (в миллисекундах) потребовалось для движения пакетов туда и обратно.
Результаты команды ping могут выглядеть, например, так:
Из этого примера видно, что узел назначения исправно отвечает на запросы, потерь пакетов нет. Рассмотрим еще один пример:
В данном случае из результатов видно, что узел назначения доступен, потери пакетов нет, но время ответа несколько увеличено по причине географической удаленности: узел назначения находится в Японии, а запросы отправлялись из Санкт-Петербурга.
Иногда может иметь место и такая ситуация:
Результаты работы команды в данном случае показывают, что ни один из пакетов не дошел до цели и что узел, скорее всего, недоступен, или не отвечает на ICMP-запросы.
Таким образом, с помощью запроса ping можно проверить соединение с удаленным узлом. Сам факт успешного возвращения запросов дает основания предполагать, что все устройства на пути от маршрутизатора к указанному узлу работают нормально. Следует отметить, что потеря пакетов может иметь место даже при отсутствии неисправностей: она может быть обусловлена, например, перегруженностью сети. Часто бывает и так, что маршрутизаторы дают диагностирующим пакетам низкий приоритет. Но если хотя бы один из отправленных пакетов возвращается, то это уже свидетельствует о наличии соединения и доступности узла.
На основании результатов запроса ping однозначного вывода о наличии неисправности сделать невозможно. Можно лишь выдвинуть предположение, которое нуждается в дополнительной проверке с помощью других инструментов.
Команда traceroute
Проблемы с доступностью веб-сервисов могут также быть обусловлены техническими проблемами на промежуточных узлах, через которые проходят пакеты на пути к хосту назначения. Выявить эти проблемы можно с помощью команды traceroute.
Как работает эта команда? Одной из характеристик пересылаемых по сети пакетов является время жизни (англ. time to live, сокращенно TTL) — число хопов (англ. hop — прыжок, т.е. переход пакета от одного маршрутизатора — к другому) или время в миллисекундах, в течение которого пакет может находиться в сети. Каждый маршрутизатор, обрабатывающий пакет, уменьшает значение TTL на единицу. Когда TTL становится равным нулю, пакет уничтожается, а отправителю высылается ICMP-сообщение time exceeded (время истекло). Изначально этот механизм использовался для предотвращения бесконечного копирования сетевых пакетов при ошибочном закольцевании сети.
Получив команду traceroute, маршрутизатор отправляет в направлении хоста назначения пакет с TTL=1. Узел, с которого приходит ответ time exceeded, определяется как первый хоп (т.е. первый шаг на пути к цели). Затем поочередно отправляются пакеты с TTL=2,3,4,5 и так далее — до тех пор, пока один из пакетов не достигнет узла назначения и не получит от него ответ.
В результате на экран выводится список всех промежуточных узлов на пути пакета от маршрутизатора к узлу назначения. Он может, выглядеть, например, так:
Что видно из представленного результата?
В девятом переходе вместо одного из значений времени ответа отображается звездочка. Это означает, что на какой-то из отправленных пакетов не было получено ответа. Это может быть вызвано, например, перегрузкой сети. Или тем, что многие маршрутизаторы отбрасывают низкоприоритетные ICMP-пакеты. Появление таких звездочек в выводе traceroute — вполне типичная ситуация, которая не является причиной для беспокойства.
Если для одного из промежуточных маршрутизаторов отображается три звездочки, то это значит, что от него не было получено ни одного ответа. Но не следует делать вывода о наличии неисправности на основании одних лишь этих звездочек. Их появление может быть обусловлено самыми разными причинами. Например, маршрутизаторы нередко конфигурируют таким образом, чтобы они “молча” отбрасывали устаревшие пакеты. В этом случае пакеты благополучно переходят на следующий маршрутизатор.
Причина может заключаться и в том, что ответные пакеты от этого маршрутизатора идут слишком долго, и Looking Glass перестает ждать их прибытия. Если же три звездочки отображаются для узлов в конце маршрута (как в приведенном примере), то это, скорее всего, свидетельствует о том, что пакеты до узла назначения не дошли.
Интерпретация выводов traceroute представляет собой более сложную и тонкую задачу, чем это может показаться на первый взгляд; более подробно об этом можно прочитать здесь и здесь (на английском языке).
Команды для диагностики BGP
BGP (англ. Board Gateway Protocol, протокол граничного шлюза) — это основной протокол динамической маршрутизации в Интернете. Он предназначен для обмена информацией не между отдельными маршрутизаторами, а между автономными системами. Автономной системой, согласно определению, данному в RFC1930, называется система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами и имеющими отдельную политику маршрутизации с Интернетом. Собственно, Интернет можно рассматривать как набор связанных друг с другом автономных систем.
С помощью BGP-протокола автономные системы сообщают друг другу: (1) о факте своего существования и (2) о том, какие сети могут быть получены через них. Они также собирают информацию о том, как добраться до других сетей в Интернете. Получая информацию о маршрутах до цели назначения, они определяют из них наилучший (на основе правил сети, а не технических метрик) и добавляют в свои таблицы маршрутизации. Именно поэтому BGP-протокол иногда называют клеем, связующим весь Интернет.
Протокол BGP был создан во времена, когда в Интернете не существовало многих проблем и опасностей, которые существуют сегодня, и он характеризуется повышенной уязвимостью. Ошибки в работе протокола, которые могут быть вызваны как техническими проблемами конкретной автономной системы, так и намеренными действиями злоумышленников, могут приводить к очень серьезным последствиям (более подробно об этом можно прочитать, например, здесь). В результате этих ошибок трафик перенаправляется и/или отбрасывается, не доходя до сети назначения — из-за этого возникают проблемы с сетевой доступностью.
Проверить работу BGP-протокола можно при помощи команд bgp route detail, bgp route terse и bgp summary. Результатом работы команды bgp route detail является таблица маршрутизации c перечнем всех автономных станций на пути движения пакетов. Команда bgp terse выводит на экран сокращенный вариант таблицы маршрутизации. Команда bgp summary выводит список всех автономных систем, с которыми есть связность у наших маршрутизаторов.
Заключение
В этой статье мы привели лишь краткое описание возможностей нашего сервиса «Looking Glass». Диагностика сетевых проблем представляет собой тему, которую невозможно охватить в рамках одной публикации. Если у вас возникли вопросы по работе нашего «Looking Glass» — добро пожаловать в комментарии. Будем также рады конструктивным замечаниям и предложениям по работе сервиса.
Для тех кто не может комментировать посты на Хабре, приглашаем к нам в блог.
Как проверить сетевое соединение
Для комфортной работы в интернете важны скорость и стабильность сетевого соединения.
Иногда с подключением к сети возникают неполадки — в результате долго скачиваются файлы или не загружаются веб-страницы. Чтобы узнать, почему появилась проблема, проверьте сетевое соединение.
Проведите встроенную диагностику
Проверьте доступ к сети с помощью средства устранения неполадок для Windows и программы беспроводной диагностики для macOS. Выберите операционную систему:
Запустите средство устранения сетевых неполадок:
Запустите средство устранения сетевых неполадок:
Подробнее о ней см. в разделе Анализ среды беспроводной сети на сайте службы поддержки Apple.
Воспользуйтесь сетевыми утилитами
Получите информацию для диагностики сети с помощью утилит Ping, PathPing/Traceroute и Telnet. Выберите операционную систему:
С помощью утилиты Ping можно проверить качество сетевого соединения. Утилита определяет время задержки между запросом на сервер и ответом, а также потерю пакетов данных. Чем меньше время приема-передачи и количество потерянных пакетов, тем быстрее откроется веб-страница или загрузится фильм.
Чтобы проверить сетевое соединение:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты PathPing можно определить, на каком промежуточном узле сети задерживаются или теряются пакеты данных.
Чтобы проверить промежуточные узлы сети:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты Telnet можно проверить, есть ли у компьютера права на подключение к серверу.
Вначале установите клиент Telnet:
Теперь вы можете проверить доступ к серверу:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
Выберите утилиту в зависимости от цели:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты Ping можно проверить качество сетевого соединения. Утилита определяет время задержки между запросом на сервер и ответом, а также потерю пакетов данных. Чем меньше время приема-передачи и количество потерянных пакетов, тем быстрее откроется веб-страница или загрузится фильм.
Чтобы проверить сетевое соединение:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты PathPing можно определить, на каком промежуточном узле сети задерживаются или теряются пакеты данных.
Чтобы проверить промежуточные узлы сети:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты Telnet можно проверить, есть ли у компьютера права на подключение к серверу.
Вначале включите клиент Telnet. Для этого:
Теперь вы можете проверить доступ к серверу:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
Выберите утилиту в зависимости от цели:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты Ping можно проверить качество сетевого соединения. Утилита определяет время задержки между запросом на сервер и ответом, а также потерю пакетов данных. Чем меньше время приема-передачи и количество потерянных пакетов, тем быстрее откроется веб-страница или загрузится фильм.
Чтобы проверить сетевое соединение:
Теперь текст можно вставить ( ⌘ + V ) в текстовый файл или письмо.
С помощью утилиты Traceroute можно определить, на каком промежуточном узле сети задерживаются или теряются пакеты данных.
Чтобы проверить промежуточные узлы сети:
Теперь текст можно вставить ( ⌘ + V ) в текстовый файл или письмо.
С помощью утилиты Telnet можно проверить, есть ли у компьютера права на подключение к серверу.
В macOS High Sierra 10.13 и выше программа Терминал не включает утилиту Telnet.
Чтобы установить утилиту:
Чтобы проверить доступ к серверу:
Теперь текст можно вставить ( ⌘ + V ) в текстовый файл или письмо.
Программа включает в себя Netstat, Ping, Whois и другие инструменты для работы с сетью.
Подробнее см. в разделе О программе «Сетевая утилита» на сайте службы поддержки Apple.
Как проверить сетевое соединение
Для комфортной работы в интернете важны скорость и стабильность сетевого соединения.
Иногда с подключением к сети возникают неполадки — в результате долго скачиваются файлы или не загружаются веб-страницы. Чтобы узнать, почему появилась проблема, проверьте сетевое соединение.
Проведите встроенную диагностику
Проверьте доступ к сети с помощью средства устранения неполадок для Windows и программы беспроводной диагностики для macOS. Выберите операционную систему:
Запустите средство устранения сетевых неполадок:
Запустите средство устранения сетевых неполадок:
Подробнее о ней см. в разделе Анализ среды беспроводной сети на сайте службы поддержки Apple.
Воспользуйтесь сетевыми утилитами
Получите информацию для диагностики сети с помощью утилит Ping, PathPing/Traceroute и Telnet. Выберите операционную систему:
С помощью утилиты Ping можно проверить качество сетевого соединения. Утилита определяет время задержки между запросом на сервер и ответом, а также потерю пакетов данных. Чем меньше время приема-передачи и количество потерянных пакетов, тем быстрее откроется веб-страница или загрузится фильм.
Чтобы проверить сетевое соединение:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты PathPing можно определить, на каком промежуточном узле сети задерживаются или теряются пакеты данных.
Чтобы проверить промежуточные узлы сети:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты Telnet можно проверить, есть ли у компьютера права на подключение к серверу.
Вначале установите клиент Telnet:
Теперь вы можете проверить доступ к серверу:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
Выберите утилиту в зависимости от цели:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты Ping можно проверить качество сетевого соединения. Утилита определяет время задержки между запросом на сервер и ответом, а также потерю пакетов данных. Чем меньше время приема-передачи и количество потерянных пакетов, тем быстрее откроется веб-страница или загрузится фильм.
Чтобы проверить сетевое соединение:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты PathPing можно определить, на каком промежуточном узле сети задерживаются или теряются пакеты данных.
Чтобы проверить промежуточные узлы сети:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты Telnet можно проверить, есть ли у компьютера права на подключение к серверу.
Вначале включите клиент Telnet. Для этого:
Теперь вы можете проверить доступ к серверу:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
Выберите утилиту в зависимости от цели:
Скопированный текст можно вставить ( Ctrl + V ) в текстовый файл или письмо.
С помощью утилиты Ping можно проверить качество сетевого соединения. Утилита определяет время задержки между запросом на сервер и ответом, а также потерю пакетов данных. Чем меньше время приема-передачи и количество потерянных пакетов, тем быстрее откроется веб-страница или загрузится фильм.
Чтобы проверить сетевое соединение:
Теперь текст можно вставить ( ⌘ + V ) в текстовый файл или письмо.
С помощью утилиты Traceroute можно определить, на каком промежуточном узле сети задерживаются или теряются пакеты данных.
Чтобы проверить промежуточные узлы сети:
Теперь текст можно вставить ( ⌘ + V ) в текстовый файл или письмо.
С помощью утилиты Telnet можно проверить, есть ли у компьютера права на подключение к серверу.
В macOS High Sierra 10.13 и выше программа Терминал не включает утилиту Telnet.
Чтобы установить утилиту:
Чтобы проверить доступ к серверу:
Теперь текст можно вставить ( ⌘ + V ) в текстовый файл или письмо.
Программа включает в себя Netstat, Ping, Whois и другие инструменты для работы с сетью.
Подробнее см. в разделе О программе «Сетевая утилита» на сайте службы поддержки Apple.
