Опубликован: 22.06.2005 | Уровень: для всех | Доступ: платный | ВУЗ: Компания IBM
Лекция 15:

Сетевые и серверные возможности

< Лекция 14 || Лекция 15: 12345 || Лекция 16 >

Автоматическая настройка

Программа-настройщик регулярно предлагала Мефодию "настроить сеть автоматически". В режиме автоматической настройки практически не запрашиваются данные у пользователя. Это значит, что данные система должна брать откуда-то еще, видимо, со специального сервера в локальной сети.

Запрашивать сетевые настройки с сервера вместо того, чтобы хранить их на каждом компьютере, довольно удобно. В самом деле: один сервер, один администратор, один файл с общими настройками. Более того, можно вообще не хранить персональных настроек для каждого компьютера в сети, а ограничиться настройками групповыми – лишь бы IP-адреса внутри группы различались. Одним из первых был разработан протокол RARP (reverse ARP), который, как следует из названия, занимается преобразованием, обратным ARP: по интерфейсному адресу компьютер узнает у сервера сетевой адрес. В Ethernet-сетях для этого посылается широковещательный Ethernet-фрейм типа "RARP-запрос", который означает: "Вот мой MAC-адрес. Кто-нибудь, дайте мне IP!". На что специальная программа-сервер дает RARP-ответ: "Вот тебе IP!" – фреймом, содержащим IP-адрес, который сервер нашел в своей таблице. Если в сети нет ни одного RARP-сервера или ни в одном из них не зарегистрирован интерфейсный адрес компьютера-клиента, тот останется без IP. Похожую схему использует и протокол BOOTP, применяющийся для сетевой загрузки компьютеров. Предполагается, что, получив IP-адрес, клиент заберет с сервера (по протоколу TFTP, trivial FTP) некий файл, загрузит его в память и передаст управление. Поэтому в BOOTP передается не только IP-адрес клиента, но и IP-адреса TFTP-сервера и маршрутизатора по умолчанию и имя файла-загрузчика.

В современных сетях чаще всего используется протокол DHCP ( D ynamic H ost C onfiguration P rotocol, протокол динамической настройки сетевых абонентов). Он имеет очень широкие возможности: с сервера можно получить IP-адрес, сетевую маску и широковещательный адрес, имя домена, адреса маршрутизатора и серверов доменных имен, а также великое множество других параметров, вплоть до не предусмотренных в DHCP явно, так что их тип задается обычным числом, а интерпретация значения целиком определяется клиентом. Урезанную часть DHCP поддерживают "умные" сетевые устройства (те, что снабжены BootROM, т. е. ПЗУ с загрузочной программой). Но полностью обрабатывать все поля DHCP умеет специальный демон-клиент. В Linux этот демон называется dhcpcd (DHCP client daemon). В его ведении находится, как минимум, настройка сетевого интерфейса, маршрута по умолчанию и resolv.conf.

Так что все, что Мефодий делал вручную или вписывал в настроечный файл, можно получить "за просто так", если в сети работает DHCP-сервер:

[root@sakura root]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
. . .
[root@sakura root]# cat /etc/resolv.conf
[root@sakura root]# /sbin/dhcpcd -h sakura -N eth0
dhcpcd.exe: interface eth0 has been configured with new
IP=192.168.102.124
[root@sakura root]# ps gax | grep "dhcpcd"
1011 ? S 0:00 /sbin/dhcpcd -h sakura -N eth0
[root@sakura root]# cat /etc/resolv.conf
nameserver 192.168.102.1
search nipponman.ru
[root@sakura root]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:56:C1:36
inet addr:192.168.102.124 Bcast:192.168.102.255 Mask:255.255.255.0
. . .
Пример 15.9. Использование dhcpcd

Протокол DHCP позволяет передавать серверу желаемое имя и адрес компьютера. Впрочем, выдача IP-адреса привязана, как правило, к MAC-адресу. Здесь есть особая хитрость. DHCP может неплохо работать, когда IP-адресов не хватает на всех: компьютеров с разными MAC-адресами в сети больше, чем выделенных IP, но эти компьютеры никогда не включаются все одновременно. Компьютер, определяемый в DHCP по MAC-адресу, не "присваивает" выданный IP навсегда: адрес сдается в "аренду" (lease) на некоторое время. Если до истечения срока аренды бывший владелец не подтвердил желание пользоваться адресом и дальше (не послал повторный DHCP-запрос), адрес считается незанятым. Но когда компьютер подключается к сети после долгого перерыва, сервер DHCP сначала просматривает "арендную историю" на предмет того, какой IP этому абоненту уже выдавался. Если этот IP не занят, то будет выдан именно он. И только когда к сети подключится совсем новый абонент (а все адреса уже когда-нибудь кому-то выдавались) среди них будет выбран и отдан в аренду новичку тот, что дольше всех оставался невостребованным.

Наконец, чтобы избавиться и от этой ручной работы, можно перенастроить ifcfg-eth0 на использование DHCPD:

[root@sakura root]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
NETMASK=255.255.255.0
ONBOOT=yes
Пример 15.10.. Настройка интерфейса на DHCP по умолчанию

Настройка соединений "точка–точка"

Если компьютер стоит дома, далеко не всегда есть возможность подключиться к локальной сети, непосредственно граничащей с Internet. Для передачи небольших сообщений чаще всего используется временное подключение посредством телефонной линии. На обеих сторонах линии устанавливается модем – устройство, преобразующее один формат сигнала в другой. На российских телефонных линиях обычно используются аналоговые модемы, способные обмениваться данными по довольно низкокачественным линиям с большой долей помех и относительно неискаженной передачей сигнала только в диапазоне слышимых звуковых частот. За низкое качество канала приходится расплачиваться низкой скоростью передачи данных: на таких модемах она до сих пор не превышает (после отбрасывания служебной информации, ошибок и прочего) трех-четырех килобайтов в секунду, а в действительности бывает раза в два меньше.

Соединение между двумя устройствами, вообще говоря, не сетевыми, а только способными передавать данные, описывается несколькими протоколами. Самый распространенный из них – PPP ( P oint-to- P oint P rotocol, протокол "точка–точка") – решает задачи, возникающие в силу особенностей соединений "точка–точка".

Во-первых, само участвующее в соединении устройство почти никогда не бывает представлено в виде сетевого интерфейса, потому что не обладает нужными для организации сети свойствами. Это значит, что какая-то часть системы (скорее всего, демон ) будет разговаривать с устройством на понятном ему языке, а с пользовательскими утилитами взаимодействовать посредством специально организованного виртуального сетевого интерфейса.

Во-вторых, нет необходимости поддерживать часть интерфейсного протокола: на среде передачи данных два абонента , никакой идентификации не требуется, потому что каждый может отличить себя от не-себя. Так, виртуальный сетевой интерфейс ppp0, соответствующий устройству, обменивающемуся данными по протоколу PPP, не обладает MAC-адресом.

В-третьих, оттого, что соединение не постоянное, а среда за время, пока абоненты не были связаны, могла измениться до неузнаваемости, обеим сторонам приходится при каждом дозвоне идентифицировать себя. Обычно идентифицируется только сторона, которой предоставляется доступ в сеть, но проверять, до нужного ли места мы дозвонились, тоже не мешает. При установлении соединения "точка–точка" процедуры идентификации проходят после того, как появляется возможность передавать данные, но до всякой сетевой настройки. Мало того, данные по настройке сети (аналогичные тем, что используются в DHCP) также передаются на этом этапе взаимодействия по протоколу PPP.

В силу того, что дозвон нужен пользователям самого разного уровня знаний, для PPP написано множество программ-"звонилок", использующих графическую подсистему, со звуками и прочими не относящимися к делу украшениями. Пример такой программы – kppp, утилита модемного доступа для рабочего стола KDE. Все, что требуется от пользователя – это указать модем, список телефонов, по которому надо звонить и тип идентификации. Впрочем, и здесь пользователь не освобождается от "тяжелой" мыслительной работы: некоторые провайдеры (организации, предоставляющие выход в Internet) после дозвона требуют идентификацию не по протоколу PPP, а открытым текстом, на манер "login–password" в Linux. Иногда это и есть самый настоящий login: пользователю предоставляется терминальный доступ, а дальше пускай делает, что хочет. В этом случае приходится писать сценарий-диалог (chat script) в стиле "Дождаться строки "login:" – ввести входное имя. Дождаться строки "Password:" – ввести пароль. Дождаться подсказки командного интерпретатора – ввести "pppd" с параметрами".

Что совсем уже просто для пользователя, так это утилита wvdial, описанная в лекции 12. Она и модем сама определяет, и тип идентификации, и pppd настраивает и запускает тоже сама. В действительности же сетью занимается демон pppd, чьи конфигурационные файлы находятся в каталоге /etc/ppp:

[root@sakura root]# ls /etc/ppp
callback-client chap-secrets ip-up options.dialin peers
callback-server ip-down ip-up.d options.dialout
callback-users ip-down.d options pap-secrets
[root@sakura root]# ls -l /etc/ppp/*secrets
-rw------- 1 root root 78 Jun 23 1995 /etc/ppp/chap-secrets
-rw------- 1 root root 77 Jun 23 1995 /etc/ppp/pap-secrets
Пример 15.11. Каталог с настройками PPP

Большинство из этих файлов по умолчанию не используется. Следует помнить, что идентификационная информация, используемая в PPP (в зависимости от особенностей соединения и пристрастий провайдера могут применяться протоколы идентификации PAP или CHAP), хранится в файлах pap-secrets и chap-secrets в текстовом виде. Хранить не пароль, а ключ, как это сделано в /etc/shadow, нельзя, так что остается либо надеяться на права доступа к этим файлам, либо запускать pppd вручную (или с помощью тех же wvdial и kppp ) и каждый раз этот пароль вводить.

Установить PPP-соединение можно поверх любой среды передачи данных, в том числе и поверх локальной сети. В этом случае pppd обменивается данными (посредством псевдотерминальной пары pty – tty или ptmx – pts/, описанной в лекции 11) с демоном pppoe, который играет роль "модема". При этом передаваемые данные можно сжимать или шифровать, а главное, связь "точка–точка" устанавливается с конкретным пользователем, который ввел одному ему известный пароль, поэтому часто выход в Internet, требующий строгого учета трафика, осуществляется именно с помощью пары pppd/pppoe. Наконец, в сети может быть настоящий модем, преобразующий эти данные в формат, пригодный для передачи по цифровым телефонным линиям (DSL). Кстати сказать, такой модем легко собирается из маленького компьютера с низким энергопотреблением, ядра Linux и доработанного стартового виртуального диска. Некоторые современные DSL-модемы устроены именно так, причем ядро и initrd записываются в перепрограммируемое ПЗУ.

< Лекция 14 || Лекция 15: 12345 || Лекция 16 >
Аягоз Имансакипова
Аягоз Имансакипова
Тимур Булатов
Тимур Булатов

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

Гузель Фахретдинова
Гузель Фахретдинова
Россия
Алексей Маряскин
Алексей Маряскин
Россия