тестирования сети в Линукс
Эта заметка выросла из шпаргалки для самого себя. Мне по работе приходится отлавливать баги в сети. Как проверить скорость в VPN-туннеле? Почему сервер не пингуется? Или пингуется, но не доступен. Кто забил весь канал торрентами? Где пропадают пакеты? Почтовый клиент выдает непонятную ошибку, что произошло на самом деле? Эти и многие другие вопросы периодически возникают у любого пользователя. Под катом описание программ входящих во все современные дистрибутивы, начиная от пинга и до таких экзотических как ngrep. А так же картинками, если картинками можно назвать, копии дампа с консоли.
# ping -n -i 0.2 -s 512 -I eth0 ya.ru
PING ya.ru (93.158.134.8) from 10.0.94.2 eth0: 512(540) bytes of data.
520 bytes from 93.158.134.8: icmp_seq=1 ttl=59 time=17.5 ms
520 bytes from 93.158.134.8: icmp_seq=2 ttl=59 time=15.0 ms
520 bytes from 93.158.134.8: icmp_seq=3 ttl=59 time=14.7 ms
3/3 packets, 0% loss, min/avg/ewma/max = 14.757/15.777/16.899/17.512 ms
520 bytes from 93.158.134.8: icmp_seq=4 ttl=59 time=14.7 ms
^C
Ключ -n означает, что надо выводить IP адреса вместо доменных имен, это полезно если пингуете по IP, тогда не будет тратится время на разрешение доменого имя, а еще, если DNS сервер не доступен это приведет к паузе в несколько секунд. Ключ -i задает интервал между отправкой пакетов, а -s размер пакета. Размер не может быть больше, чем MTU интерфейса. При помощи комбинации ключей -i и -s можно загрузить канал на любую ширину. -I задает имя интерфейса, через который будет отправлен пакет, полезно, если надо обойти таблицу маршрутизации. Чтобы вывести статистику, как я сделал я после третьего пакета, надо послать пингу сигнал SIGQUIT, с клавиатуры это делается Cntr+\
traceroute
#traceroute -N 16 -q 1 -A ya.ru
traceroute to ya.ru (77.88.21.8), 30 hops max, 60 byte packets
1 10.94.171.1 (10.94.171.1) [AS65534] 1.402 ms
2 1.32.108.213.hl.ru (213.108.32.1) [AS47333] 1.618 ms
3 94.122.dsl.westcall.net (195.177.122.94) [AS20485/AS25408] 2.859 ms
4 b0-152.mrouter.r.westcall.net (84.52.109.161) [AS25408] 3.021 ms
5 GW-Yandex.retn.net (87.245.250.102) [AS9002] 3.266 ms
6 aluminium-vlan901.yandex.net (77.88.56.111) [AS13238] 14.037 ms
7 gallium-vlan901.yandex.net (77.88.56.126) [AS13238] 16.517 ms
8 hummer-vlan2.yandex.net (87.250.228.136) [AS13238] 16.443 ms
9 ya.ru (77.88.21.8) [AS13238] 15.809 ms
traceroute показывает маршрут до удаленного хоста. По умолчанию он работает довольно медленно, так как опрашивает каждый роутер на пути пакета, по очереди и по три раза. Вы видите три времени ответа рядом с каждым хостом или три звездочки, если он не отвечает. Но traceroute можно ускорить. Ключ -N показывает сколько шагов пути пакета, они называются хопами, найти за 1 цикл, а -q количество запросов, которые будут отправлены к хосту. Ключ -A показывает номер автономной системы. Автономная система — блок IP сетей, выделенных одному оператору.
#mtr ya.ru
Приведет к такому экрану. 
mtr это помесь пинга с трейсроутом. Наглядно видно, где проседает канал. В дебиан-образных дистрибутивах консольная версия ставится из пакета mtr-tiny
tcpdump
Иногда полезно глубже заглянуть, что же происходит в сети. Какие пакеты приходят и уходят. Например, чтобы удостовериться, что пакеты все таки уходят, а не блокируются фаерволом.
Вот что происходит при команде
В соседнем терминале запущен tcpdump
%sudo tcpdump -ni eth1 udp and port 53 and host 10.0.1.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
13:09:39.038766 IP 10.94.171.10.41440 > 10.0.1.1.53: 24708+ A? ya.ru. (23)
13:09:39.040403 IP 10.0.1.1.53 > 10.94.171.10.41440: 24708 3/2/0 A 77.88.21.8,[|domain]
Расшифровываю вывод. С хоста 10.94.171.10 порт 41440 на 10.0.1.1 порт 53 пошел запрос А записи для адреса ya.ru. 53 порт это протокол DNS следующая строчка это ответ DNS сервера, по адресу 10.0.1.1
Не смотря на название, tcpdump знает множество сетевых протоколов. Ключ -i показывает какой интерфейс будем слушать, -n не запрашивать имена в DNS для IP адресов. Дальше в командной строке идет описание какие именно пакеты мы будем отлавливать. Здесь я не буду описывать команды фильтрации — их множество, остановлюсь только на возможностях. И так можно выбирать с какого и на какой хост идет пакет, с какого и на какой порт и даже диапазон портов. Можно группировать фильтры при помощи скобок и логических слов and, or, not. Выбирать протоколы icmp, arp, tcp, udp подробности в мане.
ngrep
#ngrep -W byline -d eth0 NOTIFY port 5060
interface: eth0 (213.108.32.94/255.255.255.255)
filter: (ip or ip6) and ( port 5060 )
match: NOTIFY
#
U 213.108.33.128:5060 -> 85.114.2.44:5060
NOTIFY sip:85.114.2.44 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK-2c32804.
From: 8126221842 ;tag=4751f3b994a4aca8o0.
To: .
Call-ID: a85b76bd-dc9f6574@192.168.1.2.
CSeq: 22858 NOTIFY.
Max-Forwards: 70.
Event: keep-alive.
User-Agent: Linksys/PAP2T-5.1.6(LS).
Content-Length: 0.
Ключ -W byline форматирует вывод по знакам переноса строки внутри пакета. Это очень удобно для почтовых протоколов или SIP, как в примере. Строка фильтра пакетов формируется так же, как и в tcpdump. Если не указывать какую подстроку ищем, то ngrep будет дампить все подходящие по условую пакеты. Если внутри пакета нет текстовой информации, тогда он обозначается решеткой (#)
И несколько простых утилиток, про которые нужно знать, что они существуют.
Как узнать, через какую запись в таблице маршрутизации пойдет трафик на IP адрес.
# ip route get 10.94.171.10
10.94.171.10 dev eth1.173 src 10.94.171.1
cache mtu 1500 advmss 1460 hoplimit 64
Как посмотреть кто или что забивает канал?
Для этого есть утилита iptraf c интерфейсом основанным на ncurses. При запуске без параметров выводит меню.
Для того, чтобы посмотреть суммарную статистику по интерфейсу
iptraf -d eth0
Для статистики по соединениям
iptraf -i eth0
Например у вас есть VPN туннель. Как проверить его ширину? Самый простой способ это утилита iperf. На одном хосте запускаем ее с ключем -s это будет сервер, который повиснет по умолчанию на порт 5001. С другой стороны запускаем с единственным параметром — адресом нашего сервера.
mii-tool
# mii-tool eth0
eth0: negotiated 100baseTx-FD flow-control, link ok
Утилитка из пакета net-tools. Показывает скорость физлинка. При ее помощи можно выловить проблему, когда две сетевые карточки не могут автоматически договориться о скорости и в результате будет что-то типа 10 мбит полудуплекс. Редкая проблема, но до сих пор встречается.
За рамками обзора остались nmap и hping. Жду в камментах ссылки на другие полезные программы. Может имеет смысл перенести в какой-нибудь подходящий блог?
Источник
Диагностика сетевого подключения (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 –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 8.8.8.8 –n и изучаем вывод программы:
Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.
Часто используемые опции:
- traceroute –n — вывод результата в числовом формате вместо символических имен промежуточных узлов;
- traceroute –I — использование ICMP-протокола при отслеживании маршрута. По умолчанию используются UDP-датаграммы;
- traceroute –s адрес— указать адрес источника для исходящего сетевого пакета;
- traceroute –i интерфейс— указать сетевой интерфейс, с которого будут отправляться пакеты.
Диагностика разрешения имен (nslookup, dig)
Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.
Самый простой способ проверить работает ли разрешение имен — запустить утилиту ping с указанием доменного имени вместо IP-адреса (например, ping ya.ru). Если ответные пакеты от удаленного сервера приходят, значит все работает как надо. В противном случае нужно проверить прописан ли DNS-сервер в сетевых настройках и удается ли получить от него ответ.
Способы выяснения какой 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
После успешной установки сделаем тестовые запросы:
В разделе 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-серверы принимают запросы).
Часто используемые параметры:
- nslookup имя сервер — разрешить доменное имя, используя альтернативый сервер;
- nslookup –type=тип имя — получить запись указанного типа для доменного имени (например, nslookup -type=mx ya.ru – получить MX-записи для домена ya.ru);
- dig @сервер имя — разрешить доменное имя, используя альтернативый сервер;
- dig имя тип — получить запись указанного типа для доменного имени (например, dig ya.ru mx — получить MX-записи для домена ya.ru).
Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.
Источник
