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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка mgetty

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

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

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

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

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

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

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

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

port ttyS1

speed 115200

data-only у

debug 3

init-chat "" ATZ OK

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

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

Перегрузив операционную систему, можно приступать к испытаниям – попробуйте позвонить на телефонный номер, где установлен ваш модем – если все настроено нормально – модем должен «поднять трубку».

Настройка pppd

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

# Устройство

lock

login

auth

modem

crtscts

–chap

+pap

# наш интерфейс: удаленный интерфейс

192.168.10.100:192.168.10.101

# маска подсети

netmask 255.255.255.0

# адрес сервера DNS для клиента Windows

Файл /etc/ppp/pap-secrets должен содержать следующие данные:

user1 сервер. домен "" * user2 сервер. домен "" *

где:

• user1 – имя пользователя, причем он должен существовать в вашей системе, где установлен модем;

• user2 – сервер, на котором будет проводиться аутентификация; в нашем случае вместо сервер. домен необходимо поставить имя компьютера, где расположен модем;

• "" – отсутствие пароля указывает на то, что пароли необходимо брать из файла /etc/shadow;

• * – абонент может производить аутентификацию с любого IP-адреса.

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

Настройка callback-сервера

Итак, вы настроили свой dial-in-сервер, попользовались им какое-то время и захотели чего-то другого. Например, в вашем городе повременная оплата и часами работать в Интернете из дома не получается, но руководство вашей организации не возражает против того, чтобы вы работали за ее счет. Дело за малым – организовать ваш dial-in-сервер таким образом, чтобы не вы ему звонили, а он вам. В компьютерных документах такой сервер зовется callback-сервером. Функционирует он следующим образом.

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

Конфигурация callback-сервера

После того как настройка dial-in-сервера завершена, необходимо настроить callback. Для этого надо выполнить следующие действия:

1. Создать нового пользователя back.

2. Создать пустой файл с именем callback.conf в /etc/mgetty/.

back – /usr/sbin/callback -S 1234567

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