Персональный
сайт
Игоря
Сысоева

24.08.1999

Поскольку при аутентификации через CHAP мы должны высылать удалённой стороне случайный ключ и имя нашей системы, это имя необходимо задать с помощью параметра name, например, в файле /etc/ppp/options:

modem
crtscts
asyncmap 0
name fast

Если мы не укажем имя нашей системы, pppd будет использовать в этом качестве полное доменное имя компьютера, на котором его запустили, в нашем случае, dial.fast.ru. Иногда в рекомендациях по настройке pppd зачем-то используют параметр domain. Я не знаю, какая цель при этом преследуется, но этот параметр влияет только на имя нашей системы. Если мы укажем параметр domain fast.ru, то имя нашей системы станет dial.fast.ru.fast.ru. Не знаю, как Вам, но мне это совершенно не нужно. Что касается PAP, то для него имя нашей системы необязательно, но не помешает.

В принципе, для клиентов, использующих аутентификацию PAP или CHAP может вообще не быть записи в /etc/master.passwd, поскольку имена и пароли для аутентификации находятся в файлах /etc/ppp/pap-secrets и /etc/ppp/chap-secrets (для краткости мы будем называть их файлы secrets) в виде строк:

max       fast     abcdefg         *

max       fast     abcdefg

В одном и том же файле могут хранится имена и пароли как для аутентификации удалённых систем, так и для аутентификации себя. Первые визуально отличаются наличием поля IP-адреса. Кроме того, имя нашей системы при аутентификации удалённых систем можно заменить символом "*". Таким образом, наш файл secrets будет выглядеть так:

igor      cool     1234567
max       *        abcdefg         *

В файле /etc/ppp/pap-secrets пароль клиента может хранится не открытым текстом, а в виде результата функции crypt, например, вот так:

max       *        $1$1q2w3e4r$UptrhXMwGUeq2z68qDcXi/   *

Если pppd указать параметр login, то при аутентификации PAP он будет проверять в /etc/master.passwd пароль пользователя, имя которого совпадает с именем удалённой системы. Кроме того, pppd проверит, что бы это имя не было в файле /etc/ppp/ppp.deny, а шелл этого пользователя присутствовал в файле /etc/ppp/ppp.shells. Помимо этого, проверяется срок действия аккаунта пользователя.

Файлы /etc/ppp/ppp.deny и /etc/ppp/ppp.shells и срок действия аккаунта проверяет только pppd, входящий в комплект FreeBSD. О других отличиях читайте в статье "Сравнение версии pppd, входящей в дистрибутив FreeBSD, c обычной версией"

Если все проверки пройдут удачно, pppd запишет время работы этого пользователя в файле /var/log/wtmp. При использовании параметра login пароль клиента может вообще не храниться в /etc/ppp/pap-secrets:

max       *        ""               *

Надо заметить, что хранить пароль в шифрованном виде или в виде "" можно только при аутентификации PAP. Используя CHAP, мы вынуждены хранить пароль открытым текстом.

Теперь перейдём к полю адреса. Как мы уже говорили, символ "*" в четвёртом поле файла secrets разрешает удалённой стороне использовать любой адрес, но мы также можем разрешить использование только определённых адресов, указав их через пробел:

max       *        abcdefg         192.168.1.200 192.168.1.201

Если число запрещённых адресов меньше, чем разрешённых, то удобнее воспользоваться символом "!":

max       *        abcdefg         * !192.168.1.202

Любые диапазоны разрешать нельзя, но можно разрешать адреса, входящие в указанную подсеть:

max       *        abcdefg         192.168.1.200/30

Указав в поле адреса на первом месте символ "-", мы запрещаем использовать любые адреса, что выливается в невозможность аутентификации через PAP или CHAP для данного клиента:

max       *        abcdefg         -

Того же эффекта можно достичь, вообще убрав поле адреса.

Наконец, с помощью этого поля можно назначить адрес удалённой стороне:

max       *        abcdefg         :192.168.1.210

max       *        abcdefg         192.168.1.2:192.168.1.210

Назначать адреса в secrets-файлах может только pppd, входящий в комплект FreeBSD. О других отличиях читайте в статье "Сравнение версии pppd, входящей в дистрибутив FreeBSD, c обычной версией"

Может ли pppd использовать для аутентификации одних клиентов PAP, а для других — CHAP ? В общем случае — нет. Дело в том, что о способе аутентификации pppd договаривается с удалённой стороной ещё до того, как эта удалённая сторона сообщит своё имя. В результате может возникнуть следующая ситуация. Перед тем, как определить способ аутентификации, pppd заглядывает в файл /etc/ppp/chap-secrets и, если он находит там хотя бы одну строку, у которой второе поле равно "*" или совпадает с именем нашей локальной системы, то он предлагает удалённой системе аутентификацию через CHAP. Если удалённая сторона согласится и затем с самыми хорошими намерениями передаст нам своё имя, а этого имени в файле /etc/ppp/chap-secrets не окажется, то аутентификация не удастся. Если на удалённой стороне пользуются pppd и точно знают, что аутентификация через CHAP им не светит, они могут указать ему параметр refuse-chap и удалённый pppd ответит отказом, после чего аутентификация будет проводиться через PAP. Если же на удалённой стороне используется Windows, то дело тухляк. В Windows можно отказаться от PAP, но никак не от CHAP.

Поэтому, если мы решили использовать CHAP, то всех клиентов под Windows придётся занести в файл /etc/ppp/chap-secrets. Я бы рекомендовал использовать PAP для всех клиентов, потому что в этом случае, во-первых, пароль можно хранить в зашифрованном виде или даже в /etc/master.passwd, а во-вторых, параметр login записывает время работы клиента. Что касается того, что пароль передаётся в открытом виде по каналам связи, то для телефонных линий, на мой взгляд, это не критично. Поэтому в наш файл /usr/sbin/pppd.sh можно добавить такие параметры:

#!/bin/sh

/usr/sbin/pppd auth login require-pap refuse-chap

Мы запрещаем CHAP, требуем PAP, используем для аутентификации /etc/master.passwd, и, кроме того, записываем время работы в файл /var/log/wtmp.

(C) Игорь Сысоев
http://sysoev.ru