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

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

192

Глава б. Настройка интерфейса

pppd поддерживает два протокола проверки подлинности: протокол аутенти-

фикации с предварительным согласованием вызова CHAP (Challenge Hand-

shake Authentication Protocol) и протокол аутентификации пароля PAP

(Password Authentication Protocol). PAP - это простая система парольной без-

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

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

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

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

В процессе проверки подлинности используются два файла: /etc/ррр/chap-

secrets и /etc/ррр/рар-secrets. Приведенные выше параметры предписывают

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

средством CHAP. Такая проверка требует присутствия определенной инфор-

мации в файле chap-secrets, и удаленная система должна ответить на вызов

CHAP. Если не выполнено хотя бы одно из условий, pppd пытается иденти-

фицировать удаленную систему посредством РАР. Если отсутствует подхо-

дящая запись в файле pap-secrets, либо удаленная система не ответила на

вызов РАР, попытка установить соединение РРР заканчивается неудачей.

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

систем посредством CHAP (предпочтительного протокола), если возможно,

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

вающих только РАР. Однако чтобы этот механизм заработал, необходимо

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

Каждая запись файла chap-secrets содержит до четырех полей:

клиент

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

ра, для которого необходимо произвести аутентификацию перед создани-

ем соединения. Речь не обязательно идет о клиенте, обращающемся к сер-

веру РРР: в большинстве документов используется термин клиент, хотя

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

Обе стороны канала РРР могут принудительно проходить проверку под-

линности. В вашем файле chap-secrets, вероятно, будет по две записи на

каждую удаленную систему: одна запись для аутентификации этой систе-

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

этой системы.

сервер

Имя системы, от которой исходит вызов CHAP, то есть компьютера, кото-

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

ния РРР. Речь не обязательно идет о сервере РРР. Система-клиент вполне

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

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

система, проверяющая допустимость ответа.

секрет

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

ме, от которой исходил вызов.

Установка РРР

193

Здесь снова пара записей: одна для удаленной и одна для локальной систе-

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

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

рона запросит данные идентификации.

Аутентификация РРР повышает уровень безопасности при работе по комму-

тируемым соединениям. Наибольшую актуальность она приобретает для

серверов РРР, обслуживающих удаленные системы. В следующем разделе

мы рассмотрим настройку сервера РРР.

Настройка сервера РРР

Сервер РРР может запускаться рядом способов. Первый способ - использо-

вать pppd в качестве оболочки, вызываемой при регистрации пользователей,

подключающихся по РРР. Замените имя командного интерпретатора в фай-

ле /etc/passwd полным именем pppd, чтобы запустить сервер. Измененная за-

пись /etc/passwd может выглядеть так:

craig:wJxX.iPuPzg:101:100:Craig Hunt:/etc/ppp:/usr/sbin/pppd

Первая запись используется для проверки узла limulus удаленного сервера

РРР. Проверяется подлинность узла limulus, проверка выполняется системой

ring. Секретный ключ представлен строкой «Peopledon'tknowyou». Допусти-

мый адрес - 172.16.15.3, то есть адрес, назначенный системе limulus в табли-

це узлов. Вторая запись позволяет проверить узел ring, когда вызов исходит

от системы limulus. Секретный ключ - «andtrustisajoke.». Узлу ring разреше-

но использовать только адрес 172.16.15.1. Пара записей, по одной на каждую

сторону канала, - нормальное явление. Файл chap-secret обычно содержит две

записи на каждый канал РРР: одну для проверки подлинности удаленной сис-

темы, и вторую - для ответов на вызовы, исходящие от удаленной системы.

Используйте РАР только по необходимости. Если речь идет о системе, не

поддерживающей CHAP, создайте для этой системы запись в файле pap-sec-

rets. Формат записей файла pap-secrets точно такой же, как формат записей

chap-secrets. Система, не работающая с CHAP, может хранить следующие

записи в файле pap-secrets:

адрес

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

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

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

правильно зашифровал ответ на вызов. Данное поле является необяза-

тельным.

Файл chap-secrets узла ring может иметь следующий вид:

194 Глава б. Настройка интерфейса

Понятно, такой сценарий может содержать несколько команд. Команда mesg

-п

запрещает другим пользователям передавать данные на этот терминал по-

средством программ talk, write или других подобных. Команда stty отклю-

чает эхо-контроль символов. В некоторых системах символы, набираемые

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

кальном терминале. Такой режим называется полным дуплексом. В нем нет

необходимости в случае канала РРР, так что мы его отключаем. Управление

характеристиками физического канала - основная причина размещения ко-

манды pppd в отдельном файле сценария.

Ключевая строка сценария, разумеется, та, что содержит вызов

pppd.

Демон

запускается с рядом параметров, но одного параметра здесь не хватает,

а именно имени устройства терминала. Во всех предшествующих примерах

это имя присутствовало в строке команды

pppd.

Если имя отсутствует, как в

этом случае, pppd использует в качестве такого устройства управляющий

терминал и не переходит в фоновый режим работы. Именно это нам нужно.

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

мандой

когда она вызвала сценарий ppplogin.

Параметр командной строки auth предписывает pppd выполнять аутентифи-

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

этой системы в файле chap-secrets или pap-secrets. Параметр crtscts включа-

Здесь все поля соответствуют стандартной записи файла /etc/passwd: имя

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

пы, код gcos, исходный каталог, оболочка (интерпретатор команд), вызыва-

емая после регистрации. Исходным каталогом для внешнего пользователя

РРР является /etc/ррр, а в поле оболочки содержится полное имя програм-

мы

pppd.

Зашифрованный пароль должен быть указан при помощи програм-

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

ции в системе ничем не отличается от стандартного. Обнаружив данные, по-

ступающие через последовательный порт, getty выполняет login в целях

аутентификации пользователя, login проверяет введенное пользователем

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

терпретатора запускается демон РРР.

При таком способе запуска сервера параметры настройки, как правило, раз-

мещаются в файле /etc/ррр/.ррргс. login проверяет подлинность пользовате-

ля, a pppd выполняет аутентификацию клиента. Поэтому нужно настроить

файл chap-secrets или pap-secrets для работы с теми системами, из которых

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

Традиционной альтернативой запуску pppd посредством login является соз-

дание сценария, в котором pppd - лишь одна из команд. Например, можно

создать сценарий /etc/ppp/ppplogin следующего содержания:

Установка РРР

195

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

слеживать состояние индикатора DCD модема, чтобы вовремя обнаружить

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

нее.

Но один из параметров, passive, нам не знаком. Параметр passive пред-

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

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

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

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

мя на инициализацию собственного демона РРР.

Наконец, есть еще один вариант запуска сервера РРР - разрешить пользова-

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

целью демон pppd должен выполняться с полномочиями пользователя root

(по умолчанию не так). В таком случае пользователь, вошедший в систему

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

$ pppd proxyarp

которая запустит демон РРР. Если параметр auth существует в файле /etc/

ррр/options, то pppd выполняет аутентификацию удаленного клиента посред-

ством CHAP или РАР. Когда подлинность,клиента установлена, демон соз-

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

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

равноправного узла.

Из этих трех подходов я предпочитаю создание сценария, вызываемого про-

граммой login в качестве интерпретатора команд пользователя. Это избавля-

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

запуск сервера на пользователя. При этом доступна вся мощь команды pppd

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

РРР в Solaris

dip и pppd существуют для Linux, BSD, AIX, Ultrix, OSF/1 и SunOS. Работая с

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

ми. Хорошим примером системы, в которой для настройки РРР применяет-

ся иной набор команд, является Solaris.

Протокол РРР в Solaris реализован демоном aspppd (Asynchronous РРР Da-

emon). Настройки aspppd хранятся в файле /etc/asppp.cf. Файл asppp.cf состо-

ит из двух разделов: раздела ifconfig и раздела path.

Команда ifconfig производит настройку интерфейса РРР (ipdptpO) как кана-

ла точка-точка с локальным адресом узла ring и конечным адресом узла li

mulus. В команде ifconfig не обязательно указывать конечный адрес канала.

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

196

Глава 6. Настройка интерфейса

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

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

Больший интерес представляет раздел

path,

определяющий характеристики

среды РРР. Оператор interface указывает интерфейс, служащий для созда-

ния соединений. Здесь требуется указать один из интерфейсов РРР, опреде-

ленных в разделе ifconfig. В нашем примере определен только один интер-

фейс -

ipdptpO.

Оператор peer_system_name определяет систему, выступающую

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

ратора ifconfig, но это не обязательно. Конечный адрес в команде ifconfig

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

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

ла из оператора peer_system_name используется в процессе подключения.

Раздел path завершается оператором inactivity_timeout. Команда примера

устанавливает интервал ожидания в 300 секунд. Одно из достоинств систе-

мы Solaris в действии. Solaris автоматически подключается к удаленной сис-

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

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

канала в течение указанного интервала времени. Такой механизм избавляет

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

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

Подобно

pppd,

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

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

UUCP следующим образом.

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

определяются в файле /etc/ииср/Devices. Например, ниже мы создаем автома-

тическое вызывающее устройство (Automatic Call Unit, ACU - всего лишь

другое название модема), подключенное к последовательному порту В (cua/b),

работающему на любой скорости из указанных в файле Systems. Характе-

ристики модема определяются записью «hayes» в файле Dialers.

Файлы Devices и Dialers уже существуют в стандартной установке системы.

Существующие записи, вероятно, совместимы с модемом вашей системы.

Правка настроек в таком случае может ограничиваться лишь файлом /etc/

ииср/Systems. В файле Systems необходимо указать имя удаленной систе-

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

chat,

выполняющий регистрацию. Например:

Затем мы определяем характеристики модема, такие как строка инициали

зации и команда набора, в файле /etc/ииср/Dialers. Команды инициализа

ции и набора определяются в качестве chat-еценария по стандартной схем

ожидания/передачи и посредством стандартного набора специальных сим

волов

chat.

Например:

Установка РРР

197

В единственной строке мы указываем limulus в качестве удаленной системы,

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

нала в любое время суток (Any), выбираем запись ACU из файла Devices,

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

чение 56700, передаем программе набора номера телефонный номер, а так-

же определяем регистрационный сценарий chat.

Поскольку эта книга посвящена совсем не UUCP, мы не будем вдаваться в де-

тали этих файлов. В поисках более подробной информации по UUCP и aspppd

предлагаю обращаться к книгам Solaris AnswerBook и Solaris TCP/IP Net-

work Administration Guide (Администрирование сетей TCP/IP Solaris - как

им удалось придумать такое классное имя?).

Диагностирование последовательных соединений

Отладка соединений РРР затруднена проблемами, возникающими на не-

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

порта, модема, настройки РРР и TCP/IP. Ошибка на любом из уровней мо-

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

тинную причину проблемы. Лучший способ диагностирования проблем для

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

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

ладки предыдущего.

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

процессе загрузки. Проверьте корректность настроек, обратившись к ката-

логу /dev. Для системы Linux с четырьмя последовательными портами

должны существовать входящие последовательные порты с /dev/ttySO по

/dev/ttyS3 и исходящие последовательные порты с /dev/сиаО по /dev/сиаЗ.

Имен устройств tty и сиа существует гораздо больше. Однако прочие устрой-

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

теме многопортовой последовательной карты. В большинстве систем ис-

пользуются имена tty и сиа, даже если эти имена являются всего лишь сим-

волическими ссылками на реальные устройства. Например, в Solaris:

Если последовательные устройства не обнаружены в каталоге /dev, их мож-

но добавить вручную при помощи команды mknod. Так, следующая команда

создает последовательные устройства для первого последовательного порта

системы Linux:

198

Глава б. Настройка интерфейса

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

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

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

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

наружение одного последовательного интерфейса в системе Linux:

При загрузке системы должны наблюдаться аналогичные сообщения для

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

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

Модем, позволяющий установить соединение, подключается к одному из по-

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

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

ный порт. Воспользуйтесь простым коммуникационным пакетом, таким

как

minicom,

kermit или

seyon.

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

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

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

ма, чтобы определить эти значения.

Для создания примеров мы используем minicom и систему Linux. Чтобы на-

строить minicom, станьте суперпользователем при помощи команды su и вы-

полните minicom с ключом

-s,

предписывающим вывод меню настройки. По

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

ние порта в настройках - /dev/modem. Это имя устройства иногда является

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

ете, существует ли такая ссылка в системе, введите в этом поле корректное

имя устройства, например /dev/cual. Убедившись в точности настроек, по-

киньте меню и воспользуйтесь эмулятором терминала

minicom,

чтобы прове-

рить работоспособность модема:

Установка РРР

199

В этом примере minicom выводит несколько строк заголовка, а затем посыла-

ет модему Науеэ-команду (AT). Мы ее не вводили, это часть стандартной на-

стройки программы minicom. (Если выполнение команды вызывает пробле-

мы, удалите ее при помощи вышепомянутого меню настройки.) Затем мы

выполняем аппаратную инициализацию модема (atz) и набираем номер уда-

ленного сервера (atdt). Когда модемы установили соединение, регистриру-

емся на сервере и настраиваем его. (Процедура регистрации своя для каждо-

го удаленного сервера, это просто пример.) Похоже, что все замечательно ра-

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

(+++) и вешаем трубку

(ath),

а затем заново инициализируем модем. Работа с

minicom завершается нажатием <Ctrl>+<A> и затем <Х>. Порт и модем на-

шей системы отлично работают. Если вы не можете передать модему даже

простую команду, проверьте, что:

• модем правильно подключен к порту;

• использованы нужные кабели;

• модем включен в сеть питания;

• модем корректно настроен на исходящие звонки и эхо-отображение ко-

манд.

Если модем реагирует на простые команды, наберите номер удаленного сер-

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

ся набирать номер либо отображает сообщение NO DIALTONE, убедитесь,

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

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

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

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

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

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

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

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

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

вод своего модема и удаленного сервера. Затем переведите удаленный сервер

в режим РРР или SLIP и запишите, как этого удалось добиться. Все эти ша-

ги необходимо будет воспроизвести в сценарии dip.

Начните с примитивного сценария, похожего на start-ppp.dip, чтобы иметь

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

200

Глава б. Настройка интерфейса

наращивать сложность сценария, добавляя обработку ошибок. Выполните

сценарий посредством dip с ключом подробной диагностики (-v). Строки сце-

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

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

• Модем не реагирует на команды сценария. Убедитесь, что в команде port

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

манд databits, parity, speed и stopbits, если таковые присутствуют в сце-

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

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

настройка модема выполняется при помощи ключевых слов dip, а не ко-

манды send.

• Модем не может соединиться с удаленным узлом. Убедитесь, что настрой-

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

ную. Параметры модема, такие как databits и

parity,

должны соответство-

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

ции в удаленной системе требуется временное переключение на сочетание

7-бит/контроль четности. После регистрации следует переключиться об-

ратно на сочетание 8-бит/без контроля, которое требуется для работы РРР

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

манде набора, особенно если модем выводит строки VOICE, RING - NO

ANSWER либо BUSY вместо ожидаемого CONNECT.

• Сценарий зависает. Вероятно, он находится в ожидании ответа. Убеди-

тесь, что корректны строки команд

wait.

Помните, что в качестве ожидае-

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

вать строку «>», чем

«Port9>»,

в случае, когда вы не уверены в номере пор-

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

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

дачу данных прежде, чем будет готов к приему сервер. Кроме того, про-

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

мандой серверу: к примеру, sleep 2, чтобы создать двухсекундную за-

держку. Задержка бывает необходима, чтобы сервер успел инициализи-

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

• Удаленный сервер отображает сообщение об ошибке. Вероятно, сценарий

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

Убедитесь, что они завершаются именно той комбинацией символов воз-

врата каретки и новой строки, которая ожидается сервером.

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

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

за другой. Повторяйте процедуру до тех пор, пока не получите четкой после-

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

ре. Затем возвращайтесь к отладке сценария. Скорее всего, свежий взгляд

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

Когда сценарий запущен, а соединение успешно установлено, ничто не

должно препятствовать нормальной работе. Удаленный сервер должен отве-

чать на команду

ping.

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

Резюме 201

стройке IP-интерфейса или неверном маршруте по умолчанию. Сценарий

должен создать последовательный интерфейс. Команда netstat -ni выводит

статистику по уже настроенным интерфейсам:

О содержимом таблиц маршрутизации мы подробно поговорим в следующей

главе. Пока просто обратите внимание, что маршрут по умолчанию прохо-

дит через интерфейс

рррО

и что маршрут по умолчанию является маршрутом

к удаленному серверу РРР (в данном случае - 172.16.25.3).

Если сценарий создал соединение, установил интерфейс, и таблица маршру-

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

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

подсистемами TCP/IP. В главе 13 подробно описан процесс диагностирова-

ния и отладки.

Резюме

TCP/IP работает с широким спектром физических сетей. Протоколы TCP/IP

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

терфейсы и их характеристики. В этой главе мы рассмотрели ряд примеров,

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

тает TCP/IP.

Чаще всего для настройки интерфейсов применяется команда ifconfig. Она

назначает интерфейсу IP-адрес, устанавливает маску подсети, широковеща-

тельный адрес, а также выполняет ряд других функций.

TCP/IP может работать и по коммутируемым телефонным каналам. Задача

решается при помощи протоколов Serial Line IP (SLIP) и Point-to-Point Pro-

tocol (РРР). Предпочтительным вариантом является РРР - стандартный

протокол Internet, обладающий повышенной надежностью, производитель-

ностью и безопасностью.

Интерфейс, в данном случае -

рррО,

установлен. Команда сценария default

создает маршрут по умолчанию. Воспользуйтесь netstat для просмотра со-

держимого таблицы маршрутизации: