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

 

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

Протокол PPP
Протокол PPP (Point-to-Point Protocol) был разработан для связи по последовательным каналам, таким как коммутируемые телефонные каналы, соединения через последовательные порты и т.д. С помощью протокола PPP можно установить канал связи и передавать по нему пакеты любых протоколов - TCP/IP, IPX/SPX, NetBIOS. Нас в приложении к UNIX интересует настройка работы с TCP/IP поверх PPP.
Протокол PPP предполагает возможность выполнения следующих операций:

  • установление связи;
  • согласование параметров передачи (скорость, четность и т.п.);
  • согласование параметров сетевого интерфейса (IP-адрес, маска, адрес сервера имен и пр.);
  • передача пакетов между интерфейсами;
  • разрыв связи.

Для установления связи может потребоваться аутентификация, поэтому программы, работающие с PPP, должны уметь запрашивать и передавать аутентификационную информацию (имя и пароль, в некоторых случаях - зашифрованные).
Подробная документация по настройке PPP в Solaris 9 содержится, в частности, в документе "Solaris 9 System Administrator Collection System Administration Guide: Resource Management and Network Services" по адресу http://docs.sun.com/db/doc/806-4076?q=ppp, а обзор PPP в Solaris 9 имеется по адресу http://docs.sun.com/db/doc/806-4076/6jd6amr63?q=ppp&a=view.
Программа aspppd
В системах Solaris, начиная с Solaris 2.4 и до Solaris 8 включительно, для обеспечения связи по протоколу PPP использовалась утилита aspppd, вызывавшая нарекания из-за сложности настройки и использования. В Solaris 9 она заменена на более стандартную и удобную программу pppd, которая может служить как сервером, так и клиентом PPP . Для настройки aspppd в более старых системах Solaris следует обратиться к FAQ на эту тему. Например, можно найти одно из них по адресу http://solaris.opennet.ru/docs/RUS/solaris_x86/index.html.
Программа pppd
Сейчас для установления соединений через PPP в UNIX-системах используют сервер pppd , причем он есть в поставке как новых коммерческих, так и некоммерческих вариантов UNIX.
Программа pppd может работать в качестве сервера удаленнго доступа , т.е. принимать входящие звонки, а может выполнять роль клиента, дозваниваясь до сервера удаленного доступа .
При соединении двух компьютеров по протоколу PPP каждый из них рассматривается как равноправный участник соединения. Любой участник может предъявить к соединению свои требования: запросить определенный IP-адрес для себя или другого участника, потребовать аутентификацию и т.д. Если второй участник соглашается с требованием или его собственные требования не противоречат запрошенным, соединение устанавливается. Если требования участников противоречивы, то соединение не устанавливается.
Настройки программы pppd находятся в каталоге /etc/ppp. Основной файл настроек pppd - это /etc/ppp/options.
Синтаксис вызова pppd:
pppd параметры
Параметры должны включать имя_устройства и скорость.
Имя устройства последовательного порта
В Solaris, как и в некоторых других системах UNIX, файл устройства, используемый для приема соединения через последовательный порт, и файл устройства, используемый для инициирования такого соединения, - это два разных файла. Входящие соединения принимаются устройствами /dev/ttyd*, а исходящие создаются через /dev/cua*. Имя устройства, например, для входящих соединений через COM2 будет /dev/ttyd1 (ttyd0 - COM1, ttyd1 - COM2), а для исходящих через COM2 - /dev/cua1.
Если вы настраиваете сервер удаленного доступа , надо заранее записать в конфигурацию модема (т.е. в NVRAM самого модема) значения S0=1 и S1=1 для того, чтобы модем снимал трубку с первого звонка.
Для непосредственного общения с модемом удобно использовать простейшую терминальную программу cu:
cu -l /dev/cua1
Если никакая программа не общается с /dev/cua1 в данный момент, то cu подключится к порту COM2. Теперь можно набирать команды модема: все, что будет набрано, попадет в последовательный порт. Для выхода из cu надо набрать ~. (тильда, затем точка) и подождать немного. Программа cu не умеет мгновенно отсоединяться.
По умолчанию, обращаться к устройствам напрямую с помощью cu может только root. Это соглашение можно изменить, установив нестандартные права доступа к файлам устройств /dev/cua* и /dev/ttyd*·.
Параметры pppd удобно записать в файл /etc/ppp/options. Если все PPP-сессии на сервере будут однотипными (одна скорость, соединение через один и тот же модем, звонки всегда только входящие), в этот файл можно записать все параметры pppd. Саму программу pppd можно прописать в качестве командного процессора по умолчанию в /etc/passwd всем, кто использует этот сервер как сервер удаленного доступа :
cat /etc/ppp/options
/dev/cuaa0                                           # устройство
57600                                         # скорость
crtscts                                      # управл. сигн. RTS/CTS
modem                                                # модем, использовать DTR
debug                                                # протоколирование сессии
passive                                       # устанавливать соед. и ждать *
dns1 193.114.38.65                            # установить DNS
193.114.38.5:193.114.38.4                  #назначить адреса local:dialup **
-detach                                       # не уходить в background
lock                                                 # блокировка порта по типу UUCP
Параметр debug включает протоколирование сессии. Программа pppd расценит этот параметр как требование записывать с использованием механизма syslog() все управляющие входящие и исходящие пакеты в удобочитаемой форме. Запись происходит от имени источника daemon с уровнем debug. Подробнее об источниках и уровнях записей в syslogd см. лекцию 16.
Параметр modem указывает, что нужно использовать сигналы управления модемом. Программа pppd ждет сигнала CD (carrier detect) от модема, если только не указан connect-script, и "передергивает" (коротко выключает, затем включает) сигнал DTR (dara terminal ready) как только соединение завершается и перед тем, как запустить connect-script.
Если нужно установить индивидуальные настройки pppd для каждого пользователя, то в домашние каталоги пользователей нужно положить файлы .pppr, которые будут прочитаны демоном pppd после /etc/ppp/options и могут содержать дополнительные сведения для него.
Выдача динамических адресов клиентам PPP ("динамических" в том смысле, что клиент не знает заранее, какой адрес он получит) выполняется путем создания файлов с именами типа /etc/ppp/options.ttyd1.
В каждом таком файле можно указать конкретный адрес удаленного клиента, и тот будет получать разные адреса при соединении с разными последовательными портами сервера. В то же время, каждому порту сервера и его удаленному клиенту на этом порту при такой настройке всегда будет соответствовать фиксированная пара адресов, жестко определенная для каждого последовательного порта сервера.
Кроме этого, можно вообще ничего не писать в /etc/ppp/options про назначение адресов. По умолчанию всем позвонившим на сервер удаленного доступа pppd выдаст адрес ethernet-интерфейса этого сервера. Отличать разных клиентов он будет не по IP-адресу, а по имени создающегося при соединении через PPP интерфейса - ppp0, ppp1 и т.д.
Приведенный пример предполагает, что при дозвоне на сервер удаленного доступа не используется стандартный протокол аутентификации в Windows-системах, так называемый PAP (password authentication protocol). В данном примере предполагалось, что пользователи применяют конфигурацию generic login из Windows XP или вводят имя и пароль вручную открытым текстом.
Если требуется настроить аутентификацию с использованием PAP и при этом использовать для аутентификации файл /etc/passwd, нужно записать в файл /etc/ppp/options параметр login. При этом пользователь, который соединяется с сервером удаленного доступа посредством PAP, должен иметь учетную запись и в /etc/passwd, и в /etc/ppp/pap-secrets. Формат записей в последнем таков:
имя_клиента имя_сервера пароль IP-адрес
В каждом из полей может стоять *, обозначающая допустимость любого значения. Как правило, строка аутентификации в pap-secrets выглядит так:
klara * KqZXV5-u *
Эта строка определяет имя и пароль пользователя klara, которому разрешено соединяться с данным сервером.
В некоторых версиях pppd при установленном параметре login программа в начале аутентификации полагает, что ей должен быть передан пароль, записанный открытым текстом в /etc/ppp/pap-secrets.
Если это так и есть, то любой, прочтя этот файл, сможет ввести в строку пароля именно то, что записано в этом файле, и будет аутентифицирован. Естественно, хранить незашифрованные пароли в /etc/ppp/pap-secrets небезопасно, поэтому там следует хранить зашифрованный пароль.
Чтобы объяснить программе pppd, что пароль в /etc/ppp/pap-secrets зашифрован, следует использовать параметр papcrypt при вызове pppd или указать его в файле /etc/ppp/options.
Есть, таким образом, две схемы организации сервера удаленного доступа :

  1. Пользователь дозванивается на модем сервера, где его встречает программа ttymon (стандартная программа, обслуживающая вход на любой терминал, кроме псевдотерминала). Она спрашивает его login и password, которые пользователь сообщает вручную или с использованием скрипта на своей машине. Затем, уже после входа в систему, для пользователя запускается pppd, указанный в качестве командного процессора для этого пользователя в /etc/passwd.
  2. При запуске системы вместо ttymon, запускается pppd на том последовательном порту, где находится модем, и pppd ждет входящего звонка. Когда кто-то дозванивается, pppd сам проводит аутентификацию с использованием /etc/ppp/pap-secrets.

Запуск ttymon для определенных терминалов контролируется в /etc/inittab в системах System V, включая Solaris. Старые версии Solaris и большинство других операционных систем используют программу getty вместо ttymon, в новых версиях Solaris программа getty также может быть вызвана, поскольку файл getty здесь представляет собой символическую ссылку на ttymon.
Файл /etc/ppp/pap-secrets может содержать как строки для аутентификации удаленных клиентов, так и строки, которые соответствуют аутентификации самого pppd на сервере удаленного провайдера. Имя пользователя, которое pppd будет использовать для того, чтобы идентифицировать самого себя, задается параметром user.


Настройка клиента удаленного доступа
При настройке клиента удаленного доступа нужно добавить несколько строк в файл параметров, чтобы заставить pppd посылать удаленному серверу провайдера имя и пароль по запросу.
Если мы звоним на сервер удаленного доступа , организованный по типу 1, то options может, например, выглядеть так:
/dev/cuaa0
57600
crtscts
modem
debug
defaultroute
passive
-detach
lock
connect "chat -f /etc/ppp/chat.x"
Файл /etc/ppp/chat.x при этом может быть, например, таким:
'' ATDT3200000 CONNECT \r name:-BREAK-name: pppfil
ssword: e.67FGq1
Здесь в скрипте соединения указан номер телефона (3258752), по которому мы дозваниваемся. Это - телефон провайдера или сервера удаленного доступа в нашей организации (можно использовать PPP-соединения как для подключения к Интернету, так и для соединения двух площадок одной компании между собой). Помните, что команда ATDT означает тоновый набор, для набора в импульсном режиме, который обычно используется на городских АТС в России, следует применить команду ATDP. В данном примере предполагается, что имя пользователя для соединения с удаленным сервером - pppfil, а пароль (незашифрованный) - e.67FGq1.
Если сервер, на который мы звоним, организован по типу 2, то файл options выглядит примерно так:
/dev/cuaa0
57600
crtscts
modem
debug
defaultroute
passive
-detach
lock
user myname
Поскольку здесь мы явным образом указываем имя пользователя, которое следует использовать для аутентификации на удаленном сервере, в файле /etc/ppp/pap-secrets на нашем компьютере (который звонит удаленному серверу) должна быть строка
myname * mypassword *
Если соединение с удаленной системой должно быть постоянным (например, нам нужно постоянное соединение с провайдером по модему), можно написать простой скрипт, который будет запускать pppd снова, если он почему-то завершится:
#!/bin/sh
while sleep 3
do
/usr/sbin/pppd
done
"Засыпание" на три секунды нужно на всякий случай. Чтобы дать проблеме, из-за которой завершился pppd, время на то, чтобы самоустраниться. Цикл бесконечный, прервать его можно только посылкой сигнала KILL. Такой цикл удобно оформить в виде скрипта, запускающегося при старте системы.
Вместо такого "вечного" цикла можно воспользоваться параметром demand. Он запускает дозвонку pppd в случае прихода пакета, который нужно отправить по dial-up каналу.
Кроме того, надо помнить о возможности запускать pppd из файла /etc/inittab, указав тип запуска respawn (запустить заново в случае завершения). Следует выбрать только один из рассмотренных способов поддержания постоянного соединения с помощью pppd - одновременно их использовать не рекомендуется во избежание путаницы и запуска "лишних" копий программы.

Настройка syslogd
Демон syslogd (файл конфигурации /etc/syslog.conf) протоколирует события, информацию о которых ему поставляют другие процессы, вызывая функцию syslogd (). В файле /etc/syslog.conf определяется, какие события нужно протоколировать и как.
Синтаксис записи в /etc/syslog.conf таков:
источник.уровень               действие
Источник - это условное название процесса или группы процессов, которые могут генерировать сообщения о событиях. Уровень - это степень серьезности сообщения (ошибка, фатальный сбой, предупреждение, информационное сообщение и т.п.). Источник в оригинальной документации называется facility , в переводной литературе используют понятие "средство". Однако мы будем использовать термин "источник ", так как речь идет именно об источнике сообщений. Два этих поля (источник.уровень и действие) отделяются друг от друга табуляцией.
Общими для большинства систем UNIX являются источники , перечисленные в табл. 16.1. Полный перечень источников и уровней для вашей системы приведен в man syslog.conf.


Таблица 16.1. источники сообщений suslogd

Источник

Программы, которые по умолчанию генерируют сообщения от имени этого источника в Solaris 9

user

сообщения от пользовательских процессов

kern

ядро

mail

почтовые программы

daemon

демоны, например, in.ftpd

auth

login, su, getty и другие, связанные с аутентификацией

lpr

подсистема печати, в т.ч. lpr, lpc

news

зарезервировано для программ телеконференций типа inn

cron

cron, crontab, at (в настоящее время в Solaris не используется)

local0-local7

зарезервировано для других программ

mark

специальный источник для добавления меток времени в файл протокола демоном syslogd

Если в поле источника стоит знак "звездочка"(*), например *.info, это означает все события всех источников уровня info, за исключением событий источника mark.
Уровень сообщения соответствует степени его серьезности, в таблице 16.2 уровни расположены в порядке убывания серьезности:


Таблица 16.2. Уровни протоколирования syslogd

Уровень

Чему соответствуют

emerg

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

alert

Нехорошее состояние; надо срочно исправлять положение, иначе быть беде, например, испортился важный системный файл

crit

Сообщение о критической ошибке, например сбоит жесткий диск

err

Прочие ошибочные состояния

warning

Предупреждение (например, место на диске заканчивается, но дело еще не пахнет керосином)

notice

Предупреждение о какой-то проблеме, это не рассматривается как ошибка

info

Информационное сообщение - так, чтобы мы были в курсе дел

debug

Сообщение при отладке программы (или её файла конфигурации)

none

Требование не выполнять действий в отношении сообщений от указанного источника ; например, *.debug;mail.none означает, "выполнить действие в отношении всех сообщений уровня debug, кроме сообщений от источника mail:"

Если в поле уровня стоит знак "звездочка" (*), например, mail. *, это означает события всех уровней данного источника . Такое указание не имеет смысла, поскольку при указании некоего уровня разрешается передача всех сообщений этого уровня и более серьезных, т.е. уровень info фактически означает "info и все остальные".
С сообщением могут быть выполнены следующие действия:

  • запись информации о событии в файл;
  • пересылка сообщения другому компьютеру (демону syslogd на нем);
  • отправка сообщения по почте;
  • вывод сообщения на экран вошедшим в систему пользователям.

Обычно информация записывается в файл. Принято файлы протоколов держать в /var/log или /var/adm. Имя файла, записанное в поле "действие", приводит к записи информации в этот файл.
Для активации изменений, внесенных в файл конфигурации /etc/syslog.conf, требуется послать сигнал HUP демону syslogd. За размером файлов протокола надо следить, иначе они займут все свободное место на разделе. Уровень протоколирования следует выбирать из соображений разумной достаточности. Незачем протоколировать все события с уровнем info или notice: если сервер уже настроен, вполне достаточно протоколировать события большинства источников с уровнем error.
Указанный в строке /etc/syslog.conf уровень - это минимальный уровень, который должно иметь событие, чтобы быть занесенным в протокол. Стало быть, если вы указали уровень событий info, то все более серьезные уровни (warning, error и т.д.) тоже будут отвечать этой же строке syslog.conf и события будут записаны туда же, куда и сообщения о событиях уровня info.
Пример минимального файла syslog.conf:
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                              /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none                       /var/log/messages
# The authpriv file has restricted access.
auth.*                                               /var/log/secure
# Log all the mail messages in one place.
mail.*                                               /var/log/maillog
# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg                                              *
# Save mail and news errors of level err and higher in a
# special file.
mail,news.crit                        /var/log/spooler
#All Other
#*.*                                                         /var/log/all
Файлы протоколов
В Solaris администраторы часто находят полезным собирать в следующие файлы сообщения по уровням и источникам :

  • /var/log/notice - протоколирование всех сообщений почтовой подсистемы, кроме отладочных сообщений уровня debug) и всех сообщений уровня notice и выше (представляете, как их там много?);
  • /var/log/critical - все сообщения о критических ошибках (уровня crit и выше), это может быть полезно для последующего анализа происходившего в системе перед серьезным сбоем;
  • /var/log/auth - все сообщения подсистемы аутентификации (уровня warining и выше) - для своевременного обнаружения вторжения в систему или попыток такого вторжения.

Использование файлов протоколов
Файлы протокола можно использовать как для анализа уже произошедших событий, так и для мониторинга. Последнее предпочтительнее: внимательный анализ файлов протоколов помогает понять происходящее в системе и вовремя предупредить сбой.
Особого внимания заслуживают файлы с сообщениями почтовой подсистемы и подсистемы аутентификации. Электронная почта - это ядро коммуникационной системы любого предприятия. Это только кажется, что доступ к сети Интернет - самое важное, что есть у сотрудников для общения, получения информации и даже (о ужас!) развлечений. На самом деле, и этот маленький секрет знает каждый опытный системный администратор, электронная почта намного важнее! Офис потерпит полдня без доступа в Интернет, пока провайдер меняет оборудование на узле, но если вдруг из-за настроек почтового фильтра кто-нибудь не получит важное письмо, это вызовет настоящий скандал.
Поэтому анализ последних сообщений от почтового сервера должен входить в список ежедневных (а то и ежечасных) задач системного администратора.
Для просмотров последних записей файла протокола удобно использовать команду tail с ключом f (tail -f), поскольку в таком случае tail выдает последние 10 строк файла протокола и затем постоянно выдает все новые и новые строки, по мере их появления после последней выведенной строки. Рассчитывайте свои силы: некоторые программы генерируют очень интенсивный поток сообщений в файл протокола. Завершение работы tail -f обеспечивается нажатием комбинации клавиш "Ctrl-C".
Следует также упомянуть файл /var/adm/messages, в котором по умолчанию собираются сообщения, выдаваемые при загрузке системы, а также важные сообщения по ходу работы.
Протоколы в SMC
ПО Solaris Management Console (smc) представляет собой набор утилит и общую графическую оболочку, которые выполняют функции высокоуровнего интерфейса администратора. Возможности SMC обсуждаются в лекции 26, сейчас же в наши задачи входит знакомство с системой протоколирования, доступной в SMC .
Прежде всего, здесь доступна внутренняя система протоколирования всех событий, зарегистрированных "внутри" оболочки smc. В левом нижнем углу окна SMC можно выбрать закладку Console events и далее следовать по ссылке All events.
Окно Console Events откроется по щелчку на All Events, и в окне можно просмотреть список событий . Детали события доступны по клику на соответствующей строке. Протокол событий SMC полезен в том случае, если администратору нужно восстановить последовательность своих действий и проанализировать их.
Протокол в SMC не позволяет изучить многочисленные файлы протокола, которые наполняются благодаря syslogd, но зато он предоставляет доступ к собственной базе событий. Возможно, в будущем просмотр других файлов протоколов тоже будет доступен в SMC .

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика