Протокол РРР

Формат кадра 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: 7e ff 03 с0 21
2: 7e ff 7d 23 C0 21
3: 7e 7d df 7d 23 c0 21

В строке 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 предусмотрена еще одна возможность. Она состоит в том, что хост РРР может в любой момент во время сеанса РРР попросить клиента об аутентификации. Такая возможность позволяет предотвратить несанкционированный доступ со стороны других устройств.

Протокол 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. Далее выполните следующие шаги.

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

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

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

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

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

pppd <tty line> <speed> [options]

Здесь в роли <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.

1 ""
2 ATDT5551234
3 CONNECT
4 ""
5 "ogin:"
6 rich
7 "word:"
8 guitar
9 "rich]$"
10 "exec /usr/sbin/pppd silent modem crtscts proxyarp
10.0.0.100:10.0.0.2"

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

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

pppd ttyS1 38400 connect '/usr/sbin/chat -v -f /home/rich/isp.chat'\modem crtscts defaultroute

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

Sep 22 86 56 56 shadrach pppd[663] pppd 2.3.5 started by root, uid 0
Sep 22 06 56 56 shadrach kernel: registered device ppp0
Sep 22 06 56 57 shadrach chat[664]: send (ATZS7=100^M)
Sep 22 06 56 57 shadrach chat[664]: expect (OK)
Sep 22 06 56 57 shadrach chat[664]: ATZS7=100^M^M
Sep 22 06 56 57 shadrach chat[664]: OK
Sep 22 06 56 57 shadrach chat[664]: -- got it
Sep 22 06 56 57 shadrach chat[664]: sehd (ATDT5551234^M)
Sep 22 06 56 58 shadrach chat[664]: expect (CONNECT)
Sep 22 06 56 58 shadrach chat[664]: ^M
Sep 22 06 57 18 shadrach chat[664]: ATDT5551234^M^M
Sep 22 06 57 18 shadrach chat[664]: CONNECT
Sep 22 06 57 18 shadrach chat[664]: -- got it
Sep 22 06 57 18 shadrach chat[664]: send (^M)
Sep 22 06 57 18 shadrach chat[664]: expect (ogin:)
Sep 22 06 57 18 shadrach chat[664]: 28800/V42BIS^M
Sep 22 06 57 19 shadrach chat[664]: ^M
Sep 22 06 57 19 shadrach chat[664]: ^MRed Hat Linux release 5.2 (Apollo)
Sep 22 06 57 19 shadrach chat[664]: ^MKerhel 2.0.36 on an 1486
Sep 22 06 57 19 shadrach chat[664]: ^M
Sep 22 06 57 19 shadrach chat[664]: ^M^M
Sep 22 06 57 19 shadrach chat[664]: mail1.isp.net login:
Sep 22 06 57 19 shadrach chat[664]: --got it
Sep 22 06 57 19 shadrach chat[664]: send (rich^M)
Sep 22 06 57 19 shadrach chat[664]: expect (word:)
Sep 22 06 57 19 shadrach chat[664]: rich^M
Sep 22 06 57 19 shadrach chat[664]: Password:
Sep 22 06 57 19 shadrach chat[664]: -- got it
Sep 22 06 57 19 shadrach chat[664]: send (guitar^M)
Sep 22 06 57 20 shadrach chat[664]: expect (rich]$)
Sep 22 06 57 20 shadrach chat[664]: ^M
Sep 22 06 57 20 shadrach chat[664]: Last login: Tue Sep 21 20:45:47^M
Sep 22 06 57 21 shadrach chat[664]: [rich@mail1 rich]$
Sep 22 06 57 21 shadrach chat[664]: -- got it
Sep 22 06 57 21 shadrach chat[664]: send (exec /usr/sbih/pppd passive silent modem crtscts^M)
Sep 22 06 57 22 shadrach pppd[663]: Serial connection established.
Sep 22 06 57 23 shadrach pppd[663]: Using interface ppp0
Sep 22 06 57 23 shadrach pppd[663]: Connect: ppp0 <--> /dev/ttyS1
Sep 22 06 57 27 shadrach pppd[663]: local IP address 10.0.0.100
Sep 22 06 57 27 shadrach pppd[663]: remote IP address 10.0.0.2

Как видите, с помощью сценария 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 следующий:

/usr/sbin/diald [device1....] [options...] [-- [pppd options]]

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

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

1 ###
2 # /etc/diald.conf - diald configuration
3 #
4 # see /usr/lib/diald for sample config files
5 #
6 mode ppp
7 connect '/usr/sbin/chat -f /home/rich/isp.chat -t 35000'
8 connect-timeout 180
9 device /dev/ttyS1
10 speed 115200
11 modem
12 lock
13 crtscts
14 local 10.0.0.100
15 remote 10.0.0.2
16 defaultroute
17 include /usr/lib/diald/standard.filter
18 fifo /etc/diald/diald.ctl

В строке 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 управляет последовательной линией, выглядит примерно так:

#Set serial line for modem 
s1:12345:respawn:/sbin/mgetty -D -s 38400 -n 4 ttyS0

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

mgetty [options] ttydevice

Под параметрами [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/ - ppp /usr/sbin/pppd auth -chap +pap login modem \ crtscts lock proxyarp

Все данные в строке 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 09/19 06 43 56 yS0 mgetty: experimental test release 1.1.14-Apr02
2 09/19 06 43 56 yS0 check for lockfiles
3 09/19 06 43 56 yS0 locking the line
4 09/19 06 43 56 yS0 lowering DTR to reset Modem
5 09/19 06 43 57 yS0 send: \dATQ0V1H0[0d]
6 09/19 06 43 57 yS0 waiting for ``OK'' ** found **
7 09/19 06 43 58 yS0 send: ATS0=0Q0D3C1[0d]
8 09/19 06 43 58 yS0 waiting for ``OK'' ** found **
9 09/19 06 43 58 yS0 waiting...
10 09/19 06 45 23 yS0 waiting for ``RING'' ** found **
11 09/19 06 45 23 yS0 waiting for ``RING'' ** found **
12 09/19 06 45 29 yS0 waiting for ``RING'' ** found **
13 09/19 36 45 35 yS0 waiting for ``RING'' ** found **
14 09/19 06 45 59 yS0 send: ATA[0d]
15 09/19 06 45 59 yS0 waiting for ``CONNECT'' ** found **
16 09/19 06 46 13 yS0 send:
17 09/19 06 46 13 yS0 waiting for ``_'' ** found **
18 09/19 06 46 16 ##### data dev=ttyS0, pid=2766, caller='none', conn='38400/ARQ/28800 LAP-M', 
name='', cmd= '/usr/sbin/pppd' , user='/Autoppp/'

Как видно из данного листинга, в строках 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.