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

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

512

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

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

ло ее работе. Новая сеть разрешит ваши проблемы с конфликтами пакетов и

сократит объем работ по диагностированию аппаратных проблем.

Сетевые аппаратные проблемы

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

проблему с сетевыми устройствами. При обнаружении такой проблемы свя-

житесь с людьми, ответственными за аппаратное обеспечение. Если пробле-

ма предположительно связана с выделенной телефонной линией, свяжитесь

с телефонной компанией. Если с территориальной сетью - с руководством

этой сети. Не ждите, что проблема исчезнет сама по себе. Она может еще и

усу губиться.

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

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

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

новится перебор - отключение устройств по одному. Удобнее всего выполнять

такую операцию на коммутаторе или концентраторе. Обнаружив устройство,

вызывающее проблемы, почините или замените его. Помните, что пробле-

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

Проверка маршрутизации

Сообщение об ошибке «network unreachable» четко указывает на проблему

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

легко обнаружить и устранить. Во-первых, воспользуйтесь командами net-

stat -nr и grep, чтобы определить, присутствует ли в таблице допустимый

маршрут к целевой системе.

В данном примере проверяется наличие марш-

рута к сети 128.8.0.0:

netstat -n г работает в большинстве систем, однако администраторы Linux предпо-

читают команду route -п.

Этот же тест на системе, не имеющей такого маршрута в таблице, завершится

вообще без результатов. К примеру, пользователь сообщает, что «сеть легла»,

потому что он не может провести сеанс ftp с helios.metalab.unc.edu, а про-

звонка возвращает следующие результаты:

Проверка маршрутизации

513

helios.metalab.unc.edu PING Statistics

2 packets transmitted, 0 packets received, 100% packet loss

Руководствуясь сообщением «network unreachable», проверьте таблицу

маршрутизации пользователя. В данном случае мы ищем маршрут к системе

helios.metalab.unc.edu. IP-адрес

helios.metalab.unc.edu - 152.2.210.81. Вы-

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

следовательности 152.2:

% netstat -nr | grep "Ч52\.2\. '

Данная проверка показала, что таких маршрутов нет. Если бы маршрут су-

ществовал, команда grep отобразила бы его. Поскольку нет конкретного

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

по умолчанию. Следующий пример показывает успешную проверку марш-

рута по умолчанию в системе Solaris:

% netstat -nr | grep def

default 172.16.12.1 UG 0 101277 dnetO

Если netstat свидетельствует о наличии конкретного маршрута или действу-

ющего маршрута по умолчанию, проблема не в таблице маршрутизации. В

таком случае воспользуйтесь командой trace route (как описано в следующем

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

Если в таблице маршрутизации ожидаемый маршрут отсутствует, проблема

в локальной маршрутизации. Существует два подхода к таким проблемам, в

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

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

маршрут при помощи команды route

add.

Помните, большинство систем, ис-

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

чанию, поэтому нужным маршрутом вполне может быть маршрут по умолча-

нию. Убедитесь, что загрузочные файлы добавляют необходимый маршрут в

таблицу при загрузке системы. Подробно команда route add описана в главе 7.

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

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

что запущен демон gated:

% ps 'cat /etc/gated.pid'

PID TT STAT TIME COMMAND

27711 ? S 304:59 gated -tep /etc/log/gated.log

Если нужный демон маршрутизации не запущен, перезапустите его и пред-

пишите трассировку. Трассировка позволяет обнаружить проблемы, вы-

нуждающие демон аварийно завершать работу.

Воспользуйтесь nslookup для определения адреса IP, если не знаете его. Програм-

ма nslookup описана далее в этой главе.

В системе Linux выполняйте grep для сети 0.0.0.0, которая в Linux применяется

для обозначения маршрута по умолчанию - вместо слова «default».

514

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

Трассировка маршрутов

Если локальная таблица маршрутизации в порядке, проблема может су-

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

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

answer», а также «network unreachable». При этом сообщение «network un-

reachable» не всегда указывает на проблему маршрутизации, оно может

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

ду локальным узлом и удаленным пунктом назначения. Обнаружить такие

проблемы позволяет программа trace route.

trace route отслеживает маршрут пакетов UDP, адресованных локальным уз-

лом удаленному узлу. Программа отображает имя (по возможности) и адрес

IP каждого шлюза на пути к удаленному узлу.

trace route при трассировке пакетов использует два механизма: небольшое

TTL (время жизни) пакета и некорректные номера портов, trace route посы-

лает пакеты UDP с небольшими значениями TTL, чтобы обнаружить проме-

жуточные шлюзы. Значения TTL начинаются с 1 и увеличиваются на 1 для

каждой группы из трех отправленных пакетов UDP. Получив пакет, шлюз

уменьшает TTL. Если TTL к этому моменту имеет значение 0, пакет не пере-

сылается дальше, а источнику пакета возвращается ICMP-сообщение «Time

Exceeded» (время доставки превышено), traceroute выводит одну строку для

каждого шлюза, от которого получено сообщение «Time Exceeded». На

рис. 13.2 представлена одна строка вывода и описаны значения ее полей.

Рис. 13.2. Вывод traceroute

Конечный узел, получив пакет от traceroute, возвращает ICMP-сообщение

«Unreachable Port» (порт не доступен). Это происходит потому, что tracerou-

te преднамеренно использует недействительный номер порта (33434), чтобы

вызвать такую ошибку. Получив сообщение «Unreachable Port», traceroute

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

Итак, traceroute обладает способностью получать список шлюзов, обозначая

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

ресованный ему пакет. На рис. 13.3 представлена передача пакетов трасси-

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

Ниже приведен вывод traceroute для www.internic.net, инициированный сис-

темой Solaris в сети Comcast, traceroute посылает три пакета для каждого

значения TTL. Если для пакета не получен ответ, traceroute выводит звез-

дочку (*). Если ответ получен, traceroute отображает имя и адрес ответивше-

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

Проверка маршрутизации

515

Рис. 13.3. Передача пакетов traceroute

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

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

516

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

тов, адресованных данным узлом системе www.internic.net, составляет около

140 миллисекунд.

Вариации и ошибки в реализациях ICMP на шлюзах различных типов,

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

шествовать дейтаграмма, могут приводить к странным результатам. По этой

причине не слишком заостряйтесь на выводе traceroute. Самые важные во-

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

• Добрался ли пакет до пункта назначения?

• Если нет, где он был остановлен?

Следующий листинг содержит другую трассировку пути к www.internic.net.

На этот раз пакет до InterNIC не добрался.

Если traceroute не удается доставить пакеты удаленной системе, трассиров-

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

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

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

последнего шлюза из вывода

traceroute.

Объясните им, в чем проблема, воз-

можно, они смогут оказать помощь. В нашем примере последним шлюзом из

ответивших на пакет стал pl6-0-0-0.r04.snjsca03.us.bb.verio.net. Следователь-

но, мы свяжемся с администратором этой системы и администратором

www.internic.net.

Поиск администратора

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

делить, кто он. whois помогает в поиске важных лиц. Один из важнейших

элементов информации в сети - сведения о том, кто управляет второй сторо-

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

ет получить whois.

Проверка маршрутизации

517

whois извлекает нужную информацию из белых страниц сети Интернет. Бе-

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

которую регистраторы сети Интернет. Чтобы получить официальный номер

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

которая становится вашей личной записью в базе данных белых страниц. По

этой причине предполагается, что все лица, ответственные за официальные

сети или домены, имеют запись в белых страницах, и эта запись доступна

всем, кому необходимо связаться с этими лицами.

Во многих системах Unix существует команда

whois,

позволяющая запраши-

вать сведения из белых страниц. Общий синтаксис команды:

whois [-h server] name

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

белых страниц. Поле server содержит имя сервера системы белых страниц.

В следующем примере мы выполняем поиск контактной информации для

домена verio.net, то есть для домена, в котором располагается удаленный

маршрутизатор из примера по traceroute.

518

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

По запросу отображается имя, адрес и телефонный номер контактных лиц

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

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

грамотным управлением, таких как verio.net, она обычно так и работает.

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

ной информации, так как сопровождение базы данных белых страниц не на

высоте. Если whois не возвращает нужной информации, попробуйте обра-

титься к службе имен DNS. Запись DNS SOA должна содержать почтовый

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

вам координаты искомого системного администратора.

Проверка службы имен

На проблемы с сервером имен указывает сообщение об ошибке «unknown

host», полученное от пользовательского приложения. Проблемы, связанные

со службой имен, обычно могут диагностироваться при помощи nslookup или

dig.

nslookup подробно обсуждался в главе 8; dig - это альтернативный инст-

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

Прежде чем обратиться к

dig,

взглянем еще раз на nslookup и его применение

для отладки службы имен.

Проверка службы имен

519

Особо важными для отладки проблем удаленного сервера имен являются

три возможности

nslookup,

описанные в главе 8. Эти возможности отражают

способность программы:

• Находить компетентные серверы удаленного домена при помощи запро-

сов записей NS

• Извлекать все записи по удаленному узлу при помощи запросов ANY

• Просматривать все записи удаленной зоны при помощи команд nslookup

Is и view

При диагностировании проблемы удаленного сервера обращайтесь напря-

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

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

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

ные серверы по очереди и сравните их ответы. Причиной нерегулярных

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

ры возвращают различные ответы на один и тот же запрос.

Запрос ANY возвращает все записи, в которых фигурирует определенный

узел, что дает наиболее широкий диапазон сведений для отладки. Простое

знание, какая информация доступна (и недоступна), может разрешить множе-

ство проблем. Например, если запрос возвращает запись MX, но не возвраща-

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

инициировать сеанс telnet с этим узлом! Многие узлы доступны для почтовой

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

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

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

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

вильного имени в этом случае можно сравнить с поиском иголки в стоге се-

на. Тем не менее программа nslookup способна помочь. Воспользуйтесь ко-

мандой nslookup

Is,

чтобы получить копию файла удаленной зоны и записать

ее в локальный файл. Затем используйте команду nslookup view для просмот-

ра этого файла в поисках имен, похожих на представленное пользователем.

Многие проблемы возникают из-за неверных имен узлов.

Все упомянутые здесь возможности и команды nslookup используются в гла-

ве 8. Тем не менее примеры использования этих команд для разрешения ре-

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

основаны на реальных сообщениях о проблемах.

Одни системы работают, другие - нет

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

разрешается, а на центральной системе - нет. При этом центральная систе-

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

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

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

520

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

Данный сеанс nslookup содержит несколько шагов. Прежде всего, необходи-

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

ster.foo.edu). Мы установили тип запроса в NS, чтобы получить соответству-

ющие записи, и выполнили поиск для домена (foo.edu), к которому принад-

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

ров: gerbil.foo.edu, red.big.com и shrew.foo.edu.

Затем мы установили тип запроса в ANY с целью поиска произвольных за-

писей, связанных с именем проблемного узла. Затем мы предписали nslookup

обращаться к первому серверу из списка компетентных, gerbil.foo.edu, и вы-

полнили запрос для hamster.foo.edu. Мы получили адресную запись. Итак,

сервер gerbil.foo.edu работает замечательно. Мы повторили тест для сервера

red.big.com и получили сбой. Запрос не вернул каких-либо записей.

Следующий шаг - получить записи SOA с каждого из серверов и выяснить,

идентичны ли они:

нет. Какой-то определенной и предсказуемой схемы у сбоев не было. Поэто-

му мы воспользовались nslookup для проверки удаленных серверов:

Проверка службы имен

521

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

что файл зоны (а следовательно, и данные узла) еще не был скопирован на

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

чаются, как в этом случае, присутствует конкретная проблема. Уведомите

администратора удаленного домена. Почтовый адрес администратора содер-

жится в поле «mail addr» записи SOA. В нашем примере письмо с описанием

проблемы отправляется на адрес amanda@gerbil.foo.edu.

Данные на месте, но сервер не может

их обнаружить!

Об этой проблеме сообщил администратор одного из наших подчиненных

серверов имен. Администратор сообщил, что его сервер не может выполнить

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

ется подчиненным. Основной сервер при этом совершенно свободно выпол-

нял ту же операцию. Администратор получил образ кэша (более подробно об

этом поговорим в следующем разделе), и таким образом убедился, что его

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

это, сервер не мог выполнить преобразование имени узла в IP-адрес!

Проблема была воспроизведена на ряде других подчиненных серверов. Имя

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

ми. Все серверы имели один и тот же порядковый номер в записи SOA, и образ

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

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

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

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

файла зоны. Основные серверы загружают свои данные непосредственно из

локальных дисковых файлов. Подчиненные серверы получают данные от ос-