24.2.1. Сеть не работает
24.2.1. Сеть не работает
Причиной отказа сети могут быть физическими или программными. Физические связаны с неработающим сетевым оборудованием или повреждением среды передачи данных. Программные — с неправильной настройкой сетевого интерфейса. Как правило, избавиться от программных проблем помогает конфигуратор сети — вы его еще раз запускаете и правильно настраиваете сетевые интерфейсы. Если вы сомневаетесь в своих действиях, обратитесь за помощью к более опытному коллеге.
Для диагностики работы сети мы используем стандартные сетевые утилиты, которые входят в состав любого дистрибутива Linux. Предположим, что у нас не работает PPPoE/DSL-соединение. Проверить, «поднят» ли сетевой интерфейс, можно с помощью команды ifconfig. Итак, сначала мы предприняли попытку установить соединение командой sudo pon dsl-provider, а затем вызвали ifconfig, чтобы понять, установилось ли соединение (рис. 24.1).
Присутствие интерфейса ppp0 в списке вывода команды ifconfig указывает на то, что соединение установлено. Интерфейс eth0 относится к первой сетевой плате (вторая называется eth1, третья — eth2 и т. д), а интерфейс lo — это интерфейс обратной петли, который используется для тестирования программного обеспечения (у вас он всегда будет «поднят»).
Если же интерфейс ppp0 в списке вывода отсутствует (не «поднят»), следует просмотреть файл /var/log/messages сразу после попытки установки сообщения:
tail — n 10 /var/log/messages
Эта команда просматривает «хвост» файла протокола (выводит последние 10 сообщений). В случае удачной установки соединения сообщения в файле протокола будут примерно следующими:
Feb 6 14:28:33 user-desktop pppd[5176]: Plugin rp-pppoe.so loaded.
Feb 6 14:28:33 user-desktop kernel: [17179852.932000] CSLIP: code copyright 198
9 Regents of the University of California
Feb 6 14:28:33 user-desktop kernel: [17179852.944000] PPP generic driver versio n 2.4.2
Feb 6 14:28:33 user-desktop pppd[5183]: pppd 2.4.4b1 started by root, uid 0
Feb 6 14:28:33 user-desktop pppd[5183]: PPP session is 2838
Feb 6 14:28:33 user-desktop kernel: [17179852.984000] NET: Registered protocol family 24
Feb 6 14:28:33 user-desktop pppd[5183]: Using interface ppp0
Feb 6 14:28:33 user-desktop pppd[5183]: Connect: ppp0 <-> eth0
Feb 6 14:28:33 user-desktop pppd[5183]: Remote message: Login ok
Feb 6 14:28:33 user-desktop pppd[5183]: PAP authentication succeeded
Feb 6 14:28:33 user-desktop pppd[5183]: peer from calling number 00:15:F2:60:28:97 authorized
Feb 6 14:28:33 user-desktop pppd[5183]: local IP address 193.254.218.243
Feb 6 14:28:33 user-desktop pppd[5183]: remote IP address 193.254.218.129
Feb 6 14:28:33 user-desktop pppd[5183]: primary DNS address 193.254.218.1
Feb 6 14:28:33 user-desktop pppd[5183]: secondary DNS address 193.254.218.27
Первая строчка — сообщение о том, что загружен модуль поддержки PPPoE. Следующие два сообщения информируют нас о поддержке нашим компьютером протоколов CSLIP и PPP. Затем сообщается, что демон pppd запущен, от чьего имени он запущен (root) и приводится версия самого pppd. Далее сообщается имя используемого интерфейса (ppp0) и имя вспомогательного интерфейса (помните, что протокол PPPoE подразумевает передачу кадров PPP по Ethernet) — eth0. Следующие два сообщения свидетельствуют об удачной регистрации:
Feb 6 14:28:33 user-desktop pppd[5183]: Remote message: Login ok
Feb 6 14:28:33 user-desktop pppd[5183]: PAP authentication succeeded
Затем система сообщает нам наш IP-адрес, адрес удаленного компьютера, который произвел аутентификацию, а также IP-адреса серверов DNS.
А вот пример неудачной попытки соединения:
Feb 6 09:23:48 user-desktop pppd[6667]: PPP session is 2336
Feb 6 09:23:48 user-desktop pppd[6667]: Using interface ppp1
Feb 6 09:23:48 user-desktop pppd[6667]: Connect: ppp1 <-> eth0
Feb 6 09:23:48 user-desktop pppd[6667]: Remote message: Login incorrect
Feb 6 09:23:48 user-desktop pppd[6667]: Connection terminated.
Причина неудачи понятна — имя пользователя или пароль не приняты, о чем красноречиво свидетельствует сообщение Login incorrect. Чтобы изменить имя пользователя или пароль, можно запустить конфигуратор pppoeconf, однако не стоит с этим спешить — если в предыдущий раз соединение было установлено, и настройки соединения вы не изменяли, возможно, следует обратиться к провайдеру — это явный признак неправильной работы оборудования на его стороне.
Вот еще один пример неправильной работы оборудования провайдера, характерный для PPPoE:
Feb 6 09:23:48 user-desktop pppd[6667]: PPP session is 2336
Feb 6 09:23:48 user-desktop pppd[6667]: Using interface ppp1
Feb 6 09:23:48 user-desktop pppd[6667]: Connect: ppp1 <—> eth0
Feb 6 09:23:48 user-desktop pppd[6667]: Connection terminated.
Возможно, нужно перезагрузить точку доступа (access point), т. е. просто выключить и включить ее. Если это не поможет, обращайтесь к провайдеру.
Наиболее простая ситуация — когда сеть вообще не работает. В этом случае очень легко обнаружить причину неисправности. Если работает устройство, значит, повреждена среда передачи данных (сетевой кабель) — проверьте, нет ли обрыва модемной линии. В случае с витой парой обрыв маловероятен (хотя возможен), поэтому проверьте правильность обжатия кабеля (возможно, придется обжать витую пару заново).
Намного сложнее ситуация, когда сеть то работает, то нет. Например, вы не можете получить доступ к какому-либо узлу, хотя пять минут назад все работало отлично. Если исключить неправильную работу удаленного узла, к которому вы подключаетесь, следует поискать решение в маршруте, по которому пакеты добираются от вашего компьютера до удаленного узла. Сначала пропингуйте удаленный узел командой ping (прервать выполнение команды ping можно с помощью нажатия комбинации клавиш <Ctrl>+<C>):
ping dkws.org.ua
PING dkws.org.ua (213.186.114.75) 56(84) bytes of data.
64 bytes from wdt.org.ru (213.186.114.75): icmp_seq=1 ttl=58 time=30.7 ms
64 bytes from wdt.org.ru (213.186.114.75): icmp_seq=2 ttl=58 time=24.8 ms
64 bytes from wdt.org.ru (213.186.114.75): icmp_seq=5 ttl=58 time=12.2 ms
64 bytes from wdt.org.ru (213.186.114.75): icmp_seq=6 ttl=58 time=159 ms
64 bytes from wdt.org.ru (213.186.114.75): icmp_seq=7 ttl=58 time=19.3 ms
64 bytes from wdt.org.ru (213.186.114.75): icmp_seq=9 ttl=58 time=29.0 ms
…
В этом случае все нормально. Но иногда ответы от удаленного сервера то приходят, то нет. Чтобы узнать, в чем причина (где именно теряются пакеты), нужно выполнить трассировку узла (рис. 24.2):
tracepath dkws.org.ua
Сразу видно, что имеются определенные проблемы с прохождением пакетов до удаленного узла — по пути пакеты теряются. В данном случае пакеты доходят до маршрутизатора dc-m7i-1-ge.interfaces.dc.utel.ua, а после него движение пакетов прекращается. Чтобы выяснить причину, надо обратиться к администратору того маршрутизатора, который не пропускает пакеты, — причина именно в нем.
Примечание
В других дистрибутивах вместо команды tracepath используется команда traceroute, а в Windows — tracert.
Данный текст является ознакомительным фрагментом.