Недорогие авиабилеты

Версия 21:58, 20 марта 2008

Диагностика: проблемы с сетью

Если сеть у вас захворала, зовите Доктора! Правда, домашних визитов к читателям д-р Крис Браун не делает, но готов поделиться диагнозом…

За годы жизни я помог многим друзьям и знакомым освоиться с компьютером, и в подходящих случаях обучал их Linux. При этом, естественно, возникает нечто вроде родительской ответственности за развитие и взросление своих питомцев. Последний случай был типичным. Друг позвонил мне со словами: «У меня не работает сеть». Такое сообщение об ошибке не уступает классической фразе с борта Аполлона-13 «Хьюстон, у нас проблема», хотя и менее опасно для жизни. К счастью, в Linux много сетевых утилит, которые помогают выяснить, что именно не работает. (Чтобы не томить вас ожиданием развязки, сразу скажу, что моего друга просто отключил провайдер, потому что он забыл продлить контракт.)

Итак, следуйте за мной: рассмотрим некоторые средства диагностики сетевых неисправностей в Linux и посмотрим, как с их помощью получить ответ на вопрос «Что не так в моей сети?»

При любом поиске неисправностей прежде всего нужно понять и представить, в чем выражается правильная работа. Есть ли у компьютера статический IP-адрес, и если да, то какой? Пользуетесь ли вы DHCP, и если да, то каков адрес DHCP-сервера и выделяемый диапазон IP-адресов? Подключен ли широкополосный модем непосредственно к вашему компьютеру или у вас широкополосный маршрутизатор через Ethernet или беспроводную сеть?

На данном уроке мы будем использовать методику «снизу вверх»: начнем с самых низких уровней и постепенно переедем на более высокие. Это хороший систематический подход для случая, если сеть не работала никогда. С другой стороны, если вчера сеть работала отлично, чаще будет быстрее начать сверху и двигаться вниз.

Находит ли Linux сетевую карту?

Первый вопрос на этом этапе – видит ли Linux сетевые интерфейсы? Вы сможете ответить на него, просмотрев системные сообщения ядра, которые выдавались во время загрузки. Для этого используется команда <fotn color=darkred>dmesg</font>:

# dmesg | grep eth
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth0: e1000_watchdog: NIC Link is Up 10 Mbps Half Duplex

В качестве альтернативы попробуйте вывести список устройств на шине с помощью команды <fotn color=darkred>lspci</font>:

# lspci | grep Ethernet
01:01.0 Ethernet controller: Intel Corporation 82547EI
02:01.0 Ethernet controller: Intel Corporation 82540EM

Сообщения об ошибках на этой стадии говорят о неисправном или несовместимом оборудовании.

Задан ли IP-адрес?

Если сетевая карта на месте, то следующий вопрос – задан ли IP-адрес? Простейшая команда для этого случая – <fotn color=darkred>ifconfig</font>:

# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0C:F1:96:A3:F7
inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::20c:f1ff:fe96:a3f7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:306 errors:0 dropped:0 overruns:0 frame:0
TX packets:261 errors:0 dropped:0 overruns:0 carrier:0
collisions:8 txqueuelen:10
RX bytes:43074 (42.0 KiB) TX bytes:34480 (33.6 KiB)
Base address:0xac00 Memory:ff7e0000-ff800000

Здесь важна вторая строка, в которой можно увидеть IP-адрес: <fotn color=darkred>192.168.0.3</font>. Если такой строки нет, то IP-адрес не задан. А если все же задан, подумайте, действителен ли он в вашей сети.

На практике я несколько раз сталкивался с ситуацией, когда сеть переставала работать после того, как в нее ввели компьютер, случайно оказавшийся DHCP-сервером, настроенным на диапазон адресов, не соответствующих этой сети. При перезагрузке компьютер с шансами 50/50 получал или действительный IP-адрес от «настоящего» DHCP-сервера, или ложный адрес от самозванца.

Если в сетевом интерфейсе не задан IP-адрес, то проверьте, настроен ли автоматический запуск этого интерфейса при загрузке системы. Если да, то использует ли он DHCP или статический IP-адрес? Конкретные имена файлов, которые нужно просмотреть, зависят от дистрибутива. В Fedora и Red Hat это /etc/sysconfig/network-scripts/ifcfg-eth*, в SUSE – /etc/sysconfig/network/ifcfg-eth*, а в Ubuntu – /etc/network/interfaces. (Стандарты – отличная штука: ну не прелестны ли эти ничем не объяснимые расхождения?) Конечно, в каждом из дистрибутивов есть графические утилиты, с помощью которых можно посмотреть и отредактировать настройки.

Обычно инициализация интерфейса упрятана глубоко в загрузочные скрипты, и взаимодействие с сервером DHCP разглядеть трудно; но его можно увидеть, непосредственно запустив скрипт ifup или dhclient. Эта программа поддерживает диалог с DHCP-сервером и позволяет задать параметры сети:

# dhclient
Internet Systems Consortium DHCP Client V3.0.5-RedHatо
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth1/00:0e:0c:01:d3:a0
Sending on LPF/eth1/00:0e:0c:01:d3:a0
Listening on LPF/eth0/00:0c:f1:96:a3:f7
Sending on LPF/eth0/00:0c:f1:96:a3:f7
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 192.168.0.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.3 -- renewal in 125868 seconds.

В данной системе два интерфейса, eth0 и eth1. Мы видим, что IP-адрес интерфейса eth0 получен от DHCP-сервера 192.168.0.1. Интерфейс eth1 пытался сделать то же самое (он передал команду <fotn color=darkred>DHCPDISCOVER</font>), но не получил ответа. И неудивительно: этот интерфейс не был ни к чему подключен.

Пингуется ли маршрутизатор?

Если IP-адрес задан корректно, пропингуйте (<fotn color=darkred>ping</font>) другой компьютер в сети. В случае удачи результат будет примерно таким:

# ping -c1 192.168.0.6
PING 192.168.0.6 (192.168.0.6) 56(84) bytes of data.
64 bytes from 192.168.0.6: icmp_seq=1 ttl=64 time=0.468 ms
--- 192.168.0.6 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.468/0.468/0.468/0.000 ms

а неудачи – таким:

# ping -c 1 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
From 192.168.0.3 icmp_seq=1 Destination Host Unreachable
--- 192.168.0.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Сообщение <fotn color=darkred>«Узел недоступен»</font> (<fotn color=darkred>Destination Host Unreachable</font>) обычно значит, что целевой компьютер (здесь – 192.168.0.2) не подключен к сети или не работает и поэтому не может ответить на ARP-запрос MAC-адреса с моего компьютера. Это также может означать, что ваш компьютер не находит маршрут доступа к локальной сети; чаще всего это бывает, когда ваш IP-адрес не входит в данную сеть. Возможны и более сложные проблемы с маршрутизацией – впрочем, в домашней сети, где маршрут (по умолчанию) только один, это маловероятно. Если в вашей сети нет других компьютеров, можно попробовать пропинговать маршрутизатор (Вы ведь знаете адрес своего маршрутизатора?).

Если не получилось, то проблема носит местный характер. Если сеть проводная, проверьте кабели. Зеленые светодиоды на сетевых карточках должны гореть <fotn color=darkblue>[некоторые сетевые карты имеют другой способ индикации подключения. В случае необходимости изучите инструкцию, – прим.ред.]</font>.

Не блокирован ли трафик брандмауэром?

На некотором этапе нашего диагностирования полезно проверить, не чересчур ли «закручивает гайки» ваш брандмауэр. Самый быстрый и грубый способ это узнать – и его предпочитают многие системные администраторы, если надо торопиться – удалить все правила брандмауэра командой

# iptables -F

и посмотреть, изменится ли что-нибудь к лучшему. Если проблема исчезнет, то по крайней мере ясно, что ее причиной был брандмауэр. Далее вам нужно перезагрузить компьютер (чтобы брандмауэр вновь заработал) и думать дальше. Не соблазняйтесь идеей оставить брандмауэр в отключке: это Плохая Идея!

5 Установлено ли ADSL-соединение ?

Если с самим маршрутизатором все в порядке, пора расширить охват. На маршрутизаторе должно быть еще несколько зеленых светодиодов (а если найти инструкцию к нему, то можно даже понять, что они означают), и по ним можно определить, подключен ли ADSL-модем маршрутизатора к провайдеру. У некоторых маршрутизаторов также есть возможность задать настройки и определить статус соединения с помощью web-приложения. Нас интересуют статус соединения (Connection Status) и IP-адрес, который провайдер назначил внешнему соединению. (Что это за адрес, не столь важно; главное, чтоб он был!) Разорвите соединение и заново установите его вручную, и попробуйте понять, на каком этапе возникает ошибка. Если соединения не добиться, нужно проверить провод, соединяющий маршрутизатор с телефонной линией (полезно подключить телефонную трубку, чтобы убедиться в наличии зуммера). Если провод в порядке, остается позвонить в службу поддержки провайдера. Приготовьте себе чашку кофе и вооружитесь интересной книжкой – ждать своей очереди на линии можно очень долго!

Пингуется ли удаленный сервер?

Если соединение с провайдером хорошее, тестированию пора подняться на уровень выше. Попробуйте пропинговать внешний компьютер с известным IP-адресом. Например, web-сервер Linux Format UK имеет адрес 89.167.142.11. (Конечно, он вполне может измениться, когда вы будете это читать, но пока для примера сгодится.)

# ping -c1 89.167.142.11
PING 89.167.142.11 (89.167.142.11) 56(84) bytes of data.
64 bytes from 89.167.142.11: icmp_seq=1 ttl=56 time=24.3 ms
--- 89.167.142.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.367/24.367/24.367/0.000 ms

Если это работает, ваше сетевое соединение в порядке. В качестве последнего теста попробуйте добраться до удаленного компьютера по его имени:

# ping -c1 www.linuxformat.com
PING www.linuxformat.com (89.167.142.11) 56(84) bytes of data.
64 bytes from kryten.future.net.uk (89.167.142.11): icmp_seq=1
ttl=56 time=24.2 ms
--- www.linuxformat.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.249/24.249/24.249/0.000 ms

С помощью этого теста ошибки DNS сразу же выявляются, например:

$ ping www.prophylactic.gov
ping: unknown host www.prophylactic.gov

Если удаленный компьютер пингуется только по IP-адресу, но не по имени, пора изучать настройки вашего сервера DNS (LXF97). Для этого лучше всего подходит утилита dig. Вот пример ее запуска (успешного). Не пугайтесь обилием подробностей; нужно лишь обратить внимание на запись <fotn color=darkred>A</font> в разделе <fotn color=darkred>ANSWER</font>:

# dig www.linuxformat.com
; <<>> DiG 9.4.0 <<>> www.linuxformat.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23236
;; flags: qr rd ra; QUERY:1, ANSWER:2, AUTHORITY:2,
ADDITIONAL:2
;; QUESTION SECTION:
;www.linuxformat.com. IN A
;; ANSWER SECTION:
www.linuxformat.com. 300 IN CNAME redirect1.future.net.uk.
redirect1.future.net.uk. 300 IN A 89.167.142.11
;; AUTHORITY SECTION:
future.net.uk. 245 IN NS ns0.future.net.uk.
future.net.uk. 245 IN NS ns1.future.net.uk.
;; ADDITIONAL SECTION:
ns0.future.net.uk. 33231 IN A 89.167.142.1
ns1.future.net.uk. 33231 IN A 89.167.143.1
;; Query time: 41 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Jul 6 15:21:44 2007
;; MSG SIZE rcvd: 158

Если DNS не работает, вариантов может быть несколько.

В первом случае сервер DNS не может найти компьютер, к которому вы обращаетесь. Вот пример обращения к серверу, которого просто не существует:

# dig prophylactic.gov
; <<>> DiG 9.4.0 <<>> prophylactic.gov
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13168
;; flags: qr rd ra; QUERY:1, ANSWER:0, AUTHORITY:1,
ADDITIONAL:0
;; QUESTION SECTION:
;prophylactic.gov. IN A
;; AUTHORITY SECTION:
gov. 2560 IN SOA a.gov.zoneedit.com. govcontact.
zoneedit.com. 1183644065 3600 900 1814400 86400

Обратите внимание на статус запроса <fotn color=darkred>NXDOMAIN</font> и отсутствие раздела <fotn color=darkred>ANSWER</font>, который мы видели в результатах предыдущего запроса. Если вы ввели корректное имя компьютера, то такая ошибка – следствие чьих-то чужих проблем.

Можете ли вы найти свой DNS-сервер?

Вторая причина отказа DNS – ваш компьютер не может найти DNS-сервер. Тогда источник проблемы, вероятно, ближе к дому.

# dig www.linuxformat.co.uk
; <<>> DiG 9.4.0 <<>> www.linuxformat.co.uk
;; global options: printcmd
;; connection timed out; no servers could be reached

Если это произошло, загляните в файл /etc/resolv.conf. В нем Linux хранит сведения о местонахождении DNS-серверов. Если вы пользуетесь DHCP, IP-адреса DNS-серверов предоставляются сервером DHCP. Если IP-адрес статический, вы, наверно, использовали графическую утилиту настройки для определения параметров серверов DNS (например, system-config-network в Fedora). В любом случае результаты записываются в этот файл. Есть ли в нем корректный адрес сервера имен? Можете ли вы пинговать его?

Если ничто не помогает, попробуйте просмотреть сетевой трафик с помощью wireshark, утилиты отслеживания пакетов, ранее известной как ethereal. Как средство диагностики wireshark, на мой взгляд, «последняя надежда». Дело не в недоработке этой программы: программа-то отличная, но чтобы искать неполадки в сети путем изучения трафика на уровне пакетов, нужно очень хорошо знать TCP/IP и прикладные протоколы верхних уровней. Вам также может потребоваться дополнительный компьютер в сети для наблюдения за трафиком.

Выполните команду

# ping 192.168.0.42

на компьютере с IP-адресом 192.168.0.3. Посмотрите на верхнюю из трех панелей wireshark; в ней каждому перехваченному пакету соответствует одна строка. Средняя и нижняя панели позволяют разобраться в содержимом отдельных пакетов, но сейчас они нам не нужны. Сообщение простое и ясное: компьютер с адресом 192.168.0.3 пытается использовать ARP для получения MAC-адреса компьютера, до которого хочет достучаться. Он пытался сделать это три раза с интервалом в одну секунду, но не получил ответа.

Итак, мы можем сделать вывод, что с компьютером, адрес которого 192.168.0.3, все в порядке – он может получать пакеты от компьютеров сети с корректными IP-адресами, но компьютера с адресом 192.168.0.42 там просто нет.

Смотрим дальше

Вот другой пример. На клиентском компьютере установлен SUSE Linux 10.1. Проблема была в том, что каждый раз, когда браузер Konqueror пытался соединиться с внешним сайтом (т.е. производил поиск DNS-сервера), перед установкой соединения возникала 15-секундная задержка. Пакет 1 реализует стандартный запрос DNS для адреса www.linuxformat.co.uk, а пакет 3 – ответ на этот запрос, который приходит через 0.04 с от сервера DNS, встроенного в мой маршрутизатор (192.168.0.1) с требуемым IP-адресом. Чудесно. Проблема в том, что Konqueror также решил запросить IPv6-адрес для этого сайта (запрос записи <fotn color=darkred>AAAA</font> в пакете 2). Слава богу, маршрутизатор игнорирует этот запрос, и через пять секунд Konqueror перенаправляет этот запрос к маршрутизатору (пакет 7) и ко внешнему серверу DNS (пакет 6). Маршрутизатор все еще не отвечает, зато отвечает внешний DNS-сервер (пакет 8): сообщает, что не может найти записи <fotn color=darkred>AAAA</font> для сайта linux.format.co.uk. Ну, теперь помаленьку проясняется...

DNS-ресолвер приписывает доменное имя по умолчанию example.com к адресу, который он пытается преобразовать (в результате получаем бессмыслицу www.linuxformat.co.uk.example.com) и начинает поиск записей AAAA для этого адреса. Он тратит еще пять секунд, надеясь получить ответ от маршрутизатора, после чего еще раз пытается обратиться к внешнему серверу DNS (пакет 10). В конце концов занавес над этой печальной историей опускается, и через пятнадцать секунд после начала Konqueror создает соединение TCP/IP (пакеты с 17-го и далее), используя старый добрый адрес IPv4, с которого и начал.

Оказалось, что это известная проблема, как свидетельствуют и результаты поиска Google по фразе “Konqueror IPv6”. Решение простое: отключите стек протоколов IPv6 в ядре, отредактировав файл /etc/modprobe.conf, и перезагрузите систему. Это хороший пример использования отслеживания пакетов для отладки, потому что другим способом решить эту проблему трудно. Не нужно проводить детальный анализ перехваченных пакетов, достаточно просто понять, что компьютер пытается разрешить имя в IPv6.

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