35. Поиск неисправностей в сетях

Существует несколько хороших инструментов, позволяющих искать неисправности в сети на уровне TCP/IP. Большинство из них выдает низкоуровневую информацию, поэтому для того, чтобы пользоваться ими, нужно хорошо понимать принципы работы протоколов TCP/IP и маршрутизации.

С другой стороны, источником проблем в сети могут служить и ошибки в работе та­ ких высокоуровневых протоколов, как DNS, NFS или HTTP. Прежде чем приступать к чтению этой главы, прочтите главы 14 и 15.

В этом разделе мы рассмотрим общую стратегию поиска неисправностей, после чего перейдем к знакомству с основными инструментами этого поиска: утилитами ping, traceroute, netstat, tcpdump и Wireshark. Команда arp, которая также предназначе­ на для поиска неисправностей в сети, здесь не описывается; о ней рассказывалось раз­ деле 14.6.

Когда в сети возникает неисправность, появляется желание побыстрее все устранить. Не торопитесь! Важно обдумать подход к решению проблемы, избегая необдуманных действий. Наибольшая ошибка заключается во внесении плохо спланированных изме­ нений в неисправную сеть.

Прежде чем “набрасываться” на собственную сеть, примите во внимание следующие принципы.

•

• •

•

•

• •

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

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

ной информации с помощью утилит, таких как sar и nmon.

Начните с “края” системы или сети и продвигайтесь по ключевым ее компонен­ там, пока не доберетесь до источника неисправности. Например, начните с ис­ следования сетевой конфигурации клиентского компьютера, затем проверьте фи­ зическое соединение клиента с сетью, сетевое оборудование и, наконец, сетевые аппаратные средства сервера и его программную конфигурацию.

Будьте в курсе событий. Сетевые проблемы оказывают влияние на многих людей: пользователей, провайдеров, системных администраторов, инженеров по телеком­ муникациям, сетевых администраторов и т.д. Постоянный контакт с другими спе­ циалистами позволит вам не мешать друг другу при решении проблемы.

Работайте в команде. Многолетний опыт показывает, что люди совершают меньше глупых ошибок, если им оказывают поддержку.

Помните о многоуровневой структуре сетевых средств. Начните с верхнего или нижнего уровня и последовательно продвигайтесь по стеку протоколов, проверяя их работу.

Последнее замечание заслуживает более подробного рассмотрения. Как указывалось в разделе 14.2, в семействе протоколов TCP/IP определяются уровни абстракции, на ко-

Глава 21. Управление сетями 909

торых функционируют различные компоненты сети. Например, протокол HTTP зависит от протокола TCP, который, в свою очередь, основан на протоколе IP, а последний взаи­ модействует с протоколом Ethernet, работоспособность которого зависит от целостно­ сти сетевого кабеля. Можно существенно уменьшить время поиска неисправности, если предварительно понять, средства какого уровня ведут себя неправильно.

Проходя стек протоколов уровень за уровнем (вверх или вниз), проверяйте следующее.

• Есть ли физическое соединение и светится ли индикатор связи?

• Правильно ли сконфигурирован сетевой интерфейс?

• Отображаются ли в таблицах маршрутизации адреса других компьютеров?

• Есть ли брандмауэр на вашем локальном компьютере?

• Если брандмауэр есть, проходят ли через него ICMP-пакеты утилиты ping и от­ веты?

• Находит ли команда ping узел localhost (127.0.0.1)?

• Находит ли команда ping другие компьютеры локальной сети по IР-адресам?

• Правильно ли сконфигурирована служба DNS?1

• Находит ли команда ping другие компьютеры локальной сети по именам?

• Находит ли команда ping компьютеры в другой сети?

• Работают ли высокоуровневые сетевые утилиты, такие как telnet или ssh?

• Вы правда проверили брандмауэры?

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

21.2. Команда ping: проверка доступности компьютера

Команда ping удивительно проста, но во многих случаях ее оказывается вполне до­ статочно. Она посылает ICMP-пакет ECHO_REQUEST конкретному компьютеру и ждет ответа.

Команду ping можно применять для проверки работоспособности отдельных ком­ пьютеров и сегментов сети. В обработке ее запроса участвуют таблицы маршрутизации, физические компоненты сетей и сетевые шлюзы, поэтому для достижения успешного результата сеть должна быть в более или менее рабочем состоянии. Если команда не ра­ ботает, можно быть совершенно уверенным в том, что более сложные средства тем более не функционируют. Однако это правило неприменимо в сетях, где брандмауэры блоки­ руют эхо-запросы ICMP. Убедитесь в том, что брандмауэр не препятствует работе коман-

1 Если компьютер загружается очень медленно, зависает при загрузке или при попытке уста­ новить связь посредством утилиты telnet, вероятнее всего, служба DNS функционирует неверно. В системах Solaris и Linux используется очень сложный подход к разрешению имен, конфигурация которого задана в файле /etc/nsswitch.conf. В других системах особый интерес представляет Демон кеширования службы имен (nscd). Если он дает сбой или имеет неправильную конфигу­ рацию, это сказывается на поиске имен. По мере развития протокола IPv6 выяснилось, что мно­ гие маршрутизаторы DSL выполняют функции службы по перенаправлению DNS, которые про­ сто игнорируют запросы на записи DNS для IPv6 (АААА). Эта “оптимизация” вызывает длинные простои при выполнении запросов на распознавание имен. Для проверки правильности работы вашего распознавателя и сервера имен используйте команду getend (например, getend hosts google.com).

910 Часть II. Работа в сети

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

Если сеть находится в плохом состоянии, вероятно, система DNS работает непра­ вильно. Упростите ситуацию, используя числовые IP-адреса при выполнении утилиты ping, и примените параметр -n, чтобы предотвратить обратный поиск IP-адресов, по­ скольку при этом также генерируются DNS-запросы.

Если утилита ping используется для проверки выхода в Интернет, необходимо про­ верить брандмауэр. Некоторые хорошо известные сайты отвечают на пакеты ping, а другие — нет. Например, оказалось, что сайт google.com отвечает на такие запросы.

Большинство версий команды работает в бесконечном цикле, если не задан аргумент “число пакетов”. В системе Solaris команда ping -s обеспечивает расширенный вывод, а в других системах это происходит по умолчанию. Для того чтобы прервать работу ко­ манды, нажмите <Ctrl+C>.

Приведем пример.

linux$ ping beast

PING beast (10.1.1.46) : 56 data bytes

64 bytes from beast(10.1.1.46): icmp_seq=0 ttl=54 time=48.3ms

64 bytes from beast(10.1.1.46): icmp_seq=l ttl=54 time=46.4ms

64 bytes from beast(10.1.1.46): icmp_seq=2 ttl=54 time=88.7ms

^C

--- beast ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss, time 2026ms rtt min/avg/max/stddev = 46.490/61.202/88.731/19.481 ms

Информация о компьютере beast включает его IP-адрес, порядковый номер ответ­ ного ICMP-пакета и полное время прохождения пакета. Полученные результаты свиде­ тельствуют о том, что компьютер beast работает и подключен к сети.

Порядковый номер ICMP-пакета — особенно ценный элемент информации. Нарушение последовательности свидетельствует об удалении пакетов. Обычно они со­ провождаются сообщениями о каждом пропущенном пакете.

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

В случае исчезновения пакетов сначала выполните команду traceroute (описана ниже) для выяснения маршрута, по которому пакеты следуют к компьютеру-адресату. Затем посредством команды ping проверьте все промежуточные шлюзы, через которые пролегает маршрут, и узнайте, на каком этапе теряются пакеты. Для того чтобы точно диагностировать проблему, следует отправить такое количество пакетов, которое по­ зволит получить статистически достоверные результаты. Неисправность сети находится на участке между последним шлюзом, для которого количество потерянных пакетов не больше некоторой заданной величины, и шлюзом, при обращении к которому количе­ ство потерянных пакетов превышает эту величину.

Полное время прохождения пакетов, сообщаемое командой ping, дает представле­ ние об общей скорости передачи пакета по сети. Колебания этого значения, как прави­ ло, не являются признаком проблем. Иногда пакеты задерживаются на десятки и сотни