15.3 Диагностика сетевых неполадок (Troubleshooting Network Problems)

Установка сетевого интерфейса — это только половина задачи. Чтобы обеспечить работу сети, необходимо использовать разнообразные инструменты проверки и мониторинга, чтобы убедиться в её корректной работе. Именно этому посвящена данная часть главы. Будут рассмотрены следующие темы:

• Применение стандартизированной методологии диагностики
• Использование ping
• Использование netstat
• Использование traceroute
• Использование nc
• Использование инструментов разрешения имён

Начнём с обсуждения стандартизированной методологии диагностики.

Стандартизированная методология диагностики (Using a Standardized Troubleshooting Model)

Умение диагностировать неполадки — неотъемлемое качество эффективного системного администратора Linux. Преподавая новичкам-администраторам на протяжении почти двух десятилетий, автор убедился, что это один из самых трудно даётся им навыков. Некоторые из них, по всей видимости, обладают врождённым чутьём в диагностике; другим оно не даётся. По мнению автора, причина в том, что диагностика — это отчасти искусство. Подобно тому как не всем дано рисовать, лепить или писать картины, так и не все умеют диагностировать неполадки.

Однако опыт показывает: при должном обучении и достаточной практике большинство начинающих администраторов в конечном счёте приобретают навыки эффективной диагностики. Есть три ключевых условия для этого:

• Применение чёткой методологии диагностики
• Владение инструментами диагностики
• Накопление практического опыта

Последний пункт выходит за рамки данной книги: опыт диагностики нарабатывается только в реальной работе на протяжении нескольких лет. Два первых пункта можно проработать здесь. В этой части главы речь пойдёт специально о диагностике сетевых проблем, однако описываемая методология применима и к любым системным неполадкам в целом.

Сетевые проблемы могут быть вызваны самыми разными причинами — рассмотреть их все в одной книге невозможно. Цель — сосредоточиться на стандартизированном процессе диагностики сетевых неполадок. Опираясь на такой процесс, можно адаптироваться к самым разным проблемам, противостоять им и решать их. Приведённая ниже модель не является исчерпывающей. Возможно, в конкретной ситуации потребуется добавить, удалить или переупорядочить шаги. Тем не менее она даёт хорошую отправную точку.

Многие начинающие системные администраторы допускают типичную ошибку при диагностике системных или сетевых проблем: вместо методичного подхода они бросаются реализовывать исправления, не разобравшись в причине проблемы. Назовём это «стрельбой из дробовика» (shotgun troubleshooting): администратор применяет одно исправление за другим в надежде, что одно из них сработает.

Это крайне опасная практика. Такой подход может порождать проблемы тяжелее исходных. В качестве примера: несколько лет назад при настройке серверов в сети один из серверов был настроен неправильно и испытывал затруднения при синхронизации с другими системами. Пока автор искал источник проблемы, коллега (назовём его Сид) начал применять одно исправление за другим по принципу «стрельбы из дробовика», пытаясь заставить сервер синхронизироваться с остальными. В итоге он катастрофически нарушил работу всех серверов! Исходная проблема была относительно незначительной и потребовала бы около 20 минут на устранение. Вместо этого пришлось провести остаток дня и часть ночи, переустанавливая каждый сервер с нуля и восстанавливая данные.

Вместо «стрельбы из дробовика» следует применять стандартизированную методологию диагностики, цель которой — чётко определить источник проблемы, прежде чем приступать к исправлениям. Звучит просто, однако многие администраторы с трудом следуют этому принципу. Ниже приведена предлагаемая методология, на основе которой можно выработать собственный подход:

Шаг 1. Сбор информации. Это критически важный шаг. Необходимо точно установить, что произошло. Каковы симптомы? Отображались ли сообщения об ошибках? Что в них было написано? Каков масштаб проблемы? Она затрагивает одну систему или несколько?

Шаг 2. Определение изменений. На этом шаге следует установить, что изменилось в системе. Было ли установлено новое программное обеспечение? Новое оборудование? Что-то изменил пользователь? Что-то изменили вы сами?

Шаг 3. Формулирование гипотез. На основе информации, собранной на предыдущих шагах, разработайте несколько гипотез, способных объяснить проблему. Для этого может потребоваться дополнительное исследование: изучение FAQ и баз знаний в Интернете, консультации с коллегами для проверки гипотез. Используя полученные сведения, сузьте список до одной-двух наиболее вероятных причин.

Шаг 4. Определение подходящего исправления. Следующий шаг — с помощью коллег, FAQ, баз знаний и собственного опыта определить порядок действий по устранению проблемы. При этом необходимо обязательно оценить возможные последствия применяемого исправления. Нередко исправление может иметь побочные эффекты, сопоставимые по тяжести с исходной проблемой или даже превышающие её.

Шаг 5. Применение исправления. На этом этапе можно приступать к реализации исправления. Обратите внимание: в данной методологии большой объём исследовательской работы проводится до применения исправления! Это существенно повышает вероятность успеха. После применения исправления обязательно проверьте, что проблема действительно устранена и не воспроизводится.

Шаг 6. Проверка удовлетворённости пользователей. Это типичная ошибка многих системных администраторов. Полезно помнить принцип: «Если пользователь недоволен — вы тоже недовольны». Системные администраторы нередко грешат неудовлетворительными коммуникациями. Если проблема затрагивает пользователей, необходимо сообщить им о её характере и о том, что она устранена. При необходимости следует также объяснить, как предотвратить её повторение в будущем. Необходимо также уведомить руководителей пользователей и убедиться, что они знают об устранении проблемы.

Шаг 7. Документирование решения. Наконец, необходимо задокументировать решение проблемы — чтобы при её повторном возникновении через год-два вы или другие системные администраторы смогли быстро определить проблему и способ её устранения.

Применяя эту методологию и накапливая практический опыт, можно стать очень эффективным специалистом по диагностике.

Помимо методологии, для экзамена Linux+/LPIC-1 необходимо знать ряд утилит для диагностики сети. Рассмотрим сначала утилиту ping.

Использование ping (Using ping)

Утилита ping — незаменимый инструмент в арсенале сетевого специалиста. Она постоянно используется для проверки связи между узлами через сеть. Ping работает, отправляя пакет ICMP-запроса эха (ICMP echo request) с исходной системы на конечную. Конечная система отвечает пакетом ICMP-ответа эха (ICMP echo response). Этот процесс показан на рис. 15-13.

Рис. 15-13. Использование ping

Если пакет ICMP-ответа получен исходной системой, можно утверждать следующее:

• Ваш сетевой интерфейс работает корректно.
• Конечная система включена и работает корректно.
• Сетевое оборудование между вашей системой и конечной системой работает корректно.

Примечание

Имейте в виду: многие персональные межсетевые экраны (host-based firewalls), используемые в различных операционных системах, по умолчанию настроены не отвечать на ICMP-запросы эха. Это делается для защиты от ряда атак типа «отказ в обслуживании» (DoS), использующих лавину ping-запросов. Такая конфигурация может создать ложное впечатление, что конечная система недоступна. На самом деле она прекрасно работает — просто межсетевой экран узла не пропускает ping-пакеты до операционной системы.

Это важно понимать! Базовый синтаксис команды ping: ping конечный_IP-адрес. Данная команда отправляет ICMP-запросы эха на указанный узел. Например, команда ping 192.168.2.1 выполнит проверку связи с узлом по этому адресу. Это показано на рис. 15-14.

Рис. 15-14. Проверка связи с узлом по IP-адресу

Обратите внимание на рис. 15-14: результаты каждого отправленного ping отображаются в отдельной строке. В каждой строке указываются размер пакета ответа (64 байта), адрес источника (192.168.2.1), значение TTL (63) и время прохождения туда и обратно (от 4,25 мс до 1,01 мс).

Примечание

Значение TTL (time-to-live, время жизни) определяет максимальное количество маршрутизаторов, через которые разрешено пройти пакету, прежде чем он будет отброшен.

По умолчанию утилита ping продолжает отправлять запросы на указанный узел, пока пользователь не прервёт её нажатием ctrl-c. Параметр -c позволяет задать количество отправляемых запросов. Например, ping -c 10 192.168.2.1 выполнит проверку десять раз, после чего завершит работу.

Можно также использовать имя узла вместо IP-адреса. Если в системе настроен корректный DNS-сервер, ping разрешит имя узла в IP-адрес и отправит запросы на него. Это показано на рис. 15-15.

Рис. 15-15. Проверка связи по имени узла

Проверка связи по имени узла — ценный диагностический инструмент. Он позволяет выявить проблемы с DNS-сервером. Например, если ping по IP-адресу работает, а по имени узла — нет, значит, базовая сетевая конфигурация и связность в порядке, но с DNS-сервером есть проблема.

Для проверки связи по протоколу IPv6 необходимо использовать команду ping6 вместо ping.

Помимо ping, необходимо знать команду netstat. Рассмотрим её.

Использование netstat (Using netstat)

Утилита netstat — ещё один мощный инструмент. Она позволяет:

• Выводить список сетевых подключений
• Отображать таблицу маршрутизации
• Отображать информацию о сетевом интерфейсе

Синтаксис: netstat параметр в командной строке. Доступные параметры приведены в таблице 15-5.

Таблица 15-5. Параметры netstat

Параметр	Описание
-a	Выводит список всех слушающих и не слушающих сокетов
-i	Отображает статистику по сетевым интерфейсам
-l	Выводит список слушающих сокетов
-s	Отображает сводную информацию по каждому протоколу
-r	Отображает таблицу маршрутизации

Помимо netstat, необходимо знать утилиту traceroute. Рассмотрим её.

Использование traceroute (Using traceroute)

Утилита traceroute — действительно полезный инструмент. Если попытаться отправить данные IP-узлу, не находящемуся в том же сегменте сети, пакеты будут переданы шлюзу по умолчанию (default gateway router). Этот маршрутизатор воспользуется различными протоколами маршрутизации, чтобы определить путь до конечной системы. В процессе пакеты могут передаваться от маршрутизатора к маршрутизатору. Это показано на рис. 15-16.

Рис. 15-16. Маршрутизация в IP-сети

В этом и состоит одно из достоинств IP-сетей: можно соединять несколько сетей с помощью маршрутизаторов и передавать данные между ними. Именно эта функциональность обеспечивает существование Интернета: можно отправить HTTP-запрос с веб-браузера на веб-сервер в любой точке мира и получить запрошенную страницу. Протоколы маршрутизации, применяемые маршрутизаторами, динамически определяют наилучший маршрут для пакетов на основе текущей загрузки. Маршрут может меняться по мере изменения состояния сети.

Утилита traceroute позволяет проследить маршрут, который пакет должен пройти через маршрутизаторы, чтобы достичь конечного узла. Для этого используются те же пакеты ICMP-запроса и ответа эха, что и в ping, но с манипуляцией параметром TTL. В результате каждый маршрутизатор, через который проходят пакеты, отправляет пакет ICMP-ответа эха обратно исходной системе, — что позволяет получить список, показывающий маршрут между исходным и конечным узлами.

Рис. 15-17. Использование traceroute

Эта утилита особенно полезна при проблемах со связью между сетями: traceroute помогает обнаружить неработающий маршрутизатор в маршруте. Синтаксис: traceroute имя_узла_или_IP-адрес. При запуске traceroute формирует одну строку для каждого маршрутизатора, через который проходят пакеты на пути к конечному узлу. Это показано на рис. 15-17.

Как видно на рис. 15-17, отображается IP-адрес каждого маршрутизатора вместе со статистикой времени прохождения туда и обратно. Как и ping, команда traceroute поддерживает протокол IPv6. Для этого вместо traceroute используется traceroute6.

Примечание

Для трассировки маршрута до удалённого узла можно также использовать команду tracepath. По синтаксису, функциональности и выводу она практически идентична traceroute. Аналогично traceroute, для работы с IPv6 используется tracepath6.

Использование nc (Using nc)

Команда netcat (nc) — очень полезный инструмент для проверки сетевых соединений между узлами. Она выходит за рамки команды ping и устанавливает реальное TCP- или UDP-соединение между двумя сетевыми узлами. Один из способов использования: открыть на одном узле слушающий TCP- или UDP-сокет, а затем подключиться к нему с другого узла. В следующем примере сначала открывается слушающий TCP-сокет на одном из проверяемых узлов:

openSUSE:/ # nc -l 2388

Параметр -l указывает netcat ожидать входящих подключений вместо попытки установить соединение с другим компьютером. Поскольку протокол не задан, по умолчанию используется TCP. Для работы с UDP необходимо добавить параметр -u. Также указан IP-порт для прослушивания (2388).

После открытия слушающего сокета на одной системе можно подключиться к нему с другой системы и установить TCP- (или UDP-) соединение снова с помощью nc. На этот раз вводим:

[root@fs5 ~]# nc 10.0.0.83 2388

Эта команда указывает nc IP-адрес узла для подключения и используемый IP-порт. После установки соединения можно вводить текст на второй системе и наблюдать его появление на экране первой системы:

[root@fs5 ~]# nc 10.0.0.83 2388
This is a test.
openSUSE:/ # nc -l 2388
This is a test.

Если этот тест проходит успешно, значит TCP- или UDP-соединение между этими двумя узлами может быть установлено.

Внимание

На межсетевых экранах обеих систем необходимо открыть соответствующие порты, иначе тест не сработает!

Рассмотрим теперь несколько инструментов для проверки разрешения имён в сети.

Инструменты разрешения имён (Using Name Resolution Tools)

DNS для разрешения имён работает отлично — пока не перестаёт работать. Тогда это превращается в серьёзное неудобство, поскольку конечные пользователи теряют возможность пользоваться сетевыми сервисами. К счастью, для диагностики разрешения имён в сети существует несколько инструментов:

• dig
• host
• getent

dig

Утилита dig (Domain Information Groper) позволяет выполнять DNS-запросы и отображать подробную информацию о разрешаемом имени узла и о самом DNS-сервере. Если DNS-сервер явно не указан, используются серверы, настроенные в файле resolv.conf. Синтаксис: dig @dns_сервер имя_узла. Пример показан на рис. 15-18.

Рис. 15-18. Использование dig для разрешения имени узла

Вывод dig значительно подробнее, чем у других инструментов диагностики DNS, таких как nslookup и host. Команда dig возвращает IP-адрес, соответствующий имени узла, в разделе ANSWER SECTION, а также перечисляет авторитетный сервер имён для имени узла и зоны в разделе AUTHORITY SECTION. Доступные параметры dig:

• a — разрешение записи типа A
• ptr — разрешение записи PTR
• cname — разрешение записи CNAME
• in — разрешение интернет-записи
• mx — разрешение записи MX
• soa — разрешение записи начала зоны (SOA)

host

Для разрешения имён узлов можно также использовать команду host. В отличие от dig, предоставляющей исчерпывающую информацию, host выдаёт краткие, быстро читаемые данные. Синтаксис аналогичен dig: host имя_узла DNS_сервер. Если DNS-сервер не указан, используется сервер по умолчанию из /etc/resolv.conf. Пример использования host:

openSUSE:/ # host www.google.com
www.google.com has address 74.125.239.49
www.google.com has address 74.125.239.48
www.google.com has address 74.125.239.50
www.google.com has address 74.125.239.52
www.google.com has address 74.125.239.51
www.google.com has IPv6 address 2607:f8b0:4005:800::1011

getent

Помимо host и dig, для проверки системы разрешения имён можно использовать getent. Слабость команд host и dig в том, что они не воспроизводят тот же процесс разрешения имён, что используют приложения и службы в вашей системе. Когда приложение, например веб-браузер, должно разрешить имя узла в IP-адрес, оно сначала обращается к файлу /etc/hosts. Если там нет записи для данного узла, используется настроенный DNS-сервер.

Команды dig и host так не поступают: они полностью пропускают файл hosts и обращаются напрямую к DNS-серверу. Это важно учитывать! Многие фишинговые и фарминговые атаки эксплуатируют файл hosts для перенаправления URL на вредоносные сайты, где собирается личная информация пользователей. Очевидно, что host и dig такую атаку не выявят, поскольку не проверяют файл hosts.

Хорошая новость: getent — выявляет. Синтаксис: getent hosts имя_узла. Пример:

openSUSE:/ # getent hosts router1
10.0.0.1        router1

В этом примере запись для имени узла router1 есть в файле hosts, поэтому getent нашёл и отобразил её. Если в файле hosts записи нет, getent попытается разрешить имя через DNS — точно так же, как делает обычное приложение:

openSUSE:/ # getent hosts www.nebo-tech.com
98.139.135.199 sbsfe-p11.geo.mf0.yahoodns.net www.nebo-tech.com

Совет

Команда getent может обращаться к любым данным, настроенным в файле /etc/nsswitch.conf. Например, команда getent passwd выведет записи из файла passwd.

Закрепим работу с сетевыми командами в следующем упражнении.

Упражнение 15-2: Работа с сетевыми командами (Exercise 15-2: Working with Network Commands)

Упражнение 15-2. Работа с сетевыми командами

В этом упражнении вы попрактикуетесь в использовании сетевых команд для управления сетевым интерфейсом и его диагностики. Предполагается наличие подключения к Интернету. Упражнение можно выполнить на виртуальной машине, прилагаемой к книге (запустите снимок состояния 15-1 для корректно настроенной среды).

Видео. Посмотрите видео «Упражнение 15-2» с демонстрацией выполнения этого задания.

Выполните следующие шаги:

1. Загрузите систему Linux и войдите под учётной записью студента.
2. Откройте сеанс терминала.
3. Переключитесь на учётную запись root, введя su – и пароль student.

4. Проверьте связь, введя ping www.google.com. Система должна разрешить имя узла в IP-адрес и отправить ICMP-запросы эха. (Если система не подключена к Интернету, этот шаг не сработает.)

   Примечание

   Если выполнить ping удалённого сайта не удаётся, проверьте с помощью ifconfig, был ли назначен IP-адрес. Если адрес не назначен, выполните systemctl restart network для перезагрузки конфигурации сети.

5. Отобразите сводную информацию о сетевом интерфейсе, введя netstat -s | more. Просмотрите выведенные данные.

6. Выполните трассировку маршрута до www.google.com, введя traceroute www.google.com. Обратите внимание на маршрутизаторы, которые пакеты проходят при движении через Интернет.
7. Получите расширенные сведения о разрешении имени www.google.com, введя dig www.google.com.