Munin is showing me a graph like this:
During that spike, I was unable to access my server through the eth0 port (I could access it through my IPMI port).
I’m trying to figure out what happened, but I can’t seem to locate any log files for eth0.
I don’t see anything in /var/log/(kern|syslog|messages) that is out of the ordinary. And I don’t see a log file specifically for eth0.
Are there logs for eth0, and if so, where can I find them?
I am running Ubuntu 10.04 LTS.
asked Jun 8, 2012 at 19:25
There are no logs for your interfaces. If you check soon enough, you can likely find them in the output of dmesg. You should find all that output in /var/log/messages. If it has rotated you need to look in /var/log/message.1.
Grep out the time range to a separate file that you can examine more easily. A command like
grep 'Jun 7 22:' /var/log/messages > ~/messages.tmp should work. Look for references to eth0 in the file. You may also see a reference to repeated messages which may be close to the line that indicates the problem. Also look for references to the driver for your interface, or the manufacturer.
Running the command ifconfig eth0 should output error counts, and may give you a hint as to the problem in the counts the follow the errors.
answered Jun 9, 2012 at 4:05
BillThorBillThor
27.8k3 gold badges37 silver badges69 bronze badges
2
You must log in to answer this question.
Not the answer you’re looking for? Browse other questions tagged
.
Not the answer you’re looking for? Browse other questions tagged
.
Время на прочтение
5 мин
Количество просмотров 46K
Часто мониторинг сетевой подсистемы операционной системы заканчивается на счетчиках пакетов, октетов и ошибок сетевых интерфейсах. Но это только 2й уровень модели OSI!
С одной стороны большинство проблем с сетью возникают как раз на физическом и канальном уровнях, но с другой стороны приложения, работающие с сетью оперируют на уровне TCP сессий и не видят, что происходит на более низких уровнях.
Я расскажу, как достаточно простые метрики TCP/IP стека могут помочь разобраться с различными проблемами в распределенных системах.
Netlink
Почти все знают утилиту netstat в linux, она может показать все текущие TCP соединения и дополнительную информацию по ним. Но при большом количестве соединений netstat может работать достаточно долго и существенно нагрузить систему.
Есть более дешевый способ получить информацию о соединениях — утилита ss из проекта iproute2.
Для сравнения:
$ time netstat -an|wc -l
62109
real 0m0.467s
user 0m0.288s
sys 0m0.184s$ time ss -ant|wc -l
62111
real 0m0.126s
user 0m0.112s
sys 0m0.016sУскорение достигается за счет использования протола netlink для запросов информации о соединениях у ядра. Наш агент использует netlink напрямую.
Считаем соединения
Disclaimer: для иллюстрации работы с метриками в разных срезах я буду показывать наш интерфейс (dsl) работы с метриками, но это можно сделать и на opensource хранилищах.
В первую очередь мы разделяем все соединения на входящие (inbound) и исходящие (outbound) по отношению к серверу.
Каждое TCP соединения в определенный момент времени находится в одном из состояний, разбивку по которым мы тоже сохраняем (это иногда может оказаться полезным):
По этому графику можно оценить общее количество входящих соединений, распределение соединений по состояниям.
Здесь так же видно резкое падение общего количества соединений незадолго до 11 Jun, попробуем посмотреть на соединения в разрезе listen портов:
На этом графике видно, что самое значительное падение было на порту 8014, посмотрим только 8014 (у нас в интерфейсе можно просто нажать на нужном элементе легенды):
Попробуем посмотреть, изменилось ли количество входящий соединений по всем серверам?
Выбираем серверы по маске “srv10*”:
Теперь мы видим, что количество соединений на порт 8014 не изменилось, попробуем найти на какой сервер они мигрировали:
Мы ограничили выборку только портом 8014 и сделали группировку не по порту, а по серверам.
Теперь понятно, что соединения с сервера srv101 перешли на srv102.
Разбивка по IP
Часто бывает необходимо посмотреть, сколько было соединений с различных IP адресов. Наш агент снимает количество TCP соединений не только с разбивкой по listen портам и состояниям, но и по удаленному IP, если данный IP находится в том же сегменте сети (для всех остальный адресов метрики суммируются и вместо IP мы показываем “~nonlocal”).
Рассмотрим тот же период времени, что и в предыдущих случаях:
Здесь видно, что соединений с 192.168.100.1 стало сильно меньше и в это же время появились соединения с 192.168.100.2.
Детализация рулит
На самом деле мы работали с одной метрикой, просто она была сильно детализирована, индентификатор каждого экземпляра выглядит примерно так:
{name="netstat.connections.inbound.count", state="<TCP_STATE>", listen_ip="<IP>" listen_port="<PORT>" remote_ip="<REMOTE_IP>"}Например, у одно из клиентов на нагруженном сервере-фронтенде снимается ~700 экземпляров этой метрики
TCP backlog
По метрикам TCP соединений можно не только диагностировать работу сети, но и определять проблемы в работе сервисов.
Например, если какой-то сервис, обслуживающий клиентов по сети, не справляется с нагрузкой и перестает обрабатывать новые соединения, они ставятся в очередь (backlog).
На самом деле очереди две:
- SYN queue — очередь неустановленных соединений (получен пакет SYN, SYN-ACK еще не отправлен), размер ограничен согласно sysctl net.ipv4.tcp_max_syn_backlog;
- Accept queue — очередь соединений, для которых получен пакет ACK (в рамках «тройного рукопожатия»), но не был выполнен accept приложением (очередь ограничивается приложением)
При достижении лимита accept queue ACK пакет удаленного хоста просто отбрасывается или отправляется RST (в зависимости от значения переменной sysctl net.ipv4.tcp_abort_on_overflow).
Наш агент снимает текущее и максимальное значение accept queue для всех listen сокетов на сервере.
Для этих метрик есть график и преднастроенный триггер, который уведомит, если backlog любого сервиса использован более чем на 90%:
Счетчики и ошибки протоколов
Однажды сайт одного из наших клиентов подвергся DDOS атаке, в мониторинге было видно только увеличение трафика на сетевом интерфейсе, но мы не показывали абсолютно никаких метрик по содержанию этого трафика.
В данный момент однозначного ответа на этот вопрос окметр дать по-прежнему не может, так как сниффинг мы только начали осваивать, но мы немного продвинулись в этом вопросе.
Попробуем что-то понять про эти выбросы входящего трафика:
Теперь мы видим, что это входящий UDP трафик, но здесь не видно первых из трех выбросов.
Дело в том, что счетчики пакетов по протоколам в linux увеличиваются только в случае успешной обработки пакета.
Попробуем посмотреть на ошибки:
А вот и наш первый пик — ошибки UDP:NoPorts (количество датаграмм, пришедших на UPD порты, которые никто не слушает)
Данный пример мы эмулировали с помощью iperf, и в первый заход не включили на сервер-приемщик пакетов на нужном порту.
TCP ретрансмиты
Отдельно мы показываем количество TCP ретрансмитов (повторных отправок TCP сегментов).
Само по себе наличие ретрансмитов не означает, что в вашей сети есть потери пакетов.
Повторная передача сегмента осуществляется, если передающий узел не получил от принимающего подтверждение (ACK) в течении определенного времени (RTO).
Данный таймаут расчитывается динамически на основе замеров времени передачи данных между конкретными хостами (RTT) для того, чтобы обеспечивать гарантированную передачу данных при сохранении минимальных задержек.
На практике количество ретрансмитов обычно коррелирует с нагрузкой на серверы и важно смотреть не на абсолютное значение, а на различные аномалии:
На данном графике мы видим 2 выброса ретрансмитов, в это же время процессы postgres утилизировали CPU данного сервера:
Cчетчики протоколов мы получаем из /proc/net/snmp.
Conntrack
Еще одна распространенная проблема — переполнение таблицы ip_conntrack в linux (используется iptables), в этом случае linux начинает просто отбрасывать пакеты.
Это видно по сообщению в dmesg:
ip_conntrack: table full, dropping packetАгент автоматически снимает текущий размер данной таблицы и лимит с серверов, использующих ip_conntrack.
В окметре так же есть автоматический триггер, который уведомит, если таблица ip_conntrack заполнена более чем на 90%:
На данном графике видно, что таблица переполнялась, лимит подняли и больше он не достигался.
Вместо заключения
- детализация метрик очень важна
- если где-то что-то может переполниться, нужно обязательно покрывать мониторингом такие места
- мы снимаем еще много разного по TCP/IP (RTT, соединения с непустыми send/recv очередями), но пока не придумали, как c этим правильно работать
Примеры наших стандартных графиков можно посмотреть в нашем демо-проекте.
Там же можно постмотреть графики Netstat.
Как отобразить отброшенные пакеты для каждого интерфейса в операционных системах Linux из командной строки?
Как определить, почему сервер Linux отбрасывает пакеты?
Мы можем использовать команду ip, команду netstat или команду ethtool для отображения статистики отброшенных пакетов для каждого сетевого интерфейса на Linux.
Давайте посмотрим, как использовать обе команды для вывода списка отброшенных пакетов для каждого интерфейса.
Содержание
- Отображение отброшенных пакетов для каждого интерфейса в Linux с помощью netstat
- Чтобы отобразить сводную статистику для каждого протокола, запустите:
- Покажем статистику tcp
- Покажем статистику udp
- Отображение статистики cброшенных пакетов по сетевому интерфейсу в Linux с использованием IP
- Запроcим у указанного сетевого устройства статистику по сетевому адаптеру и драйверу с помощью ethtool
- Как выяснить, почему сервер Linux отбрасывает пакеты
- Сборка dropwatch
- Заключение
Отображение отброшенных пакетов для каждого интерфейса в Linux с помощью netstat
Команда netstat уже устарела.
Заменами команды netstat являются команды ss и ip.
Однако netstat все еще доступен в старых дистрибутивах Linux.
Поэтому я начну с netstat, но, если возможно, воспользуюсь инструментами ip / ss.
Синтаксис:
netstat -i
netstat --interfaces
Чтобы отобразить сводную статистику для каждого протокола, запустите:
netstat -s
netstat --statistics
Выводы:
Ip:
Forwarding: 1
101759568 total packets received
70289211 forwarded
0 incoming packets discarded
31287093 incoming packets delivered
136164545 requests sent out
22 outgoing packets dropped
220 reassemblies required
110 packets reassembled ok
2364 fragments received ok
3345 fragments failed
4728 fragments created
Icmp:
295517 ICMP messages received
6 input ICMP message failed
ICMP input histogram:
destination unreachable: 145
timeout in transit: 187
echo requests: 289750
echo replies: 5435
298725 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 3408
echo requests: 5567
echo replies: 289750
IcmpMsg:
InType0: 5435
InType3: 145
InType8: 289750
InType11: 187
OutType0: 289750
OutType3: 3408
OutType8: 5567
Tcp:
19006 active connection openings
14619 passive connection openings
2268 failed connection attempts
393 connection resets received
1 connections established
2215735 segments received
2511500 segments sent out
6067 segments retransmitted
182 bad segments received
13173 resets sent
Udp:
28543977 packets received
63 packets to unknown port received
287687 packet receive errors
22106848 packets sent
287687 receive buffer errors
0 send buffer errors
UdpLite:
TcpExt:
10 invalid SYN cookies received
2264 resets received for embryonic SYN_RECV sockets
42 packets pruned from receive queue because of socket buffer overrun
14095 TCP sockets finished time wait in fast timer
21 packetes rejected in established connections because of timestamp
16908 delayed acks sent
13 delayed acks further delayed because of locked socket
Quick ack mode was activated 4346 times
756194 packet headers predicted
441344 acknowledgments not containing data payload received
618096 predicted acknowledgments
TCPSackRecovery: 87
Detected reordering 418 times using SACK
TCPDSACKUndo: 1
14 congestion windows recovered without slow start after partial ack
TCPLostRetransmit: 3994
TCPSackFailures: 1
121 fast retransmits
8 retransmits in slow start
TCPTimeouts: 5158
TCPLossProbes: 789
TCPLossProbeRecovery: 66
TCPSackRecoveryFail: 3
TCPBacklogCoalesce: 8617
TCPDSACKOldSent: 4359
TCPDSACKOfoSent: 1
TCPDSACKRecv: 127
3870 connections reset due to unexpected data
244 connections reset due to early user close
487 connections aborted due to timeout
TCPDSACKIgnoredNoUndo: 33
TCPSackShifted: 37
TCPSackMerged: 115
TCPSackShiftFallback: 731
TCPRcvCoalesce: 225465
TCPOFOQueue: 29252
TCPOFOMerge: 1
TCPChallengeACK: 193
TCPSYNChallenge: 186
TCPAutoCorking: 26574
TCPFromZeroWindowAdv: 8
TCPToZeroWindowAdv: 8
TCPWantZeroWindowAdv: 37
TCPSynRetrans: 647
TCPOrigDataSent: 1526711
TCPACKSkippedSynRecv: 153
TCPKeepAlive: 53
TCPDelivered: 1539034
TCPAckCompressed: 2559
IpExt:
InNoRoutes: 16
InBcastPkts: 4
InOctets: 92596603587
OutOctets: 263001759492
InBcastOctets: 310
InNoECTPkts: 121775194
InECT1Pkts: 1
InECT0Pkts: 51506
InCEPkts: 25
Покажем статистику tcp
netstat --statistics --tcp
netstat -s -t
Покажем статистику udp
netstat --statistics --udp
netstat -s -u
Отображение статистики cброшенных пакетов по сетевому интерфейсу в Linux с использованием IP
Давайте посмотрим, как просмотреть статистику сетевого устройства с помощью команды ip. Синтаксис:
ip -s link
ip -s link show {interface}
ip -s link show eth0
В этом примере отображается статистика интерфейса wg0:
ip -s link show wg0
4: wg0: <pointopoint,noarp,up,lower_up> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
RX: bytes packets errors dropped overrun mcast
1889086196 11451163 8413 62869 0 0
TX: bytes packets errors dropped carrier collsns
56342032204 41609374 0 5685 0 0
</pointopoint,noarp,up,lower_up>
Понятно, что TX – это передача, а RX – прием.
Интерфейс wg0 создает Wireguard
Так что либо Wireguard, либо брандмауэр отбрасывают пакеты в соответствии с политикой.
Запроcим у указанного сетевого устройства статистику по сетевому адаптеру и драйверу с помощью ethtool
Передайте параметр -S или –statistics для отображения статистики.
Опять же, синтаксис прост:
ethtool -S {device}
ethtool -S eth0
NIC statistics:
rx_queue_0_packets: 94804582
rx_queue_0_bytes: 92123064799
rx_queue_0_drops: 0
rx_queue_0_xdp_packets: 0
rx_queue_0_xdp_tx: 0
rx_queue_0_xdp_redirects: 0
rx_queue_0_xdp_drops: 0
rx_queue_0_kicks: 1499
tx_queue_0_packets: 94616365
tx_queue_0_bytes: 93565559918
tx_queue_0_xdp_tx: 0
tx_queue_0_xdp_tx_drops: 0
tx_queue_0_kicks: 40246533
Другой вариант – напрямую запросить файл /proc/net/dev с помощью команды cat или команды column:
cat /proc/net/dev
column -t /proc/net/dev
И вот что мы увидим:
Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed eth0: 92123116754 94805122 0 0 0 0 0 0 93565689124 94617058 0 0 0 0 0 0 wg0: 1889086196 11451163 8413 62869 0 8413 0 0 56342032204 41609374 0 5685 0 0 0 0 lo: 52141452 150908 0 0 0 0 0 0 52141452 150908 0 0 0 0 0 0 tun0: 1650631998 16914416 0 0 0 0 0 0 30143956312 22000354 0 660246 0 0 0 0
Как выяснить, почему сервер Linux отбрасывает пакеты
Мы можем использовать dropwatch:
Это проект, помогает разработчикам и системным администраторам диагностировать проблемы в сетевом стеке Linux, в частности, способность диагностировать, где падают пакеты.
Сборка dropwatch
Установите необходимые инструменты, библиотеки и сборник компиляторов gcc в Ubuntu или Debian Linux:
sudo apt-get install libpcap-dev libnl-3-dev libnl-genl-3-dev
binutils-dev libreadline6-dev autoconf libtool pkg-config
build-essential
Затем клонируйте репо, а затем скомпилируйте его:
git clone https://github.com/nhorman/dropwatch
cd dropwatch
./autogen.sh
./configure
make
make install
Вывод:
Making install in src make[1]: Entering directory '/tmp/dropwatch/src' make[2]: Entering directory '/tmp/dropwatch/src' /usr/bin/mkdir -p '/usr/local/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c dropwatch dwdump '/usr/local/bin' libtool: install: /usr/bin/install -c dropwatch /usr/local/bin/dropwatch libtool: install: /usr/bin/install -c dwdump /usr/local/bin/dwdump make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/tmp/dropwatch/src' make[1]: Leaving directory '/tmp/dropwatch/src' Making install in doc make[1]: Entering directory '/tmp/dropwatch/doc' make[2]: Entering directory '/tmp/dropwatch/doc' make[2]: Nothing to be done for 'install-exec-am'. /usr/bin/mkdir -p '/usr/local/share/man/man1' /usr/bin/install -c -m 644 dropwatch.1 '/usr/local/share/man/man1' make[2]: Leaving directory '/tmp/dropwatch/doc' make[1]: Leaving directory '/tmp/dropwatch/doc' Making install in tests make[1]: Entering directory '/tmp/dropwatch/tests' make[2]: Entering directory '/tmp/dropwatch/tests' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/tmp/dropwatch/tests' make[1]: Leaving directory '/tmp/dropwatch/tests' make[1]: Entering directory '/tmp/dropwatch' make[2]: Entering directory '/tmp/dropwatch' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/tmp/dropwatch' make[1]: Leaving directory '/tmp/dropwatch'
Запустите его следующим образом:
# dropwatch -l kas
См. Справочную страницу и исходный код dropwatch для получения дополнительной информации:
man dropwatch
Я также предлагаю попробовать tcpdump для просмотра сброшенного трафика на сетевом интерфейсе.
Часто он дает подсказки о пакетах и легко анализируется в программе wirehark:
man tcpdump
Заключение
Вы узнали о различных командах Linux, позволяющих увидеть потерю пакетов на каждом интерфейсе Linux, включая такие отличные инструменты, как dropwatch.
Содержание
- Как проверить сетевые ошибки в Linux?
- Как найти сетевой интерфейс в Linux?
- Как исправить недоступность сети в Linux?
- Может проверить связь с сервером, но не может подключиться к нему?
- Как исправить сетевые ошибки?
- Как решить проблему с сетью?
- Как исправить проблемы с сетевым подключением?
- Как мне увидеть все интерфейсы в Linux?
- Как мне найти свой сетевой интерфейс?
- Как проверить состояние Ethernet?
- Как мне узнать номер моего порта Ethernet?
- Как вы узнаете ОС в вашей системе в Unix?
Как устранить неполадки сетевого подключения с сервером Linux
- Проверьте конфигурацию сети. …
- Проверьте файл конфигурации сети. …
- Проверить записи DNS серверов. …
- Проверьте соединение в обоих направлениях. …
- Выясните, где происходит сбой соединения. …
- Настройки межсетевого экрана. …
- Информация о статусе хоста.
Как найти сетевой интерфейс в Linux?
Определение сетевых интерфейсов в Linux
- IPv4. Вы можете получить список сетевых интерфейсов и IPv4-адресов на вашем сервере, выполнив следующую команду: / sbin / ip -4 -o a | cut -d ‘‘ -f 2,7 | cut -d ‘/’ -f 1.…
- IPv6. …
- Полная мощность.
Как исправить недоступность сети в Linux?
4 ответа
- Взять терминал.
- sudo su.
- Введите. $ Route add gw по умолчанию (например: 192.168.136.1) eth0.
- иногда вы сможете выполнить ping (ping 8.8.8.8), но тогда в браузере нет подключения к Интернету.
- перейдите в «nano /etc/resolv.conf»
- Доп.
- сервер имен 8.8.8.8.
- сервер имен 192.168.136.0 (шлюз) или сервер имен 127.0.1.1.
Может проверить связь с сервером, но не может подключиться к нему?
Эта проблема обычно возникает из-за проблемы с разрешением сервера доменных имен (DNS) из-за недоступности DNS-серверов интернет-провайдера или из-за проблемы с программным обеспечением безопасности (обычно брандмауэром), запущенным на компьютере, который пытается для доступа в Интернет.
Как исправить сетевые ошибки?
Перезагрузите устройство.
- Перезагрузите устройство. Это может показаться простым, но иногда это все, что нужно, чтобы исправить плохое соединение.
- Если перезапуск не работает, переключитесь между Wi-Fi и мобильной передачей данных: откройте приложение «Настройки» Wireless & amp; сети »или« Подключения ». …
- Попробуйте выполнить следующие действия по устранению неполадок.
Как решить проблему с сетью?
Следуйте этим советам по устранению неполадок в сети, и вы сразу же приступите к работе.
- Проверьте настройки. Сначала проверьте настройки Wi-Fi. …
- Проверьте свои точки доступа. …
- Объезжайте препятствия. …
- Перезагрузите маршрутизатор. …
- Проверьте имя и пароль Wi-Fi. …
- Проверьте настройки DHCP. …
- Обновите Windows. …
- Откройте средство диагностики сети Windows.
Как исправить проблемы с сетевым подключением?
как решить проблему с сетевым подключением?
- Убедитесь, что Wi-Fi включен, а режим полета выключен.
- Проверьте, не связана ли проблема с веб-сайтом.
- Убедитесь, что проблема в вашем устройстве.
- Перезагрузите устройство.
- Проверить действительный IP-адрес.
- Попробуйте пинговать и проследить маршрут.
- Сообщите в службу поддержки ИТ или интернет-провайдера.
Как мне увидеть все интерфейсы в Linux?
Linux Показать / отобразить доступные сетевые интерфейсы
- Команда ip — используется для отображения или управления маршрутизацией, устройствами, политикой маршрутизации и туннелями.
- команда netstat — используется для отображения сетевых подключений, таблиц маршрутизации, статистики интерфейсов, маскарадных подключений и многоадресного членства.
Как мне найти свой сетевой интерфейс?
Чтобы проверить оборудование сетевой карты, выполните следующие действия:
- Откройте панель управления.
- Откройте диспетчер устройств. …
- Разверните элемент «Сетевые адаптеры», чтобы просмотреть все сетевые адаптеры, установленные на вашем ПК. …
- Дважды щелкните запись «Сетевой адаптер», чтобы открыть диалоговое окно «Свойства» сетевого адаптера вашего ПК.
Как проверить состояние Ethernet?
Щелкните кнопку «Пуск», затем щелкните «Панель управления» и введите «состояние сети» в поле поиска в правом верхнем углу окна. Щелкните «Сеть и общий доступ», чтобы просмотреть текущее состояние вашей сети.
Как мне узнать номер моего порта Ethernet?
Как найти номер вашего порта в Windows
- Введите «Cmd» в поле поиска.
- Откройте командную строку.
- Введите команду «netstat -a», чтобы увидеть номера ваших портов.
Как вы узнаете, какая ОС в вашей системе находится в Unix?
Процедура поиска имени и версии ОС в Linux:
- Откройте приложение терминала (оболочка bash)
- Для входа на удаленный сервер используя ssh: ssh user @ server-name.
- Введите любую из следующих команд, чтобы найти имя и версию ОС в Linux: cat / etc / os-release. …
- Введите следующую команду, чтобы узнать версию ядра Linux: uname -r.
Похожие сообщения:
- Как изменить шрифт на Android?
- Быстрый ответ: как увеличить размер шрифта в Windows 10?
- Быстрый ответ: как изменить размер шрифта в Windows 10?
- Как изменить шрифт в Windows 10?
- Как изменить шрифты в Windows 10?
- Как установить шрифты в Linux?
.
Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.
Для операционных систем семейства 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/имя опции:
В данном случае видим, что на оба сетевых пакета, отправленных на адрес нашего шлюза по умолчанию, получены ответы, потерь нет. Это значит, что на уровне локальной сети со связностью все в порядке. Помимо количества полученных/потерянных сетевых пакетов мы можем увидеть время, которое было затрачено на прохождение запроса и ответа – параметр 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
для Debian/Ubuntu:
sudo apt install dnsutils
После успешной установки сделаем тестовые запросы:
dig ya.ru
В разделе Answer Section видим ответ от DNS сервера — IP-адрес для A-записи с доменным именем ya.ru. Разрешение имени работает корректно:
nslookup ya.ru
Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.
Что же делать, если в ответе отсутствует IP-адрес? Возможно, DNS-сервер недоступен. Для проверки можно отправить тестовый запрос на другой DNS-сервер. Обе утилиты позволяют эти сделать. Направим тестовый запрос на DNS-сервер Google:
dig @8.8.8.8 ya.ru
nslookup ya.ru 8.8.8.8
Если имена разрешаются публичным 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.
191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А
+7 (812) 403-06-99
700
300
ООО «ИТГЛОБАЛКОМ ЛАБС»
191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А
+7 (812) 403-06-99
700
300
ООО «ИТГЛОБАЛКОМ ЛАБС»