Обратный звонок

Представьте, что в одной из губерний известной вам страны некий монополист ввел поминутную тарификацию местных телефонных переговоров, объяснив это исключительно искренней заботой об интересах общества. И пока упомянутая выше общественность всячески пыталась протестовать и выражала свое несогласие с такой заботой, выставляя пикеты пенсионеров, отправляя письма в различные инстанции и обращаясь персонально к политическим деятелям разного ранга, перед сержантским составом одной из компаний (читай — перед системными администраторами) начальство поставило задачу: «Как-то надо на эти протесты ответить, но так, чтобы всем было хорошо!» Объясняя ситуацию, следует заметить, что у компании имелся сервер под управлением Linux, несколько телефонных линий и аналоговых модемов. Вся эта конструкция гордо называлась сервером доступа. Сотрудник или клиент компании, подключившись к серверу по модемному соединению из дома или другого офиса, получал доступ к документам и архивным файлам, пользовался электронной почтой или работал в Интернете. Но поскольку вводилась повременная оплата за телефонные соединения, подобная возможность показалась несколько расточительной. Вот и была поставлена задача сделать что-нибудь эдакое, дабы сократить расходы клиентов по оплате телефонных соединений с сервером доступа.

Схематическое описание решения

Отбросим варианты политического решения и рассмотрим технологию «обратного звонка» — callback — как способ снижения затрат пользователей на оплату телефонных соединений. Суть этой технологии заключается в следующем: пользователь, подключившись к серверу доступа, сообщает ему свой телефонный номер. Затем данное соединение прерывается, и уже север доступа дозванивается до клиента по указанному номеру и устанавливает новое соединение. Для сервера оно будет исходящим, для пользователя — входящим. После чего пользователь продолжает работать, как обычно. Этим достигаются две цели:

• повышение уровня секретности (можно ограничить список телефонных номеров, с которых разрешен доступ определенным пользователям);
• снижение уровня затрат пользователей на оплату телефонных соединений, поскольку обычно телефонные компании тарифицируют только исходящие телефонные соединения. При использовании механизма callback сервер доступа инициирует исходящее соединение. Следовательно, для клиента оно будет бесплатным. А первоначальное соединение клиента с сервером занимает всего несколько секунд.

Сервис «обратного звонка» предоставляют своим клиентам такие известные Интернет-провайдеры, как «Россия-Онлайн», «МТУ-Интел», «Тольятти Телеком» и др. Это подтверждает предположение о том, что «обратный звонок» служит нормальным способом защиты клиентов от дополнительных расходов при «повременке» — пусть они лучше тратят деньги на Интернет.

Прежде чем непосредственно начать рассматривать программные реализации технологии «обратного звонка», уделим некоторое внимание общим вопросам построения сервера доступа (dialin) на основе Linux-системы.

Конфигурирование сервера доступа

Настройка модемного сервера доступа охватывает широкий спектр вопросов — от установки и настройки специализированного программного обеспечения до конфигурирования параметров работы ядра ОС. Чтобы облегчить восприятие, разобьем весь процесс настройки на несколько этапов, объединяющих логически сходные операции.

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

• модем под управлением mgetty ожидает телефонного звонка;
• после поступления звонка mgetty или pppd-модуль проводит идентификацию пользователя;
• после подтверждения полномочий пользователя и вызова pppd соединение между системой пользователя и сервером рассматривается как полноценный сегмент компьютерной сети;
• по окончании работы пользователя и освобождении телефонной линии mgetty должна быть вызвана снова, чтобы, проинициализировав модем, возвратить его в режим приема входящих телефонных соединений, т. е. в начало сценария.

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

В файл /etc/inittab добавим следующую строку:

M1:234:respawn:/sbin/mgetty /dev/ttyS1

Здесь /dev/ttyS1 — серийный порт компьютера, к которому подключен модем.

Активируем измененную конфигурацию командой

#init q

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

В каталоге /var/log/ создается файл вида mgetty.ttyS1, куда заносятся сообщения mgetty о текущем состоянии модема.

В конфигурационный файл mgetty /etc/mgetty+ sendfax/login.conf добавим строку:

/AutoPPP/ -  a_ppp /usr/sbin/pppd

При подключении компьютера под управлением ОС Windows программа mgetty сразу вызовет pppd, чтобы избавиться от использования различных сценариев дозвона со стороны клиента. Для поддержки этой возможности при самостоятельной компиляции mgetty необходимо включить параметр DAUTO_PPP. После подсоединения клиента в журнале сообщений о подключении пользователей (/var/log/wtmp) появится запись следующего вида:

a_ppp	 ttyS1	33600/ARQ/V34/LA
 Sat Jul 12 12:44 - 12:44	(00:00)

Необходимо обратить внимание на то, чтобы конфигурационные записи не дублировали друг друга. В login.conf должна быть только одна незакомментированная строка, описывающая подключение по AutoPPP. Это позволит избежать различных недоразумений.

Если для работы модема требуется конфигурация, отличная от базисной (прошитой в памяти модема), можно поступить следующим образом:

• установить требуемые параметры работы модема и, сохранив данную конфигурацию, сделать ее основной;
• инициализировать модем под управлением mgetty.

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

Так будет выглядеть, например, описание операции инициализации модема U.S. Robotics 56K, подключенного к порту ttyS0 (com 1):

port ttyS0
init-chat "" ddd+++dddATZ OK
 AT&F1M0S0=2 OK
speed 38400
data-only y

А для модема IDC 5614BXL, подключенного к порту, ttyS1 (com 2) — вот так:

port ttyS1
init-chat "" ddd+++dddATZ OK
 AT&F1M0S0=2S115=4S112=200S13.0=1S116=1 OK
speed 38400
data-only y

#cat >/etc/ppp/options <

Указанные параметры имеют следующее значение:

• auth - удаленной стороне идентифицировать себя при установлении соединения;
• -chap (refuse-chap) - не использовать при установлении соединения сценарий аутентификации CHAP (Cryptographic Handshake Authentication Protocol);
• +pap (require-pap) - применять сценарий аутентификации PAP (Password Authentication Protocol);
• login - использовать системную базу данных паролей (/etc/passwd, /etc/shadow) для идентификации удаленной стороны при PAP-аутентификации;
• modem - применять методы управления модемом (для определения несущей и т. п.);
• crtscts - использовать аппаратное управление потоком данных;
• debug - сообщать дополнительную информацию о переданных/полученных управляющих пакетах. Это касается всех LCP-, PAP-, CHAP- и IPCP-пакетов. Такая возможность довольно удобна при отладке механизма работы или локализации неисправностей (в нормальном рабочем режиме она нецелесообразна из-за большого объема данных). Информация записывается в лог-файлы через syslog со средством daemon и уровнем отладки. Сообщения можно перенаправить в определенный файл соответствующей установкой в /etc/syslog.conf. Например,

...
daemon.debug	/var/log/pppd.debug
...

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

• proxyarp - добавить запись для подключаемой системы в таблицу ARP (Address Resolution Protocol) с IP-адресом удаленной системы и Ethernet-адресом этой системы, что необходимо для работы клиента в Интернете;
• lock - указание pppd блокировать последовательный порт. Необходимо, чтобы другие приложения не могли использовать это устройство во время соединения. По его окончании блокировка снимается.
• ms-dns 192.168.0.1 - сообщить удаленной Windows-системе IP-адрес используемого по умолчанию DNS (Domain Name Server)-сервера. Так можно указать два различных DNS-сервера. В этом случае IP-адрес, приведенный в первой записи, будет рассматриваться Windows-системой как основной (primary), а IP-адрес из второй - как вторичный (secondary).

Вообще-то параметры вызова pppd можно указывать в файле /etc/mgetty+sendfax/login.conf, например,

/AutoPPP/ 	- 	a_ppp	/usr/sbin/pppd
 auth -chap +pap login modem crtscts debug
 proxyarp lock ms-dns 192.168.0.1

Но подобный способ записи, на мой взгляд, неудобен, особенно при большом числе параметров.

Узнать более подробно о параметрах и режимах pppd можно из справочной информации, поставляемой с этой программой (man pppd). А за дополнительным материалом и примерами работы можно обратиться к Web-сайту Игоря Сысоева.

В нашем случае отредактируем только один файл pppd для каждого последовательного порта с подключенным модемом для приема входящих телефонных соединений:

#cat >/etc/ppp/options.ttyS1 <

При запуске помимо параметров, указанных в основном конфигурационном файле (/etc/ppp/options), pppd считывает и те, которые установлены индивидуально для каждого порта. В данном случае указан IP-адрес локальной системы (выступает в роли сервера) и IP-адрес удаленной системы (клиент). Адреса указываются через двоеточие.

При использовании PAP-идентификации pppd проверяет переданные клиентом данные по информации, содержащейся в файле /etc/ppp/pap-secrets. Это обычный текстовый файл. Каждая запись одного пользователя содержит четыре параметра, разделенных пробелами: имя клиента, имя локальной системы, пароль клиента и IP-адрес удаленной системы, закрепленный за данным клиентом. Вместо определенного значения можно указать символ *, что означает любое допустимое значение. Например, записи в файле могут иметь следующий вид:

#client	server password	remote IP addresses
dialinuser1	*	qwerty1!?192.168.0.17
dialinuser2	*	p!p8sSw0 192.168.0.18

Чтобы отдельно не описывать каждого пользователя в файле pap-secret, запишем туда завершающую строку вида

* * ?? *

А к параметрам вызова pppd добавим login. В результате для всех не описанных в pap-secret пользователей идентификационная информация будет проверяться по системной базе данных паролей.

#chmod u+s /usr/sbin/pppd

Для работы pppd требуется уровень полномочий root, а вызываться он будет пользователями, не имеющими таких полномочий. Поэтому и необходимо установить SUID-бит.

При организации dialin-сервера система начинает выступать в роли шлюза, принимая сетевые пакеты от клиентов и передавая их дальше (например, в Интернет). По умолчанию такая сетевая активность запрещена. Для разрешения должен быть установлен параметр ядра системы, описывающий транзитную пересылку сетевых пакетов. В файле /etc/sysctl.conf должна присутствовать запись:

net.ipv4.ip_forward = 1

Изменения активизируются командой:

#sysctl -p

Если нет необходимости присваивать клиентам реальные IP-адреса, то можно сделать так, что в сети они будут работать под IP-адресом сервера. Для маскирования IP-адреса клиента можно применять соответствующие функции брандмауэров Ipchains и Iptables. Например, для Ipchains эта операция выглядит так:

#ipchains -A forward -s
 192.168.0.0/24 -d 0/0 -j MASQ

А для Iptables следующим образом:

#iptables -t nat -A POSTROUTING -s
 192.168.0.0/24 -d 0/0 -j SNAT -
 -to-source $INET_SYSTEM_IP

В завершение темы организации dialin-сервера затронем вопрос, непосредственно не связанный с настройкой ПО, но касающийся одной из важных характеристик модемной связи. Необходимо отметить, что скорость передачи данных при работе по аналоговым модемам ограничена порогом в 33,6 кбит/с, определяемым стандартом ITU V.42 Международного союза электросвязи. Для достижения большей скорости приходится использовать со стороны сервера не аналоговые соединительные линии и аналоговые модемы, а цифровые телефонные каналы E1 или PRI, а также специальные цифровые модемы. Только в этом случае выполняются требования стандарта ITU V.90, при которых скорость входящей передачи данных (загрузки) достигает значения 56 кбит/с, а скорость исходящей (выгрузки) — 31,2 кбит/с. Однако реальная скорость передачи данных может быть несколько ниже из-за характеристик линии связи.

Программа callback

В комплексе с mgetty поставляется программа callback. Механизм «обратного звонка» при работе с этой программой следующий:

• пользователь на своем компьютере через "Удаленное соединение" подключается к серверу доступа;
• mgetty на стороне сервера запрашивает login пользователя;
• пользователь в ответ на запрос регистрационного имени передает свое имя или ответ, идентифицирующий его как пользователя, для которого разрешен "обратный звонок";
• mgetty, обращаясь к файлу login.config, проверяет, разрешен ли для этого пользователя обратный звонок. Если соответствующего разрешения нет, то процедура верификации идет обычным образом - запрашивается и проверяется пароль, затем запускается pppd и устанавливается соединение. Когда разрешение есть, то проверяется, указан ли для данного пользователя номер телефона. Если указан, то сервер разрывает соединение и перезванивает по этому номеру, а если не указан, то сервер запрашивает (через вызов программы callback) номер телефона. Получив ответ пользователя, сервер разрывает соединение и через некоторое время перезванивает по указанному номеру;
• после разрыва соединения компьютер пользователя должен быть приведен в режим ожидания входящего телефонного соединения;
• при поступлении звонка модем пользователя должен начать соединение ("снять трубку");
• сервер доступа запрашивает регистрационное имя и пароль, а пользователь их передает;
• после подтверждения регистрационной информации сервер запускает pppd, и соединение устанавливается.

Запрос callback (CBCP) сервером номера телефона пользователя

Данный механизм «обратного звонка» ориентирован на тестовый диалог системы пользователя с mgetty на сервере доступа, что приводит к необходимости применить сценарий дозвона, автоматизирующий данную операцию. Кроме того, модем пользователя должен быть сконфигурирован для обработки входящих соединений.

CBCP-сервер сообщает пользователю, что «обратный звонок» будет сделан на телефон, указанный администратором

Рассмотрим настройки сервера и клиента.

Конфигурационный файл mgetty.conf должен выглядеть так:

...
/AutoPPP/ -	a_ppp	/usr/sbin/pppd auth
 login +pap -chap debug show-password
cb - - /usr/sbin/callback -S
...

Первая запись дает возможность пользователям Windows, не применяющим сценарии дозвона, подключаться обычным образом. Как видим, в этом случае возможность обратного звонка не используется. Вторая запись описывает конфигурацию сервиса «обратного звонка». Здесь «cb» — псевдоимя, взятое для обозначения тех пользователей, которым разрешен «обратный звонок». Следует обратить внимание, что оно должно отличаться от реального имени. В противном случае mgetty при идентификации пользователя будет снова запрашивать номер телефона, и сценарий зациклится. Параметр вызова callback «-S» указывает использовать для исходящего звонка ту же линию (порт), на которую поступил входящий звонок. Альтернативный параметр -l рекомендует использовать для исходящего звонка определенную линию.

Можно применять несколько псевдоимен, указывая для них определенные номера телефонов. Например, вот так выглядит запись, предписывающая callback перезванивать пользователю с псевдоименем admincall по номеру 1234567:

admincall - - /usr/sbin/callback -S 1234567

Для передачи callback дополнительных параметров используется файл /etc/mgetty+sendfax/callback.config. Поскольку возможности этой программы слабо документированы, то, полагаю, будет интересна следующая информация, полученная путем анализа исходных текстов самой программы:

dialout-devices - порт (ttySx) или диапазон портов (ttySx:ttySy), используемых для исходящего звонка;

delay - задержка (минимальное число секунд) до исходящего звонка, значение по умолчанию - 20 с;

delay-randomize - верхняя граница случайного значения, добавляемого к задержке, значение по умолчанию - 10 с;

retry-time - время между двумя попытками установить соединение, значение по умолчанию - 30 с;

max-time - максимальное время, в течение которого предпринимаются попытки установить соединение, время по умолчанию - 300 с;

modem-init - строка инициализации модема, значение по умолчанию "ATQ0V1H0 OK AT+FCLASS=0 OK";

speed - скорость обмена данных с портом, по умолчанию 38400;

dial-prefix - префикс команды для дозвона, по умолчанию "ATDT0WP";

prompt-waittime - время задержки (в миллисекундах) после момента установления модемного соединения, значение по умолчанию 300;

debug - вывод отладочной информации.

В качестве примера callback.config можно привести следующую конфигурацию:

dialout-devices ttyG0_00:ttyG0_12
retry-time 30
max-time 90
debug 5
speed 115200
dial-prefix ATD9WP

Закончив на этом рассматривать конфигурацию сервера доступа, перейдем к настройке клиентского компьютера под управлением Windows. Сначала в строке инициализации модема (Панель управления? Модемы?Свойства?Подключения?Дополнительно? Строка инициализации) надо указать значение &C. Это отключает в модеме функцию контроля несущей, т. е. модем не сможет определить момент разрыва соединения. Иначе при каждом разъединении с сервером доступа, после которого он будет перезванивать, Windows сообщит о разрыве соединения и не будет обрабатывать входящий звонок.

Для автоматизации диалога с сервером доступа используется сценарий следующего вида:

Файл cb.scp

proc main
string str = $USERID
waitfor "ogin:"
transmit "callbackuser^M"
waitfor "number for callback:"
transmit "7654321^M"
waitfor "RING"
transmit "ATA^M"
waitfor "ogin:"
transmit $USERID
transmit "^M"
waitfor "assword:"
transmit $PASSWORD
transmit "^M"
waitfor ">"
transmit "ppp^M"
endproc

Здесь вместо «7654321» указывается требуемый номер телефона пользователя. Для выбранного соединения сценарий подключается вызовом Свойства (удаленного соединения)?Сценарии?Файл сценария (для Windows 98/2000/NT).

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

Протокол CBCP

Рассмотрим более изящное решение задачи «обратного звонка». Суть его заключается в поддержке протокола CBCP (Callback Control Protocol), разработанного компанией Microsoft и используемого в WINDOWS NT RAS. В момент инициации телефонного соединения с сервером удаленного доступа программа—клиент удаленного доступа, являющаяся частью ОС Windows, передает запрос на поддержку сервером функции «обратного звонка». Это реализовано на уровне сетевого протокола, происходит незаметно и независимо от пользователя. Если сервер поддерживает данную функцию и для пользователя установлены соответствующие разрешения, то появляется окно, содержащее извещение о том, что сейчас сервер произведет «обратный звонок», и запрос номера телефона пользователя.

После ответа пользователя соединение разрывается, и сервер предпринимает попытку установить исходящее соединение с компьютером пользователя. Все это происходит без установления дополнительных настроек и сценариев дозвона на компьютере пользователя. Поддержка протокола CBCP реализована на всех современных ОС семейства Windows.

В настоящий момент в стандартном демоне pppd реализована лишь клиентская часть протокола CBCP, т. е. можно только установить связь с машины, работающей под управлением Linux, в качестве клиента с сервером доступа, поддерживающим этот механизм «обратного звонка», например, с тем же упомянутым выше WINDOWS NT RAS. Но нельзя на основе этой версии pppd организовать сервер доступа. В таком случае придется воспользоваться разработками, не входящими в стандартную версию pppd. Например, это программные «заплатки» для pppd-версий 2.3.5, 2.3.7, 2.3.10, разработанные Мирославом Бобовским (Miroslav Bobovsky) в 2000 г. Более новая разработка, основанная на pppd-версии 2.4.0, — pppcbcp, она доступна на Web-сайте проекта Sourceforge.

Рассмотрим механизм «обратного звонка» на основе последней разработки.

После установки пакета pppcbcp в login.conf необходимо сделать запись следующего вида:

...
/AutoPPP/ - a_ppp	/usr/sbin/pppd +pap
 -chap login -debug callback server
...

Здесь параметр callback server указывает pppd включить поддержку протокола CBCP. Также необходимо обратить внимание на следующие три файла в /etc/ppp/:

• callback-users - файл, содержащий список пользователей, для которых разрешено использование "обратного звонка" и доступных телефонных номеров;
• callback-client - chat-скрипт для подключения к серверу доступа, поддерживающему протокол cbcp (клиентская часть);
• callback-server - chat-скрипт, служащий для инициации исходящего соединения с модемом клиента (серверная часть).

Для каждого пользователя можно описать правила применения технологий «обратного звонка». Например, либо разрешить использовать callback с любого телефонного номера или только с определенного, либо вообще запретить ему использовать callback. В последнем случае он сможет подключаться к серверу и работать, однако сервер не будет для него устанавливать исходящее соединение. В файле callback-users описываются разрешения клиентам сервера использовать доступ технологии «обратного звонка». Синтаксис правил достаточно прозрачен. Правило занимает одну строку и состоит из двух полей, разделенных пробелом. Первое поле — имя пользователя, второе — телефонный номер. Например, запись «alex 56734512» означает, что пользователь alex может работать лишь с данного телефона. Вместо имен и телефонных номеров можно указывать подстановочные символы: «-» и «*».

Записи в callback-users вида

mohov	*
*	-

переводятся на нормальный язык так:

• разрешить пользователю mohov указывать для callback любой номер телефона;
• запретить для всех пользователей, не описанных в callback-users, применять технологию "обратного звонка".

Настройки скриптов, сделанные по умолчанию, в большинстве случаев вполне годятся. В общем же этот способ решает задачу поддержки функции «обратного звонка» на Linux-сервере.

Примечание. Для использования pppd в качестве клиента callback-сервера на основе CBCP в его состав должен быть включен модуль поддержки протокола CBCP (по умолчанию он выключен). Если же pppd принимает параметр callback номер_телефона, то перекомпиляции не требуется. Для включения поддержки CBCP необходимо в каталоге его исходных кодов выполнить команду ./configure, затем в подкаталоге pppd отредактировать Makefile так, чтобы среди CFLAGS был -DCBCP_SUPPORT, среди SRCS — cbcp.c, а среди PPPDOBJS — cbcp.o. После этого собрать и установить pppd.

$make
$/bin/su
#make install

Аппаратные решения

В завершение обзора программных методов организации «обратного звонка» следует упомянуть и об аппаратных серверах доступа, наряду со множеством полезных функций поддерживающих и данную технологию (Cisco AS 5300, 3Com Total Control HiPer RAS, Zyxel RS-1612, и т.д.). При оценке достоинств и экономической эффективности различных решений на их стороне скорость, надежность и удобство администрирования. Но учитывая, что стоимость таких решений относительно высока, при условии небольшого числа клиентов работу с программными реализациями технологии «обратного звонка» можно считать целесообразной.

Проекты и ресурсы

Mgetty, http://www.leo.org/~doering/mgetty/

Sourceforge, http://sourceforge.net/

Pppd, http://www.samba.org/ppp/

Сайт Игоря Сысоева, http://sysoev.ru/

Сайт Мирослава Бобовски, http://www.kanoistika.sk/bobovsky/

ITU, http://www.itu.int/