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

Существует несколько хороших инструментов, позволяющих искать неисправности в сети на уровне 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, дает представле­ ние об общей скорости передачи пакета по сети. Колебания этого значения, как прави­ ло, не являются признаком проблем. Иногда пакеты задерживаются на десятки и сотни

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

миллисекунд без видимой причины — просто так работают протокол IP и сама операци­ онная система Linux. Но все-таки следует ожидать, что полное время прохождения па­ кетов будет более-менее постоянным, за некоторыми исключениями. Большинство со­ временных маршрутизаторов ограничивает скорость выдачи ответов на ICMP-запросы, т.е. маршрутизатор может задержать ответ на пакет команды ping в связи с общим огра­ ничением трафика протокола ICMP.

Команда ping позволяет задать размер посылаемого эхо-пакета. Если передается па­ кет, размер которого превышает значение MTU для данной сети (в частности, 1500 байт в сети Ethernet), включается режим принудительной фрагментации. Это позволяет вы­ являть ошибки передачи данных в самом кабеле и другие низкоуровневые ошибки, на­ пример проблемы, связанные с перегрузкой сети или виртуальной частной сетью.

В системах семейства Linux желательный размер пакета в байтах задается с помощью флага -s.

# ping -s 1500 cuinfo.cornell.edu

В системах Solaris, HP-UX и AIX достаточно просто указать желательный размер па­

кета в конце команды ping.

# ping cuinfo.cornell.edu 1500

Помните, что даже простая команда вроде ping может повлечь драматические по­ следствия. В 1998 году так называемая атака Ping of Death (Смертельный Ping) вызва­ ла сбой большого количества UNIX- и Windows-систем. Эта атака началась с отправки чрезмерно большого ping-пакета. Когда фрагментированный пакет был собран заново, он заполнил весь буфер получателя и привел к сбою компьютера. Опасность повторения атаки Ping of Death давно устранена, но некоторые изъяны, связанные с использованием утилиты ping, все еще существуют.

Во-первых, сложно отличить неисправность сети от неисправности сервера, поль­ зуясь только этой командой. Потеря эхо-пакетов означает лишь, что что-то работает неправильно.

Во-вторых, успешно выполненная команда ping не позволяет получить информа­ цию о состоянии исследуемого компьютера. Эхо-запросы обрабатываются в стеке про­ токола IP и не требуют, чтобы на зондируемом компьютере выполнялся серверный про­ цесс. Получение ответа гарантирует только то, что компьютер включен и ядро системы функционирует. Для проверки работы отдельных служб, таких как HTTP и DNS, следует применять высокоуровневые средства.

Поиск по сайту: