В предыдущих лекциях мы рассмотрели основные сетевые протоколы, которые применяются для передачи и получения сообщений электронной почты. Все они прекрасно работают, если имеется постоянное сетевое соединение клиента с сервером электронной почты. К сожалению, большинство небольших компаний не могут себе позволить обслуживание узла Internet с выделенным каналом.

Итак, для подключения почтового сервера на базе ОС Linux к сети Internet требуется посредник. Чаще всего в роли такого посредника выступает сервис-провайдер Internet. Как правило, провайдер Internet предлагает определенный набор услуг для подключения небольших сетей к Internet. Один из методов подключения к провайдеру заключается в использовании отдельного маршрутизатора, который подключен к сети компании, и по мере необходимости устанавливает соединение по телефонной линии с провайдером Internet. Такое подключение приемлемо для небольших офисов, которые могут позволить себе отдельный маршрутизатор и поддержку соединения с провайдером Internet. Еще один метод заключается в том, что сервер на базе ОС Linux с помощью стандартного модема дозванивается в сеть провайдера Internet и устанавливает с ним соединение, пригодное для передачи IP-пакетов, по телефонной линии. Тогда сервер электронной почты под управлением ОС Linux сможет передать почту, равно как и другой IP-трафик, через такое соединение. После того как передача почты или другого IP-трафика завершена, почтовый сервер может разорвать соединение. Благодаря этому экономится время, которое затрачивается на поддержку соединения.

Протокол, с помощью которого сервер электронной почты на базе ОС Linux может вести обмен IP-пакетами через модемное соединение, называется протоколом "точка-точка" (Point-to-Point Protocol — PPP). Протокол РРР как метод передачи сетевого трафика между двумя равнозначными точками через полнодуплексное двустороннее соединение описан в документе RFC 1661. После того как пакеты из вашей сети попали к провайдеру, их дальнейшая судьба целиком зависит от сервера РРР провайдера Internet. Другими словами, в обязанности провайдера Internet входит их доставка получателю.

Обзор протокола РРР

Как правило, в сеансе протокола РРР имеется четыре фазы.

• Установление соединения.
• Проверка подлинности пользователя (необязательная фаза).
• Фаза переговоров.
• Завершение соединения.

Во время этих четырех фаз в протоколе РРР используется еще несколько различных протоколов. Ядром протокола РРР является протокол передачи кадров, в который включаются кадры РРР для их дальнейшей передачи через обычное модемное соединение. Имеется в виду протокол высокого уровня управления каналом передачи данных (High-Level Data Link Control Protocol — HDLC).

Прежде чем данные будут переданы по телефонной линии, между двумя устройствами на концах линии должно быть установлено соединение. При установке соединения в РРР используется специальный протокол — протокол управления соединением (Link Control Protocol — LCP). Главная задача протокола LCP — установить оптимальные параметры связи между двумя устройствами на линии, чтобы качество связи позволяло вести передачу пакетов между ними. Например, нужно согласовать с приемной и передающей сторона длину пакета, который будет передаваться между ними без искажений. После того как фаза установления соединения закончена, РРР переходит к следующей фазе.

Фаза проверки подлинности официально оговорена в RFC как необязательная, однако в наши дни требования к сетевой безопасности достаточно высоки, и практически ни одно соединение не обходится без этой фазы. В настоящее время в РРР поддерживаются два типа проверки подлинности пользователя — протокол аутентификации запрос-ответ (Challenge-Handshake Authentication Protocol — CHAP) — и протокол установления подлинности пароля (Password Authentication Protocol — PAP). Протокол CHAP более безопасный, но PAP легче реализовать, поэтому он получил более широкое распространение. После того как удаленный хост прошел аутентификацию соединения, в сеансе РРР начинается следующая фаза.

Фаза переговоров во время РРР-соединения делает протокол РРР уникальным среди других сетевых протоколов. Так, его предшественник, протокол последовательного соединения с Internet (Serial Line Internet Protocol — SLIP) поддерживал передачу только протокола IP через телефонную линию. Если протокол РРР поддерживается устройствами на обоих концах линии, то он позволяет виртуально передавать через модемное соединение любой сетевой трафик. После проверки подлинности соединения клиентское устройство РРР должно определить, какие протоколы оно будет передавать по этому соединению. Далее удаленный хост РРР обязан принять или отвергнуть протоколы, которые им не поддерживаются. Для переговоров о возможности передачи тех или иных протоколов через РРР-соединение используется протокол управления сетью (Network Control Protocol — NCP). В течение переговоров хост и клиент должны согласовать параметры для передачи каждого протокола. Например, в течение переговоров о передаче протокола IP-хост снабжает клиента информацией об IP-адресе и сервере DNS, чтобы клиент мог нормально обращаться к сети хоста РРР. После того как переговоры о протоколе успешно завершены, между хостом и клиентом начинается передача пакетов данных.

Когда клиент желает завершить сеанс РРР, то организуется еще один сеанс по протоколу LCP с целью завершения соединения. Сервер РРР должен правильно опознать этот запрос и закрыть модемное соединение с клиентом РРР.

Кадры протокола РРР

С помощью РРР через модемное соединение можно передавать сетевые пакеты с одного хоста на другой, который подключен к сети Internet. Для установления соединения между модемом, подключенным к серверу на базе ОС Linux, и модемом провайдера Internet используется специальный протокол. Стандартным методом передачи кадров через последовательное соединение является протокол HDLC. Этот протокол может использоваться с различными соединениями, организуемыми с помощью различных типов модемов. В протоколе РРР также предусмотрен специальный формат кадра для передачи пакетов на удаленный хост-компьютер. В этом разделе обсуждаются спецификации кадров HDLC и РРР, а также механизм их использования для передачи информации между клиентом и удаленным хост-компьютером.

Кадр HDLC

На протяжении многих лет HDLC применялся для связи мэйнфрэймов. Он показал свою надежность при передаче данных между двумя устройствами, соединенными с помощью модемов. В RFC 1662 описан метод инкапсуляции протокола РРР в кадр HDLC. На рис. 8.1 представлен формат кадра HDLC.

Формат кадра HDLC состоит из пяти отдельных полей, в которые инкапсулируются данные протокола РРР, посылаемые по модемной линии.

Поле Флаг используется для идентификации начала кадра HDLC. Определено, что в него заносится двоичное значение 01111110 или, в шестнадцатеричном выражении, 0x7e. При этом программное обеспечение HDLC должно обнаружить это поле и опознать значение как начало нового кадра.

В поле Адрес всегда установлена двоичная величина 11111111 или 0xff в шестнадцатеричном выражении. Это широковещательный адрес. Все станции должны уметь опознавать данные, которые направлены на этот адрес. Так как в "сети" HDLC обычно всего два устройства, то очевидно, какому устройству предназначены данные с широковещательным адресом.

Для РРР-пакетов в поле Управление в HDLC всегда установлено двоичное значение 00000011 (шестнадцатеричное 0x03). Приемной стороной должны отвергаться кадры с другими значениями в этом поле.

Так как поля управления и адреса всегда содержат одни и те же значения, то с целью экономии полосы пропускания они часто опускаются. Таким образом, первое значение после поля флага может восприниматься либо как начало пакета РРР, либо как поле Протокол (см. описание кадра РРР). Именно поэтому в поле Протокол кадра РРР не могут использоваться величины 0xff и 0x03, так как это может ввести в заблуждение принимающую сторону, которая может "решить", что получает поля адреса и управления HDLC. Сокращение полей HDLC при передаче называется сжатием кадра.

Поле проверочной последовательности кадра FCS (Frame Check Sequence) используется для обнаружения ошибок во время передачи кадра. Значение FCS вычисляется с помощью полей Адрес, Управление и данных из пакета HDLC. При вычислении проверочной последовательности кадра не учитывается поле Флаг, а также старт- и стоп-биты, которые используются в большинстве модемов.

Поле Флаг в конце кадра обозначает конец кадра. Если за данным кадром следуют другие, то это поле должно опускаться. Одно поле флага обозначает конец одного кадра и начало другого, пока в конце не задано поле флага, которое сигнализирует о конце передачи.

Иногда данные РРР имеют те же значения, что и поле флага в HDLC. Это может привести к путанице, так как приемник понимает появление такой последовательности как конец передачи. Чтобы исключить такую возможность, используется так называемая прозрачная передача кадров. После вычисления FCS передатчик проверяет поля между двумя полями флага и вставляет специальный контрольный октет (Control-Escape octet) 01111101 или шестнадцатеричное 0x7d перед каждым значением данных, которое соответствует значению флага. Затем передатчик выполняет логическую операцию "Исключающее ИЛИ" над данными с величиной 0x20, чтобы полученная величина не равнялась значению в поле Флаг. Конечно, если значение данных равно значению контрольного октета, то перед ним также должен быть помещен еще один контрольный октет с последующим выполнением операции "Исключающее ИЛИ" с величиной 0x20. Когда приемник принимает контрольный октет, он уже "знает", что необходимо провести обратное преобразование данных к их нормальному значению.

Удаленный РРР-хост может автоматически определять запрос на установление соединения от удаленного модема путем проверки первой группы октетов, полученных от клиента. Запрос на установку РРР-соединения может быть идентифицирован одной из трех групп октетов, приведенных в листинге 8.1.

В строке 1 листинга 8.1 показан стандартный кадр HDLC (7e ff 03) со стандартным полем протокола LCP (с0 21). В строках 2 и 3 представлены методы создания прозрачности кадров, после которых передаются те же кадры. Принимая любую из этих трех последовательностей по модемной линии, сервер под управлением ОС Linux делает вывод о том, что предпринимается попытка установления РРР-соединения, и реагирует на нее. Программа mgetty+sendfax использует этот механизм для автоматической инициализации сеанса РРР по входящему звонку на стандартной телефонной линии. Если ни одна из трех последовательностей кадров не принята, то сервер под управлением ОС Linux делает вывод, что поступающие данные не являются запросом на организацию сеанса РРР. В роли таких данных могут выступать попытки пользователя ввести свое имя или пароль в обычном терминальном сеансе по модемному или факс-соединению. Как видите, одну и ту же модемную линию можно использовать и в качестве обычного терминала, и для передачи факсов, и для сеансов РРР. При этом для работы со всеми перечисленными службами используется один и тот же телефонный номер.

Кадр РРР

Кадры РРР помещаются в поля данных кадра HDLC. Формат кадра РРР представлен на рисунке 8.2.

Поле Протокол может иметь длину в один или два октета; оно идентифицирует протокол, который используется в поле Информация. В табл. 8.1 приведены некоторые значения поля Протокол, которые поддерживаются протоколом РРР.

Поле Информация содержит следующий уровень данных протокола. Обратите внимание на отсутствие поля, ограничивающего длину РРР-пакета. Такого рода информацией удаленное устройство снабжает следующий уровень протоколов.

Фазы переговоров в протоколе РРР

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

Фаза установки соединения

После того как модемное соединение по протоколу HDLC между двумя сторонами установлено, устройство, инициировавшее соединение, пытается начать переговоры о параметрах, необходимых для передачи данных через это соединение. Подобно TCP-соединению, для определения состояния соединения между устройствами используется несколько параметров. Для выполнения этой задачи используется протокол управления соединением (Link Control Protocol — LCP). Все эти параметры показаны на рис. 8.3 и подробно описаны в последующих разделах.

Протокол LCP

Протокол LCP состоит из форматированных пакетов, которые позволяют двум сторонам обмениваться информацией для определения параметров соединения. На рис. 8.4 представлен формат пакета LCP.

Поле Код пакета LCP имеет длину в один байт и используется для идентификации типа пакета. Пакеты LCP используются в основном для переговоров о параметрах соединения, но с их помощью можно изменять текущее состояние соединения (например, прекратить соединение о чем мы будем говорить позже). В RFC 1661 определено 11 типов пакетов LCP, которые представлены в табл. 8.2.

Поле Идентификатор имеет длину в один октет и используется для уникальной идентификации пакета LCP. Таким образом, передатчик может однозначно определить, на какой именно запрос он посылает ответ.

Поле Длина имеет длину в два октета. В нем указывается общая длина пакета LCP (включая поля Код, Идентификатор, Длина и поле Данные). Общая длина пакета LCP не должна превышать максимальный принимаемый блок соединения (maximum recieve unit — MRU).

В поле Данные может быть столько октетов, сколько определено полем Длина. В нем содержатся данные согласно полю Код.

Назначение пакета LCP также определяется полем Код. Как видно из табл. 8.2, существуют различные типы пакетов LCP. Ниже детально описаны некоторые типы пакетов LCP.

Пакет LCP типа Configure-Request

Пакет LCP типа Configure-Request используется для установления РРР-соединения между двумя устройствами. Параметры конфигурации, которые клиент хочет согласовать с удаленным хостом, находятся в поле данных пакета. Все параметры, для которых клиент запрашивает значения, отличные от значений по умолчанию, должны включаться в этот пакет. Все параметры, значения которых не отличаются от значений по умолчанию, в пакет LCP типа Configure-Request не включаются. Некоторые параметры Configure-Request описаны в табл. 8.3.

Пакет LCP типа Configure-Ack

Пакет LCP типа Configure-Ack посылается хостом РРР, если он согласен со значениями всех параметров, заявленных в пакете Configure-Request. Значения всех параметров в этом пакете должны полностью соответствовать параметрам, заявленным в пакете Configure-Request. Если имеется расхождение хотя бы в одном из параметров, то сервер РРР не выдает пакет Configure-Ack.

Пакет LCP типа Configure-Nak

Пакет LCP типа Configure-Nak используется для сигнализации о том, что по крайней мере один из параметров, заявленных в пакете Configure-Request, не принят сервером РРР. При этом сервер должен указать, какой именно параметр не принят, и предложить альтернативное значение этого параметра в поле Опции этого пакета.

Пакет LCP типа Configure-Reject

Пакет LCP типа Configure-Reject применяется с целью уведомления клиента о том, что параметры, указанные в пакете Configure-Request, либо не опознаны (являются ошибочными), либо не приняты сервером РРР. Когда клиент получает пакет типа Configure-Reject, то он должен сделать вывод о том, что ни один из предложенных им параметров недоступен для согласования с сервером РРР.

Пакет LCP типа Terminate-Request

Пакет LCP типа Terminate-Request используется клиентом для завершения текущего сеанса РРР. Поле данных в таком пакете может состоять из нулевых байт или заполняться данными, которые не имеют значения. Хост РРР должен обнаруживать пакеты такого типа и реагировать на них соответствующим образом в течение всего сеанса РРР.

Пакет LCP типа Terminate-Ack

Пакет LCP типа Terminate-Ack используется сервером РРР для уведомления клиента о том, что его запрос на завершение сеанса РРР получен. Поле данных этого пакета может заполняться нулевыми байтами или другой бессмысленной информацией. Когда сервер РРР принимает пакет типа Terminate-Request, он должен ответить на него пакетом типа Terminate-Ack и инициировать завершение соединения.

Пакет LCP типа Code-Request

Пакет LCP типа Code-Request используется в том случае, когда сервер РРР получает от клиента пакет РРР с искаженным значением в поле Код. Это говорит о том, что версия РРР у клиента не совпадает с версией РРР на сервере или же у клиента неправильно установлена поддержка РРР. После того как сервер послал пакет такого типа, он немедленно разрывает РРР-соединение.

Пакет LCP типа Protocol-Request

Пакет LCP типа Protocol-Request применяется, если сервер РРР получает пакет РРР либо с искаженным значением в поле Протокол, либо с протоколом, который им не поддерживается. При этом в поле данных пакета этого типа включается копия отвергнутого пакета. Получение такого пакета клиентом свидетельствует о том, что указанный протокол не поддерживается сервером, о чем он сообщает пользователю.

Пакет LCP типа Echo-Request

Пакет LCP типа Echo-Request применяется для реализации метода обратной связи в РРР-соединении. Получив пакет Echo-Request, устройство РРР должно выдать в ответ на него пакет Echo-Reply. Довольно часто эта процедура используется для того, чтобы предотвратить преждевременное завершение соединения из-за отсутствия активности. Она может использоваться также в диагностических целях. Во время переговоров о параметрах соединения может быть определен параметр Magic-Number, который затем можно использовать в данном пакете для идентификации соединения.

Пакет LCP типа Echo-Reply

Как уже отмечалось, пакет LCP типа Echo-Reply используется в ответ на пакет Echo-Request. Если для соединения был определен параметр Magic-Number, то он должен включаться в этот пакет.

Пакет LCP типа Discard-Request

Пакет LCP типа Discard-Request применяется для тестирования соединения. Приемное устройство должно немедленно отбросить пакет Discard-Request. Никакого ответа на этот пакет приемное устройство посылать не должно. Пакет типа Discard-Request также должен содержать параметр Magic-Number, который был определен на стадии установления соединения.

Параметры переговоров LCP

При обмене пакетами Configure-Request в течение фазы переговоров клиент РРР может попросить изменить тот или иной параметр соединения. Если параметр не включен в пакет Configure-Request, то его значение принимается равным значению по умолчанию. На рис. 8.5 представлен формат полей параметров в пакете Configure-Request.

Поле Тип используется для идентификации параметра, о величине которого ведутся переговоры. В табл. 8.3 показаны возможные параметры.

Поле Длина имеет один октет в длину и определяет длину полей Параметры.

Максимальный принимаемый блок (Maximum Receive Unit — MRU)

Основной параметр LCP, о величине которого ведутся переговоры, — это максимальный принимаемый блок (Maximum Receive Unit) или MRU. Его значение определяет размер пакетов, которые будут передаваться через соединение. Чем больше размер пакета, тем больший объем данных может быть передан без перегрузки полосы. Однако слишком большой размер пакета может снижать производительность на плохих линиях, в которых часто появляются искажения, так как при появлении ошибки производится повторная передача всего пакета. Когда это возможно, устанавливается значение MRU равное 1500, что соответствует размеру пакета в сети Ethernet. Однако при низкоскоростном соединении рекомендуется снижать MRU до 296, благодаря этому снижается вероятность появления ошибок и, как следствие, уменьшается количество повторных передач.

Контроль качества (Quality Control)

Параметр контроля качества (Quality Control) используется, когда устройства желают определить качество установленного соединения. При возрастании количества ошибок желательно проверить качество соединения, и если оно не удовлетворяет определенным нормам, разорвать его. По умолчанию контроль качества соединения не производится. В RFC описан лишь один тип протокола контроля качества — протокол отчета о состоянии соединения Link Quality Report типа с025. При этом обе стороны, участвующие в соединении, должны согласовать использование контроля качества и его тип, прежде чем начать наблюдение за состоянием соединения.

Параметр "магическое число" (Magic-Number)

Параметр "магическое число" (Magic-Number) используется для реализации в РРР-соединении обратной связи. При этом образуется петля и клиент имитирует РРР-соединение с самим собой. Когда в пакет Configure-Request включен параметр Magic-Number, то получивший его хост РРР сравнивает это число с параметром Magic-Number из предыдущего пакета Configure-Request. Если они совпадают, то, скорее всего, имеет место соединение типа "петля". После того как параметр Magic-Number для сеанса РРР был определен, его можно употреблять в пакетах Echo-Request и Echo-Reply с целью проверки целостности соединения.

Параметр сжатия поля протокола (Protocol Field Compression)

Параметр сжатия поля протокола (Protocol Field Compression) применяется для идентификации метода сжатия, который используется обоими устройствами в РРР-соединении с целью экономии эффективной полосы пропускания. По умолчанию поле Протокол состоит из двух октетов. Если оба устройства РРР согласны использовать протокол сжатия, то это поле может быть сокращено на один октет. Если учесть, что во время сеанса РРР обычно передается несколько тысяч кадров, то мы получим значительную экономию полосы пропускания. Однако следует отметить, что в пакетах LCP нельзя использовать возможности сжатия поля Протокол. Кроме того, проверочная последовательность кадра FCS должна вычисляться со сжатым, а не с действительным полем Протокол.

Параметр сжатия полей адреса и управления (Address and Control Field Compression)

Параметр сжатия полей адреса и управления (Address and Control Field Compression) позволяет производить сжатие кадра РРР за счет сокращения полей HDLC Адрес и Управление. При этом полоса пропускания экономится даже на низкоскоростных линиях, а объем экономии больше, чем при сжатии поля Протокол. Подобно предыдущему параметру, значение проверочной последовательности кадра FCS вычисляется без этих полей.

Параметр протокола аутентификации (Authentication Protocol)

Параметр протокола аутентификации (Authentication Protocol) позволяет устройствам вести переговоры о методе проверки подлинности клиента при установлении соединения с хостом. Поскольку к сетевой безопасности в настоящее время предъявляются довольно высокие требования, то при установке РРР-соединения практически всегда проводится аутентификация клиента. На сегодняшний день поддерживаются два типа проверки подлинности клиента: тип с223 для протокола CHAP и тип с023 для протокола PAP. Более детально эти протоколы будут рассмотрены в следующем разделе.

Фаза аутентификации РРР

В качестве альтернативы проверки пользователя с помощью текстовой процедуры userid/password были разработаны два метода аутентификации. Широкое распространение в реализациях РРР получил протокол аутентификации PAP. По сравнению с PAP, протокол CHAP более безопасен и сейчас приобретает все большую популярность. В реализации РРР для ОС Linux реализованы оба этих метода проверки подлинности пользователей.

Протокол CHAP

Протокол аутентификации запрос-ответ Challenge-Handshake Authentication Protocol (CHAP) используется для реализации функций безопасности при установлении РРР-соединения. В протоколе CHAP применяется трехразовая проверка подлинности при регистрации клиента на хосте. В RFC 1994 описан алгоритм, реализуемый в протоколе CHAP. Формат пакета протокола CHAP представлен на рис. 8.6.

Поле Код имеет в длину один октет и идентифицирует тип пакета CHAP. В табл. 8.4 представлены возможные значения поля Код.

Поле Идентификатор имеет в длину один октет. С помощью этого поля происходит идентификация пакета CHAP. Затем клиент и хост по этому идентификатору могут согласовывать свои запросы и ответы на них.

Поле Длина составляет два октета. Это поле используется для задания длины пакета CHAP. Длина пакета считается с учетом полей Код, Идентификатор, Длина и Данные.

Поле Данные может быть нулевой длины или несколько октетов в длину. В него включаются данные, которые заданы в поле Код пакета CHAP.

На рис. 8.7 показан протокол, подтверждающий установление соединения, который применяется в CHAP для проверки подлинности клиента. Подтверждение установления соединения в CHAP проходит в три фазы.

• Хост посылает пакет запроса CHAP-клиенту со случайным значением.
• Клиент отвечает пакетом ответа CHAP, в который включено значение, вычисленное с помощью наложения на значение вызова секретного ключа. Ключ выводится с помощью односторонней функции хеширования.
• Далее хост сверяет значение в ответе клиента, с полученным им самим таким же способом (наложение значения вызова на ключ). Если они совпадают, то хост высылает пакет "Success" (Успешная аутентификация), и сеанс РРР продолжается. В противном случае хост посылает клиенту пакет "Failure"(Отказ), сеанс РРР прекращается и формируется LCP-пакет типа Terminate-Request.

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

Протокол PAP

В отличие от протокола CHAP, протокол установления подлинности пароля Password Authentication Protocol (PAP) не является столь изощренным. В этом протоколе используется простой механизм проверки подлинности пользователя с помощью userid/password. Идентификатор пользователя userid посылается в текстовом виде в формате ASCII. Пароль может шифроваться, а может передаваться и в текстовом виде. Это зависит от возможностей клиента.

После аутентификации клиента продолжается сеанс РРР. При этом в течение сеанса повторная аутентификация не производится. Если клиент не подтвердил свои полномочия соответствующим образом, то сеанс РРР может быть прекращен хостом РРР.

Метод проверки подлинности с помощью PAP легко реализуется, но имеет меньший уровень безопасности. Одна из причин его популярности у провайдеров услуг сети Internet заключается в том, что безопасность коммутируемых соединений не является определяющим фактором при организации подключения к сети Internet. Прослушивание телефонной линии с целью перехвата сеанса РРР довольно затруднительно, в отличие от перехвата пароля, который посылается по локальной сети Ethernet в текстовом виде. Таким образом, простота настройки PAP перевешивает возможную угрозу, связанную с низким уровнем его безопасности.

Фаза согласования сетевых протоколов

После установления соединения в фазе переговоров LCP могут организовываться отдельные сетевые сеансы. В протоколе РРР предусмотрена возможность одновременной передачи данных нескольких сетевых протоколов. Организация сеанса передачи для каждого сетевого протокола происходит в фазе согласования сетевых протоколов. Согласование параметров сетевых протоколов в сеансе РРР осуществляется с помощью протокола сетевых соединений Network Connection Protocol (NCP). Для работы сервера электронной почты на базе ОС Linux по РРР требуется лишь один протокол — IP. Протокол NCP используется для согласования параметров IP-соединения, и сеанс РРР называется протоколом управления IP или IPCP.

Протокол IPCP

Для поддержки сети IP через РРР обеими сторонами должен поддерживаться протокол управления IP. Протокол IPCP используется для согласования параметров протокола IP между двумя сторонами. Когда в кадре РРР содержится пакет IPCP, то в поле Протокол кадра РРР будет установлена величина 8021 (см. табл. 8.1).

Формат кадра IPCP идентичен формату кадра LCP (см. рис. 8.4). В поле Код пакета IPCP используются те же самые коды, что и в пакетах LCP, но распознаются только два из них — 1 и 7 (согласно табл. 8.2). Метод согласования параметров в IPCP полностью совпадает с процедурой ведения переговоров в LCP. Для согласования параметров клиент посылает на хост пакет типа Configure-Request. Если хост согласен с параметрами, предлагаемыми клиентом, он отвечает пакетом Configure-Ack, в противном случает он отвечает пакетом Configure-Nak.

Параметры IPCP

С помощью протокола IPCP два устройства РРР производят согласование параметров IP-протокола перед установкой IP-соединения. Параметры IPCP включаются в пакет Configure-Request, подобный пакету протокола LCP. В табл. 8.5 приведены параметры IPCP, регулируемые RFC.

Параметр 1 был исключен из новой редакции RFC и в настоящее время не используется. В его функции входило назначение IP-адресов устройствам РРР, которые принимают участие в сеансе. Однако было экспериментально доказано, что устройствам довольно трудно установить взаимно приемлемые IP-адреса. Поэтому вместо этого параметра был введен параметр 3.

Параметр 2 используется для согласования метода сжатия IP-пакетов с целью экономии полосы пропускания во время сеанса РРР. В настоящее время поддерживается метод сжатия заголовков TCP/IP Ван Якобсона (Van Jacobson). С его помощью можно сократить заголовок TCP/IP до трех октетов. Значение, посылаемое в пакете Configure-Request для включения функции сжатия IP, — 002d.

Параметр 3 используется для назначения IP-адреса клиентскому устройству РРР. С помощью этого параметра клиент может выбрать для себя приемлемый IP-адрес. Если хост РРР по какой-либо причине не может использовать, предложенный ему клиентом IP-адрес, то он может возвратить в пакете Configure-Nak альтернативный IP-адрес для клиента. По умолчанию никакой IP-адрес не назначается.

После успешного завершения переговоров IPCP через РРР-соединение могут пересылаться пакеты IP с одним из трех значений в поле Протокол: 0021 — для обычных, несжатых IP-пакетов, 002b — для TCP/IP-пакетов, сжатых по алгоритму Ван Якобсона, и 002f — для несжатых TCP-пакетов со сжатыми IP-заголовками (называемые несжатыми по Ван Якобсону).

Фаза завершения соединения

Когда клиенту требуется закончить сеанс РРР, он выдает пакет LCP типа Terminate-Request (описание пакетов LCP см. выше). Приняв такой пакет, сервер РРР должен ответить пакетом типа Terminate-Ack и разорвать соединение. Причем это не зависит от текущего состояния активных IP-соединений. Клиент может завершить сеанс РРР даже при активном IP-соединении. После того как сеанс РРР завершен, для открытия нового сеанса клиент должен выдать соответствующие пакеты LCP для установления соединения, даже если физическое соединение между модемами не было утеряно.

Реализации протокола РРР в ОС Linux

Операционная система Linux поддерживает протокол РРР, разбивая его функции на две части. Первая часть поддерживается на уровне ядра Linux, а вторая часть протокола РРР реализуется в прикладной программе для ОС Linux.

Функции РРР, которые необходимы для передачи пакетов HDLC через последовательное соединение, являются частью ядра ОС Linux. Благодаря этому достигается большая гибкость в работе по обычным телефонным линиям. Начиная с ядра Linux версии 2.0, был введен модульный принцип организации ядра. Теперь модули ядра можно загружать по мере необходимости и выгружать их, когда в них отпадает надобность, без компиляции ядра с новыми параметрами. В старых версиях ядра требовалась перекомпиляция ядра при добавлении или удалении из него каких-либо параметров. Теперь поддержка РРР в ядре включается намного легче. В большинство версий ядра поддержка РРР включается по умолчанию, так как сегодня он пользуется широкой популярностью.

Определить, включена ли в ядре вашей системы поддержка РРР, можно, наблюдая за сообщениями во время загрузки системы. Если во время загрузки появляется строка о поддержке РРР в ядре (или таковая имеется в файле отчета), то в ядре сконфигурирована поддержка РРР. В противном случае обратитесь к документации на имеющуюся версию ОС Linux или к документам PPP-HOWTO, если ві хотите добавить в систему поддержку протокола РРР.

Как уже отмечалось ранее, вторая часть айсберга РРР — это программа, которая управляет РРР-соединениями на сервере. Стандартом де факто для систем на базе ОС Linux стал программный пакет pppd, написанный Элом Лонгейром (Al Longyear), Полом Макеррасом (Paul Mackerras) и Майклом Калагеном (Michael Callahan). В большинство дистрибутивов ОС Linux включен бинарный пакет этой программы. В Red Hat 6.0 включена версия ppp-2.3.7, а в Caldera OpenLinux 2.2 входит ppp-2.3.5. Пакет pppd можно получить по FTP с сайта cs.anu.edu.au в каталоге /pub/software/ppp. Текущей версией на момент написания книги была ppp-2.3.10. Так как данный программный пакет сильно зависит от конфигурации ядра, настоятельно рекомендуем вам использовать версию РРР, которая поставляется с версией имеющегося ядра ОС Linux. Однако если вы любите приключения или имеете веские причины использовать именно последнюю версию РРР, то можно получить ее исходный код, а затем скомпилировать и установить ее самостоятельно. Текущую версию pppd можно получить в сети Internet по адресу:

ftp://cs.anu.edu.au/pub/software/ppp/ppp-2.3.10.tar.gz.

После получения файла извлеките его из архива tar. Далее выполните следующие шаги.

• Запустите программу ./configure в рабочем каталоге ppp-2.3.5. С ее помощью создается Makefile для специфической версии ОС Linux.
• Запустите GNU-программу make с параметром kernel (make kernel). Таким образом создаются файлы include для вашей версии Linux с необходимыми частями ядра для поддержки pppd.
• Перекомпилируйте и установите новое ядро с поддержкой pppd (обратитесь к документации на имеющуюся версию ОС Linux, чтобы исключить любые неожиданности).
• Запустите GNU программу make для компиляции программы pppd.
• С правами пользователя root запустите программу GNU make с параметром install для создания выполняемых модулей и помещения их в соответствующие каталоги.

После установки pppd (либо с использованием бинарного пакета из поставки ОС Linux, либо компиляцией исходного кода) можно сконфигурировать pppd для работы в качестве клиента или сервера РРР.

Реализация клиента РРР в ОС Linux

Программа pppd может быть сконфигурирована для работы в качестве клиента РРР. Таким образом, можно реализовать подключение локального сервера электронной почты на базе ОС Linux с провайдером Internet, у которого находится хост РРР, с целью организации IP-соединения для передачи почты и другого IP-трафика. Для поддержки функций клиента РРР для ОС Linux имеются и другие программы. Ниже мы рассмотрим некоторые из них.

Параметры клиента в pppd

Для использования pppd в клиентском режиме необходимо настроить несколько параметров, которые отвечают за подключение и установление соединения с сервером РРР. Формат команды pppd следующий:

Здесь в роли <tty line> выступает последовательный СОМ-порт, к которому подключается модем (см. лекцию 3 "Установка телекоммуникационного оборудования в ОС Linux"). Параметр <speed> обозначает скорость соединения модема с портом компьютера. Искусство применения программы заключается в подборе правильных параметров для команд, отдаваемых клиенту и серверу. Далее в этом разделе описываются некоторые параметры pppd для выполнения функций клиента РРР.

С помощью параметра connect в программе pppd можно использовать выполняемый сценарий оболочки для установки последовательных соединений перед началом работы программы pppd.

Параметр crtscts используется для включения аппаратного управления потоком RTS/CTS на последовательной линии.

Параметром defaultroute в таблице маршрутов задается маршрут по умолчанию, указывающий на IP-адрес удаленного сервера РРР. Запись в таблице маршрутов автоматически удаляется после прекращения сеанса РРР. Таким образом, Linux-серверу всегда будет известно, куда направлять IP-трафик, предназначенный для других сетей.

Параметр lock используется для создания специального файла в стиле UUCP для сигнализации о том, что модем занят.

Параметры mru и mtu позволяют регулировать максимальную величину принимаемого блока (mru) и максимальную величину передаваемого блока (mtu) во время фазы переговоров LCP. Помните, что принятие решения о величине этих блоков по-прежнему возлагается на сервер РРР. Довольно часто регулирование этих величин применяется на низкоскоростных линиях для уменьшения размера РРР-пакета.

С помощью параметра modem ОС Linux может использовать линии управления модемом. Так, если этот параметр задан, программа pppd будет ожидать появления сигнала несущей CD (carrier detect) при установлении соединения по модемной линии и сбрасывать сигнал готовности терминала DTR (data terminal ready) при разрыве соединения.

Программа chat

Программа chat является частью дистрибутива pppd и используется для упрощения строк при установлении соединения программой pppd. Для установления соединения с сервером РРР программой chat используется простой файл сценария. В сценарии chat используются текстовые строки, которые посылаются в ответ на текстовые строки, принятые от сервера. Далее chat приводит в соответствие текстовые строки в сеансе — один ответ на одну принятую строку. В листинге 8.2 показан пример сценария chat, который используется с pppd.

В строке 2 листинга 8.2 показана команда, которую посылает на модем pppd для звонка провайдеру Internet. В строке 3 указывается, какую строку текста должна ожидать pppd для инициализации установления соединения с РРР-сервером. Строка 4 сигнализирует о том, что программа chat принимает отклик модема об установлении соединения, на что она должна ответить обычной пустой строкой с символом возврата каретки. В строке 5 указывается, какую строку следует далее ожидать от сервера. Если на сервере разрешена регистрация модемного терминала, то он должен выдать соответствующую строку-приглашение login. В строке 6 программа pppd посылает идентификатор пользователя на сервер РРР, а в строке 8 — пароль. Получив доступ к командной строке сервера (см. строку 9), pppd запускает программу pppd для поддержки хоста РРР. Более детально параметры обсуждаются в разделе "Реализация сервера РРР в ОС Linux" далее в этой лекции.

Сценарий chat может использоваться клиентом pppd для дозвона на сервер РРР, где запускается программа pppd. Параметр pppd connect вызывает сценарий chat с использованием следующего формата:

Параметр connect вызывает сценарий chat для подключения к серверу РРР. Приведенная выше командная строка автоматически вызывает сервер РРР и запускает программу pppd на сервере. Параметр -v используется в программе для детализации вывода в файле отчета /var/log/messages. Его можно использовать при отладке и настройке соединения и не задавать, когда соединение работает нормально. В листинге 8.3 представлены строки, которые программы chat и pppd помещают в файл отчетов в течение сеанса РРР.

Как видите, с помощью сценария chat и команд клиента pppd организуется сеанс РРР с сервером. Все эти процедуры можно поместить в файл сценария, с помощью которого по мере необходимости можно запускать сеанс РРР. Однако при использовании такого метода организации РРР-соединения требуется наличие какого-либо события, которое запускает сценарий. В качестве такого события может использоваться процесс cron, с помощью которого запускается сценарий РРР, когда требуется забрать или отправить почту. Ниже приведена программа, с помощью которой можно запускать клиента РРР по мере надобности.

Программа diald

Теперь, имея отлаженный сценарий chat и получив возможность звонить на сервер РРР и устанавливать соединение с ним, вы, возможно, захотите автоматизировать этот процесс. Если локальный сервер электронной почты на базе ОС Linux непосредственно подключается к провайдеру Internet, то необходимо разработать график частоты его подключений для обмена электронной почтой с сервером провайдера Internet (см. лекцию 13, "Подключение почтового сервера к провайдеру Internet"). Один из методов — использование IP-маршрутизации по запросу. Под этим подразумевается, что соединение РРР устанавливается автоматически, как только обнаруживаются данные, которые направлены вне локальной сети (в сеть провайдера Internet).

Прекрасным средством для осуществления маршрутизации по запросу является программа diald, написанная Эриком Сченком (Eric Schenk). Как правило, в большинство версий ОС Linux входит бинарный пакет diald, уже готовый к установке. Если в имеющейся версии Linux эта программа отсутствует, ее можно получить в сети Internet на Web-сайте: http://diald.unix.ch.

Формат запуска программы diald следующий:

Здесь device — строка в ОС Linux для устройства tty, к которому подключается модем, options — параметры программы diald, а pppd options — параметры, которые diald передает программе pppd, когда вызывает ее. Параметры diald можно также задавать с помощью файла конфигурации.

Файл конфигурации для программы diald применяется для установки параметров, используемых ею при вызове программ pppd и chat, а также для задания списка сценариев, которые будут выполняться для старта и останова pppd. Файл конфигурации находится в каталоге /etc и называется diald.conf. В листинге 8.4 приведен пример файла diald.conf, который заменяет параметры pppd, приведенные ранее в примере.

В строке 7 листинга 8.4 задан параметр connect, который вызывает программу chat с помощью сценария chat, использованного в примере с pppd. Строка 8 предусматривает, что модем хоста РРР находится в режиме ответа на четвертый звонок (так что это не будет мешать вашим родным и друзьям, если они звонят по той же телефонной линии). Таким образом, задается интервал времени для выполнения сценария chat. В нашем случае это три минуты (180 секунд). В строке 17 программа diald обращается к файлу standard.filter, который используется diald для описания условий запуска и останова сеанса РРР. В строке 18 указывается на специальный файл, который используется сопутствующей программой dctrl для мониторинга сеанса РРР. Программа dctrl — это графический пакет для мониторинга РРР-соединения. Он позволяет оценить пропускную способность соединения, а также немедленно сигнализирует о любых ошибках в течение сеанса РРР.

После конфигурирования параметров diald можно произвести их тестирование. Программа diald запускается в фоновом режиме и запускать ее нужно с правами пользователя root. Когда diald обнаруживает в сети условия, которые требуют соединения с сервером РРР, она запускает программу chat. Та, в свою очередь, организует сеанс с сервером РРР и запускает программу pppd на локальном компьютере. Когда работа diald отлажена, можно написать для нее сценарий запуска, согласно которому она будет стартовать во время загрузки системы. Всякий же раз, когда какая-либо программа должна получить доступ к удаленному хосту по IP (например, fetchmail), будет запускаться diald и открывать сеанс РРР. Великолепно!

Программа kppp

Если в системе Linux используется менеджер окон типа K Desktop Environment (KDE), для упрощения настройки и использования РРР-соединений можно воспользоваться программой kppp. Эта программа представляет собой графическую оболочку, с помощью которой можно сконфигурировать и в дальнейшем запускать программу pppd. На рис. 8.8 показано основное окно, которое появляется при запуске kppp.

В основном окне предоставляется возможность выбора хоста РРР и запуска pppd после ввода пароля и щелчка на кнопке Соединение (Connect). Щелчок на кнопке Установка (Setup) в основном окне вызывает окно Конфигурация kppp (kppp Configuration). На вкладке Учетные записи (Accounts) окна Конфигурация kppp (kppp Configuration) можно сконфигурировать несколько пользователей. На рис. 8.9 показан внешний вид вкладки Учетные записи.

Индивидуально параметры каждой учетной записи можно задать, щелкнув на кнопке Новая (New) — рис. 8.10.

Свойства нового пользователя можно отредактировать в окне Редактирование учетной записи (Edit Account). Здесь же можно задать телефонный номер для дозвона и метод проверки подлинности, который будет использоваться во время сеанса РРР.

Доступные методы проверки подлинности включают аутентификацию с помощью протокола PAP, CHAP, сценария chat и терминального сеанса, где необходимо вручную зарегистрироваться на сервере и выполнить команду pppd на удаленном сервере. С помощью закладки IP можно задать способ получения IP-адреса: динамически — от хоста РРР или статически — вручную. Точно так же можно задать способ получения клиентом РРР IP-адресов DNS и маршрутизатора на вкладках DNS и Шлюз (Gateway): динамически — от хоста РРР или статически — вручную.

На рис. 8.11 показаны установки kppp, которые находятся на вкладке Устройство (Device). С ее помощью можно задавать настройки модема, который будет использоваться для дозвона до провайдера Internet. В их число входит аппаратное управление потоком и метод сброса линии. Флаг Использовать lock-файл (Use Lock File) позволяет использовать параметр pppd lock для создания специальных файлов в стиле UUCP. Тогда другие процессы не будут пытаться использовать модем, когда он занят в сеансе РРР.

На рис. 8.12 представлена вкладка Модем (Modem) для установки параметров модема. Воспользовавшись кнопкой Команды модема (Modem Commands), можно добавить строку инициализации модема перед установкой соединения. С помощью кнопки Опрос модема (Query Modem) осуществляется считывание текущих настроек модема. После щелчка на этой кнопке будут выводиться одновременно восемь параметров модема. А кнопка Терминал (Terminal) может пригодиться при создании сценариев дозвона. При щелчке на нее вызывается мини-терминал, с помощью которого вы можете общаться с модемом напрямую и выполнять дозвон на сервер РРР. Работа с терминалом весьма эффективна, когда требуется проследить ответы сервера, например, при отладке сценария дозвона.

После того как настройка всех параметров завершена, установление соединения представляет собой процесс дозвона до провайдера Internet и регистрацию у него на сервере с соответствующими именем пользователя и паролем. После этого требуется лишь щелкнуть на кнопке Соединить (Connect). Программа kppp будет автоматически запускать pppd с параметрами, которые были ранее заданы для данного бюджета пользователя. Для бюджетов пользователя также имеется полезная опция, с помощью которой можно получать подробный отчет о работе РРР за месяц.

Реализация сервера РРР в ОС Linux

Программа pppd, которая используется в качестве клиента РРР, может работать и в режиме сервера РРР. Обратите внимание на строку 10 в листинге 8.2. В этой строке клиент запустил pppd на сервере РРР с целью открытия сеанса РРР. Кроме возможности запуска вручную, для ОС Linux были разработаны специальные программы для автоматического запуска pppd при обнаружении на входной линии запроса на открытие сеанса РРР. В этом разделе также рассматриваются преимущества совместного использования программ pppd и mgetty+sendfax.

Параметры сервера в pppd

С помощью определенных параметров программа pppd может выполнять функции сервера РРР. Несмотря на то что протокол РРР рассматривает обе стороны, участвующие в соединении, как равноправные, одна из сторон всегда выступает в роли сервера и ожидает запросов на установление соединения от клиентов. Некоторые из параметров, используемые сервером РРР, описаны в последующих разделах.

Параметры passive и silent используются программой pppd для ожидания пакета LCP типа Configure-Request с целью инициализации сеанса РРР.

Параметр proxyarp применяется для предоставления хост-комьютеру РРР возможности обрабатывать ARP-запросы в локальной сети от имени клиента РРР. Таким образом, другие компьютеры могут подключаться к клиенту РРР.

С помощью параметра Local_IP:Remote_IP программой могут назначаться IP-адреса для удаленных устройств. При этом Local_IP — это адрес хоста РРР, а Remote_IP — адрес удаленного клиента.

Параметры pppd, которые задаются при запуске из командной строки, также можно заносить в конфигурационные файлы. По умолчанию программа pppd проверяет файл /etc/ppp/options и запускается с параметрами, которые в нем заданы. Еще одно полезное свойство pppd состоит в том, что она может устанавливать параметры в зависимости от используемого устройства tty. Благодаря этому для каждого устройства tty (порта) можно задать специфические параметры, например IP-адрес удаленной стороны. Тогда, если задействованы линии ttyS0, ttyS1 и ttyS2, для каждой из них можно задать свой набор параметров в файлах /etc/ppp/options.ttyS0, /etc/ppp/options.ttyS1 и /etc/ppp/options.ttyS2. При этом в каждом файле параметров будут указаны различные пары адресов Local_IP:Remote_IP, т.е. исключается возможность получения несколькими клиентами РРР одинакового IP-адреса.

Программа mgetty+sendfax

Если необходимо, чтобы сервер на базе ОС Linux выступал в качестве сервера РРР и принимал от клиентов запросы на установление соединений, то лучше всего для этой цели подходит программа mgetty+sendfax, написанная Гертом Доерингом (Gert Doering). Бинарный пакет этой программы, уже готовый к установке, входит в большинство версий ОС Linux. Если по какой-либо причине он отсутствует в вашей версии Linux, можно получить его с сервера sunsite.unc.edu в каталоге /pub/Linux/system/serial.

Как правило, в ОС Linux для обработки входящих соединений используется программа getty. Обнаружив попытку соединения на линии, она использует для аутентификации пользователя процедуру login, для которой требуется идентификатор пользователя и пароль. В состав mgetty+sendfax входит новая программа mgetty, которая заменяет старую программу getty для работы с последовательными линиями. Эта программа обладает большей гибкостью, чем getty, так как она способна автоматически определять тип входного звонка с помощью lock-файлов.

Для управления работой mgetty используются как параметры командной строки, так и конфигурационные файлы. В ОС Linux все указания этой программе, касающиеся взаимодействия с другими программами и обслуживания последовательных соединений, задаются в файле /etc/inittab. Каждое устройство tty на сервере под управлением ОС Linux имеет в этом файле свою строку конфигурации. Строка в файле inittab, с помощью которой mgetty управляет последовательной линией, выглядит примерно так:

Знаки двоеточия используются здесь для разделения параметров. Первый параметр — уникальный идентификатор терминальной линии. Второй параметр указывает на уровень init, на котором терминал будет активен. Как видите, для данной линии терминал будет активен для всех уровней init. Третий параметр обуславливает реакцию процесса init на активность в линии. Ключевое слово respawn указывает, что программу можно запускать на указанном уровне запуска и перезапускать ее снова после завершения работы. Таким образом, после отключения клиента модемная линия снова будет готова к приему нового соединения. Четвертым параметром является программа, которую init запускает для управления терминальной линией. Формат команды на запуск mgetty следующий:

Под параметрами [options] подразумеваются параметры для управления модемной линией, а ttydevice — устройством tty в ОС Linux, которым будет управлять mgetty. В табл. 8.6 представлены все параметры mgetty.

Как показано в примере inittab, модем переведен в режим передачи данных (т.е. в режим модема) с фиксированной скоростью 38400 бит/с. Кроме того, модем будет отвечать на звонок только после четвертого звонка. Однако есть одно свойство mgetty, которое может привести вас в замешательство. Дело в том, что mgetty не поддерживает для модема режим автоответа. Она лишь анализирует служебные сообщения, получаемые от модема. Приняв нужное количество строк RING (в зависимости от параметра -n), она выдает на модем команду на поднятие трубки ATA. Таким образом, модем не сможет ответить на входной звонок, если программа mgetty заблокирована. Вероятно, вам знакома ситуация, когда модем на сервере отвечал на входной звонок, но при этом приглашение системы login не выдавалось.

Для управления работой mgetty, кроме параметров командной строки, можно использовать и конфигурационные файлы. Для указания программ, которым mgetty должна передать управление после установления соединения, используется файл /etc/mgetty+sendfax/login.conf. Как уже отмечалось ранее, обычно управление в терминальном сеансе передается процедуре регистрации в системе login. Точно так же mgetty умеет автоматически определять, что новое соединение является соединением РРР, и передавать дальнейшее управление им программе pppd. Строка в файле /etc/mgetty+sendfax/login.conf, с помощью которой передается управление, выглядит так:

Все данные в строке AutoPPP чувствительны к регистру букв, так что будьте осторожны. Далее mgetty передает управление РРР-соединением программе pppd с параметрами, которые приведены выше в строке AutoPPP. Все они будут добавлены к параметрам, заданным в конфигурационных файлах pppd. Кстати, очень важным для клиентов РРР на базе ОС Windows, которые открывают соединение с сервером, является параметр +pap. Об этом более подробно читайте в лекции 16, "Поддержка удаленных клиентов".

После того как информация о mgetty добавлена в файл /etc/inittab, нужно чтобы она возымела действие. Для этого в ОС Linux следует задать команду telinit Q (или KILL HUP 1), чтобы процесс init перечитал файл inittab.

Следует отметить, что программа mgetty ведет собственные файлы отчетов в каталоге /var/log. Каждая модемная линия имеет свой файл отчета с именем mgetty.log + номер устройства tty. Пример сеанса работы mgetty приведен ниже в листинге файла отчета.

Как видно из данного листинга, в строках 1–9 mgetty инициализирует модем для использования с устройством ttyS0 (порт COM1). В строках 10–14 mgetty принимает от модема служебное слово RING, которое сигнализирует о получении модемом входного звонка. Как видим, после четвертого звонка mgetty выдает модему команду ATA, что означает "поднять трубку". Далее, в строке 18, mgetty определяет, что соединение является запросом на установление РРР-соединения, и запускает программу pppd с помощью команды /usr/sbin/pppd.

Резюме

Итак, протокол типа "точка-точка" (Point-to-Point Protocol (PPP)) служит для передачи сетевого трафика между двумя устройствами через модемное соединение. Для сервера электронной почты на базе ОС Linux это означает, что для установления соединения с провайдером сети Internet и получения IP-соединения требуется стандартный модем для асинхронных линий, который подключается к последовательному СОМ-порту ПК. С помощью такого соединения почтовый сервер может обмениваться электронной почтой с внешним миром (сетью Internet). Протокол РРР поддерживается в ОС Linux посредством программы pppd. Она разработана специально для работы с протоколом РРР и может выполнять как функции сервера РРР при обслуживании входящих соединений, так и клиента РРР для запроса на установление таких соединений. Сопутствующей pppd программой является программа chat. С ее помощью сервер на базе ОС Linux может общаться с модемом для установления соединения с провайдером Internet по телефонной линии и организации сеанса РРР с сервером провайдера. С целью более полной автоматизации установления РРР-соединений можно использовать программу diald. При наличии в сети IP-трафика, который адресован в Internet, она автоматически устанавливает РРР-соединение с провайдером. Для реализации функций сервера РРР можно использовать программу mgetty+sendfax, с помощью которой, при наличии входных запросов, автоматически запускается программа pppd и открываются сеансы РРР для клиентов. Она весьма успешно работает с клиентами РРР, которые используют операционные системы Windows 95, 98 и NT.