Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

532

Глава 13. Разрешение проблем TCP/IP

Заголовок (Header)

Содержит административную информацию о сообщении, включая сведе-

ния о том, что содержится в последующих разделах сообщения.

Вопрос (Question)

Определяет суть вопроса, поставленного в запросе. Если раздел вопроса

содержится в ответном сообщении, он позволяет определить, на какой во-

прос отвечает ответное сообщение.

Ответ (Answer)

Часть ответного сообщения, содержащая ответ на конкретный вопрос,

полученный в запросе.

Компетенция (Authority)

Содержит указатели на компетентные серверы домена, фигурирующего в

запросе.

Дополнительный раздел (Additional)

Содержит прочие записи ресурсов с дополнительной важной информа-

цией, сопутствующей ответу. Это не ответ на запрос, но эта информация

способствует интерпретации или использованию ответа.

Основа вывода команды dig представлена в различных разделах ответного

пакета DNS. Сведения заголовка в вышеприведенном примере представле-

ны следующим образом:

;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 4

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

dig отображает данные заголовка не в том порядке, в каком они хранятся в

заголовке, но вывод команды достаточно легко связать с полями заголовка,

описанными в RFC 1035. Ниже описаны различные значения из примера:

opcode: QUERY

Указывает, что данный запрос является стандартным.

status: NOERROR

Указывает, что в поле RCODE отсутствует код ошибки, то есть поле RCODE

содержит значение 0.

id: 6

Указывает, что для данного сообщения в качестве идентификатора ис-

пользовалось число 6.

flags: qr aa rd га

flags объединяет все однобитовые поля заголовка. В данном случае это

значение покрывает четыре различных поля раздела заголовка и предо-

ставляет сведения о трех других полях. Данная группа флагов указывает,

что QR имеет значение 1, то есть мы имеем дело с ответным сообщением.

АА имеет значение 1, поскольку ответ поступил от компетентного серве-

ра. RD имеет значение 1, поскольку в запросе присутствовал флаг рекур-

сии. RA имеет значение 1 - рекурсия была доступна на сервере. ТС отсут-

ствует, а значит, имеет значение 0, и это означает, что ответ не был усе-

чен. AD и CD также имеют значение 0, поскольку механизмы DNSSEC не

задействованы.

Эти значения представляют поля заголовка QDCOUNT, ANCOUNT,

NSCOUNT и ARCOUNT, определяющие число записей ресурсов в остав-

шихся разделах сообщения. Можно видеть, что в разделе вопроса одна за-

пись, в разделе ответа одна запись, в разделе компетенции три записи и в

дополнительном разделе три записи.

Команда dig из примера отображает следующие сведения о запросе:

Четко прослеживаются три поля данного запроса. Поле класса имеет значе-

ние IN, поскольку запрос касается записей Internet. Смысл запроса: поиск

любой записи (type = any), связанной с именем 3.0.72.18.in-addr.arpa. Отме-

тим, что программа dig выполнила обращение адреса и создала для данного

запроса соответствующее обратное доменное имя.

Далее dig выводит раздел ответа, компетенции и дополнительный:

Ответ такой, как можно было ожидать: запись PTR для имени 3.0.72.18.in-

addr.arpa. Эта запись сообщает нам, что имя узла для адреса 18.72.0.3-

bitsy.mit.edu.

В разделе компетенции перечислены серверы, выступающие в роли компе-

тентных для домена 18.in-addr.arpa. В этом разделе три записи NS, и каждая

содержит имя компетентного сервера. Таким образом, мы знаем, что серве-

ры w20ns.mit.edu, bitsy.mit.edu и strawb.mit.edu являются компетентными

для обратного домена 18.in-addr.arpa.

Дополнительный раздел завершает сообщение и содержит адреса всех ком-

петентных серверов имен. Адреса важны, поскольку если локальному серве-

ру понадобится отправить один из последующих запросов напрямую компе-

тентному серверу имен, он должен знать адреса таких серверов. Адреса в

данном случае: 18.70.0.160, 18.72.0.3, 18.71.0.151.

534 Глава 13. Разрешение проблем TCP/IP

Помимо ответа DNS, dig предоставляет сведения о состоянии в трех первых

и четырех последних строках вывода. Первая строка повторяет параметры

командной строки dig (-х в данном примере). Вторая строка содержит пара-

метры библиотеки DNS-клиента, а третья указывает, был ли найден ответ на

запрос. Последние четыре строки отображают время поиска, имя и адрес

сервера, ответившего на запрос, дату получения запроса, а также размер па-

кетов запроса и ответа. Все эти сведения могут быть полезны при отладке

проблем с DNS.

Программа dig удобна, поскольку формат сообщения DNS четко прослежи-

вается в ее выводе, dig включается в состав Linux, однако присутствует не во

всех системах Unix. Не беспокойтесь, если в вашей системе отсутствует dig.

Для атаки на те же проблемы можно смело использовать

nslookup.

nslookup и

dig одинаково эффективны для тестирования DNS.

Анализ проблем протоколов

Причинами проблем существенно чаще становятся неверные настройки

TCP/IP, чем некорректные реализации протоколов TCP/IP. Большинство

проблем, с которыми вы столкнетесь, вполне поддаются анализу посредст-

вом уже описанных ранее простых инструментов. Но временами может воз-

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

В худшем случае может дойти и до побитового анализа пакетов в потоке дан-

ных. Задачу облегчают анализаторы протоколов.

Мы воспользуемся инструментом под названием

snoop,

snoop поставляется в

составе операционной системы Solaris.

Во всех примерах фигурирует snoop,

однако концепции этого раздела применимы и к прочим анализаторам, по-

скольку большинство анализаторов протоколов функционирует по сути дела

одинаково. Анализаторы протоколов позволяют выбрать, или отфильтро-

вать, пакеты для анализа и изучать такие пакеты побайтово. Мы обсудим

обе функции.

Анализаторы протоколов просматривают все пакеты сети. Следовательно,

нужна только одна-система с анализатором в том сегменте сети, для которого

выполняется отладка. Одна система Solaris при помощи snoop может наблю-

дать за сетевым трафиком и уведомлять вас о том, что делают (или не дела-

ют) другие узлы в настоящий момент. Разумеется, речь идет только о сетях с

разделяемой пропускной способностью. Если используется коммутатор Et-

hernet, будет доступен только трафик в пределах отдельного сегмента. Неко-

торые коммутаторы имеют специальный порт для наблюдения. В остальных

случаях необходимо доставить средство наблюдения в зону проблемы.

Пользователи Linux могут использовать tcpdump. Эта программа подобна snoop.

Анализ проблем протоколов

535

Фильтр «host crab and host rodent» отбирает только пакеты, исходящие от

узла rodent и адресованные узлу crab, и пакеты, исходящие от crab и адресо-

ванные rodent. Фильтр состоит из набора примитивов, связанных с ними

имен узлов, протоколов и номеров портов. Примитивы изменяются и комби-

нируются при помощи операторов and, or и not. Фильтр может отсутствовать;

в этом случае snoop отображает все пакеты сети.

В табл. 13.2 описаны примитивы фильтров snoop. Существует ряд дополни-

тельных примитивов и варианты примитивов, дублирующие функциональ-

ность, но в таблицу включены только наиболее востребованные. Дополни-

тельная информация содержится на страницах руководства (man) по snoop.

Совместное использование примитивов и операторов and и or позволяет созда-

вать сложные фильтры. Однако фильтры, как правило, просты. Фильтр для

выявления обмена между парой узлов - вероятно, наиболее распространен-

ный. Дополнительно можно ограничить полученные данные определенным

протоколом, но часто неизвестно, какой из протоколов приводит к сбоям. Ес-

ли пользователь встречается с проблемой при работе с ftp или

telnet,

это еще

не повод обвинять соответствующие протоколы. Часто анализ следует начи-

нать с перехвата всех пакетов и последующего сужения области поиска лишь

после того, как результаты тестов укажут на более конкретную проблему.

Это возможно, только если интерфейс поддерживает работу в беспорядочном ре-

жиме, что верно не для всех интерфейсов.

Фильтры для пакетов

snoop читает все пакеты сегмента Ethernet. С этой целью snoop переводит ин-

терфейс Ethernet в беспорядочный режим (promiscuous mode).

В нормаль-

ной ситуации интерфейс Ethernet передает протоколам более высокого уров-

ня только пакеты, предназначенные локальному узлу. В беспорядочном ре-

жиме принимаются и передаются все пакеты, что и позволяет snoop просмат-

ривать и выбирать для анализа пакеты, исходя из фильтров, определенных

пользователем. Фильтры позволяют отбирать пакеты, адресованные опреде-

ленному узлу, протоколу, порту или произвольному их сочетанию либо ис-

ходящие от определенного узла, протокола, порта или произвольного их со-

четания. В качестве примера рассмотрим очень простой фильтр

snoop.

Следу-

ющая команда snoop приводит к отображению всех пакетов из обмена узлов

crab и rodent:

536 Глава 13. Разрешение проблем TCP/IP

Таблица 13.2. Примитивы выражений

Примитив

Отбирает пакеты

dst host | net | port destination

Адресованные целевому узлу (host), сети (net) или на

порт (port)

src host | net | port source

Исходящие от узла (host), сети (net) или порта (port)

host destination

Исходящие или адресованные узлу (host)

net destination

Исходящие или адресованные сети

port destination Исходящие или адресованные на порт

ether address

Исходящие или адресованные на адрес Ethernet

protocol

С типом протокола (icmp, udp или tcp)

Изменение вывода анализатора

Пример из предшествующего раздела показывает, что snoop выводит единст-

венную строку-резюме для каждого из полученных пакетов. В каждой стро-

ке содержатся адреса источника и получателя, а также используемый про-

токол (ICMP и RLOGIN в нашем примере). Строки пакетов ICMP содержат

сведения о типах пакетов (Echo request и Echo reply в нашем примере). Стро-

ки пакетов прикладных протоколов содержат номер порта источника и пер-

вые 20 символов данных пакета.

Этой сводки достаточно, чтобы понять, как обмениваются пакетами узлы и

какие потенциальные проблемы могут возникать. Однако диагностирование

проблем протоколов требует более подробных сведений о каждом пакете.

Управление составом отображаемой информации реализуется ключами snoop.

Чтобы вывести данные пакета, воспользуйтесь ключом -х. Ключ предписы-

вает отображать полное содержимое пакета в шестнадцатеричном формате

или ASCII. В большинстве случаев нет необходимости просматривать пакеты

целиком - достаточно заголовков, чтобы продиагностировать проблему про-

токола. Ключ -v предписывает отображать заголовки - подробно и в удобном

для чтения формате. Для каждого пакета отображается большое число

строк, поэтому использовать ключ -v следует только по необходимости.

Следующий пример содержит пакет ICMP Echo Request, вывод которого

предписан ключом -v. Пакет этого типа присутствовал в виде строки-резюме

в предшествующем примере.

Пример анализа протокола

537

Подробное форматирование snoop связывает байты, полученные из сети, со

структурой заголовка. В поисках более подробной информации о различных

полях заголовка обращайтесь к главе 1 и приложению G.

Пример анализа протокола

Данный пример повторяет случай из реальной жизни, когда проблема реши-

лась при помощи анализа протокола. Суть проблемы: время от времени про-

исходил сбой в работе ftp со следующим сообщением об ошибке:

netout: Option not supported by protocol 421 Service not available, remote server

has closed connection

О проблеме заявил только один пользователь, и он сталкивался с ней только

при передаче больших файлов с рабочей станции на центральную машину по

нашей магистральной сети.

Мы взяли файл данных пользователя и смогли воспроизвести проблему с

других рабочих станций. При этом проблема возникала только при передаче

файла на ту же центральную систему по магистральной сети. Рисунок 13.4

наглядно отражает тесты, которые мы выполнили для воспроизведения

проблемы.

538

Глава 13. Разрешение проблем TCP/IP

Рис. 13.4. Резюме теста FTP

Мы уведомили о проблеме всех пользователей. В ответ мы получили сообще-

ния, что и другие пользователи сталкивались с проблемой, но опять же -

только при передаче данных на центральную систему и только при передаче

по магистрали. Другие пользователи не сообщали о проблеме, поскольку

редко сталкивались с ней. Эти дополнительные сообщения свидетельствова-

ли в пользу того, что проблема не связана с последними изменениями в сети.

Поскольку мы воспроизвели проблему на других системах, вероятнее всего,

ее причина не в неверных настройках системы пользователя. Кроме того,

сбой ftp происходил только в случаях, когда взаимодействовали маршрути-

заторы магистральной сети и центральная система. Поэтому мы сосредото-

чили внимание на этих машинах. Мы проверили таблицы маршрутизации и

таблицы ARP, а также выполнили прозвонку центральной системы и марш-

рутизатораов. И не столкнулись ни с какими проблемами.

На основе предварительных данных можно было предположить, что сбой ftp

происходил в результате некой проблемы взаимодействия маршрутизаторов

определенной фирмы и центрального компьютера. Мы сделали такое пред-

положение потому, что передача данных устойчиво прерывалась только при

взаимодействии этих двух видов систем, но никогда - в других ситуациях.

Пример анализа протокола 539

Если неверны настройки маршрутизатора или центральной системы, сбой

должен возникать и при передаче данных на другие узлы. Если проблема

связана со случайными сбоями физического характера, она должна возни-

кать время от времени и не зависеть от того, какие узлы участвуют в процес-

се. Проблема же, напротив, поддавалась прогнозированию и возникала

только при взаимодействии машин определенных типов. Возможно, дело

было в несовместимости реализаций TCP/IP этих систем.

Поэтому мы воспользовались snoop и перехватили заголовки TCP/IP в ходе

нескольких сеансов тестирования ftp. Изучение результатов показало, что во

всех сеансах, заканчивающихся сообщением об ошибке «netout», ближе к

концу сеанса присутствовал пакет ICMP Parameter Error - обычно за 50 паке-

тов до окончания передачи. Ни в одном успешном сеансе передачи такого па-

кета не было. Обратите внимание, что ошибка возникала вовсе не на послед-

нем пакете потока данных, как можно было бы предположить. Часто бывает

так, что после обнаружения ошибки поток данных остается открытым какое-

то время до разрыва соединения. Не следует считать, что ошибка всегда при-

сутствует в конце потока данных.

Вот заголовки из ключевых пакетов. Сначала IP-заголовок пакета от ма-

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

ошибке на центральной системе:

540

Глава 13. Разрешение проблем TCP/IP

А вот пакет ICMP Parameter Error, отправленный центральной системой в

ответ:

Каждый из заголовков поделен на биты и связан с соответствующими поля-

ми заголовка TCP/IP. Из этого подробного анализа каждого пакета мы мо-

жем видеть, что маршрутизатор передал параметр IP Header Checksum (конт-

рольная сумма заголовка IP) со значением Oxffff, и центральной системе

контрольная сумма не понравилась. Нам известно, что центральная система

среагировала именно на этот параметр, поскольку она вернула ошибку ICMP

Parameter Error и указатель (Pointer) со значением 10. Parameter Error ука-

зывает на некорректность только что полученных данных, a Pointer указы-

вает на данные, которые система полагает ошибочными. Десятый байт в за-

головке IP-пакета маршрутизатора - поле IP Header Checksum. Поле дан-

ных сообщения об ошибке ICMP содержит заголовок, который считается

Пример анализа протокола

541

ошибочным. При просмотре этих данных мы заметили, что, возвращая заго-

ловок, центральная система «скорректировала» поле контрольной суммы и

записала в него значение 0000. Очевидно, центральная система не согласна с

вычисленной маршрутизатором контрольной суммой.

Время от времени ошибки с вычислением контрольной суммы происходят.

Они могут быть вызваны проблемами передачи и необходимы для выявле-

ния подобного рода проблем. В каждом семействе протоколов существует

механизм для восстановления после ошибок в контрольной сумме. Как они

могут обрабатываться в TCP/IP?

Чтобы определить действие протокола, корректное в данной ситуации, мы

обратились к авторитетным источникам - документам RFC. RFC 791, Inter-

net Protocol, снабдил нас информацией о вычислении контрольной суммы,

но лучшим источником для данной конкретной проблемы стал документ

RFC 1122, Requirements for Internet Hosts - Communication Layers (Требова-

ния к узлам сети Интернет - уровни передачи данных), за авторством

Р. Брейдена (R. Braden). Этот документ содержит две отсылки к действиям,

которые должны быть предприняты. Следующие выдержки взяты со стра-

ницы 29 документа RFC 1122:

В нижеследующем тексте в определенных случаях в отношении полученной

дейтаграммы используется выражение «молча удалить». Это означает, что

дейтаграмма удаляется без дополнительной обработки, а узел не посылает ка-

кие-либо ICMP-сообщения об ошибках (см. раздел 3.2.2) в результате...

...Узел ОБЯЗАН проверять правильность контрольной суммы заголовка IP для

каждой полученной дейтаграммы и молча удалять все дейтаграммы с невер-

ными контрольными суммами.

Следовательно, получив пакет с неверной контрольной суммой, система не

должна ничего с ним делать. Пакет следует удалить, а затем ожидать по-

ступления следующего пакета. Система не должна отвечать сообщением об

ошибке. Система не может ответить на неверную контрольную сумму 1Р-за-

головка, поскольку не может определить, откуда в действительности посту-

пил пакет. Если под сомнением контрольная сумма заголовка, как опреде-

лить, что верны адреса в заголовке? А если нет уверенности относительно

источника пакета, как можно на него ответить?

IP полагается на протоколы верхних уровней в восстановлении после таких

ошибок. Если используется TCP (как было в данном случае), источник TCP в

конечном итоге замечает, что получатель не подтвердил доставку сегмента, и

посылает сегмент заново. Если используется UDP, приложение-источник от-

вечает за восстановление после ошибки. Ни в том ни в другом случае восста-

новление не зависит от сообщения об ошибке, генерируемого получателем.

Итак, получив неверную контрольную сумму, центральная система должна

была просто удалить испорченный пакет. Мы уведомили о проблеме разработ-

чиков, и, следует отметить, они прислали нам поправку к программному обес-

печению в пределах двух недель. Более того, поправка замечательно работала!