Linux - Алексей Стахнов

Свойства протокола РРР

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

Таблица 31.1. Основные возможности, реализуемые протоколом РРР

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

Составляющие РРР

РРР предоставляет возможность передачи датаграмм по последовательным point-to-point-линиям и имеет три составляющие:

• метод предоставления инкапсуляции датаграмм по последовательным РРР-линиям с использованием HDLC (High-Level Data Link Control, высокоуровневого управления данными соединения) – протокол для упаковки датаграмм по РРР средствами связи;

• расширенный протокол LCP для установления, конфигурирования и тестирования физического соединения;

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

Функционирование протокола РРР

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

Поддерживаемое оборудование

Протокол РРР адаптирован для работы с любым DTE/DCE интерфейсом, включая RS-232, RS-422, RS-423, CITT V.35. Помимо этих интерфейсов протокол может работать практически на любом оборудовании, единственное требование – наличие дуплексного режима.

Структура пакета протокола РРР

Протокол РРР использует принципы, терминологию и структуру пакетов, описанных в стандартах ISO, касающихся HDLC:

• ISO 3309–1984/PDAD1 "Addendum 1: Start/stop transmission";

• ISO 3309–1979 – описывает структуру пакетов HDLC для использования в синхронных системах;

• ISO 3309:1984/PDAD1 – описывает предложения по изменениям в ISO 3309–1979, которые позволяют использовать асинхронные системы.

На рис. 31.1 изображен формат пакета протокола РРР.

Рис. 31.1. Структура пакета протокола РРР

Рассмотрим значения полей пакета протокола РРР:

• Флаг – один байт, обозначающий начало или конец пакета. Поле флага содержит двоичную последовательность: 01111110;

• Адрес – один байт, содержащий двоичную последовательность: 11111111, стандартный широковещательный адрес. РРР не поддерживает индивидуальную адресацию станций;

• Управление – один байт, содержащий двоичную последовательность: 00000011, который посылается для передачи пользовательских данных в неразделенных пакетах;

• Протокол – 2 байта определяют протокол, упакованный в пакете протокола РРР. Значения протоколов можно узнать в соответствующем RFC;

• Данные – 0 или больше байтов, составляющих датаграмму протокола, указанного в поле протокол. Конец информационного поля определяется нахождением заканчивающей последовательности и 2-байтной последовательности в поле контрольной суммы. По умолчанию максимальная длина поля данных 1500 байтов. Однако во время установления сеанса программы pppd могут договориться использовать другое значение поля данных;

• Контрольная сумма – обычно 16 битов. Однако при установлении соединения pppd могут договориться об использовании 32-битной контрольной суммы.

РРР-протокол управления соединением (LCP)

РРР-протокол управления соединением (LCP) предоставляет методы для установления, конфигурирования, поддержания и тестирования РРР-соединения. Протокол LCP выполняет функции, приведенные ниже:

• Конфигурирование и установление связи. Перед передачей какой-либо информации (к примеру, пакет IP) протокол LCP должен открыть соединение и произвести начальный обмен параметрами настройки. Этот этап заканчивается, когда пакет о подтверждении произведенной настройки будет послан и принят обратно.

• Определение качества связи. Протокол LCP позволяет (но эту возможность зачастую не используют) добавить фазу тестирования канала связи. Тестирование канала связи должно происходить сразу же за конфигурированием и установлением связи. Во время проверки качества связи определяется – способно ли соединение с достаточным качеством транспортировать какой-либо сетевой протокол.

• Установление настроек сетевого протокола. После того как протокол LCP закончит определение параметров связи, сетевые протоколы должны быть независимо друг от друга настроены соответствующими протоколами NCP, которыми могут в любой момент времени начать или прекратить пользоваться.

• Окончание связи. Протокол LCP может в любое время прервать установленную связь. Это может произойти по требованию пользователя или из-за какого-нибудь события, к примеру, потери несущей или истечению допустимого периода времени неиспользования канала.

Существуют три типа LCP-пакетов:

• пакеты установления – используются для установления и настройки связи;

• пакеты прерывания – используются для прерывания установленной связи;

• пакеты сохранения связи – используются для управления и диагностики связи.

Сокращения, используемые при описании протокола РРР

В табл. 31.2 приведены некоторые аббревиатуры, используемые при описании протокола РРР. Расшифровка содержит как английское значение, так и русский перевод.

Таблица 31.2. Аббревиатуры, используемые при описании протокола РРР

Стандарты, описывающие протокол РРР

В табл. 31.3 приведены стандарты (RFC) протокола РРР.

Таблица 31.3. Стандарты протокола РРР

Настройка сервера входящих звонков (dial-in)

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

Итак, мы умеем настраивать систему таким образом, чтобы она выступала в роли шлюза для вашей локальной сети. Но бывает нужно получить доступ к локальной сети организации, например из дома, в том числе так же из дома выйти в Интернет через корпоративную локальную сеть. Нет ничего проще. Настраивать РРР-соединение мы уже научились, осталось только установить программу, которая умеет "поднимать трубку" модема по входящему звонку и совершать некоторые дополнительные действия. Такой программой является mgetty – признанный фаворит в своей области, умеющий помимо всего прочего посылать и принимать факсы, а также с помощью голосового модема принимать и отправлять voice mail – голосовую почту.

Настройка mgetty

Обычно mgetty, как и ррр, входит в стандартную поставку дистрибутива. Единственное, что необходимо проверить, был ли пакет mgetty скомпилирован с опцией – dauto_ppp, и если нет, то пакет следует перекомпилировать с этой опцией (в дистрибутиве Red Hat mgetty скомпилирован требуемым нам образом).

После установки mgetty нам надо отредактировать конфигурационные файлы.

В файле /etc/mgetty+sendfax/login.config мы должны написать:

/AutoPPP/ – а_ррр /usr/sbin/pppd auth refuse-chap require-pap login – /bin/login @

Эта строка говорит mgetty следующее:

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

• для пользователя требуется авторизация;

• аутентификацию по протоколу CHAP – отклонять и требовать авторизации по протоколу РАР.

После установления соединения mgetty анализирует данные, приходящие с модема, и в случае, когда приходит запрос на авторизацию по протоколу РАР, программа сразу же запускает pppd, который и проводит аутентификацию по протоколу РАР.

Далее, нам необходимо отредактировать файл /etc/mgetty+sendfax/mgetty.config приблизительно следующим образом:

port ttyS1

speed 115200

data-only у

debug 3

init-chat "" ATZ OK

answer-chat "" ATA CONNECT c r

Как видите, модем подключен ко второму последовательному порту, скорость обмена 115200, строка инициализации atz. Далее нужно добавить mgetty в файл inittab. Для этого достаточно дописать всего лишь одну строку:

S4:2345:respawn:/sbin/mgetty /dev/ttyS1