Итак, терминальное соединение уже настроено и проверено, теперь нужно заставить dial-in сервер понимать протокол PPP и передавать управление не /usr/bin/login, а демону PPP - pppd, или, как его по-другому называют kernel-level ppp.
В разделе «Протокол терминальных линий»
главы
«Dial-in сервер»
уже обсуждался /etc/gettytab. В ту секцию std, где описывается выбранная
для getty скорость, добавим строку pp=/root/pppd.sh:
std.57600|57600-baud:\
:np:sp#57600:\
:pp=/root/pppd.sh:
Этим мы заставим getty использовать аутентификацию PPP с помощью скрипта
/root/pppd.sh,
причем его путь и имя могут быть произвольными,
но pppd будет запускаться от имена rootа, а /root/ - и неглубоко от
корня, и права доступа у ней вполне соответствующие для обеспечения защиты скрипта. На
pppd.sh лучше
дать минимальные права - поставить режим
500 и владельца root:wheel.
Скрипт будет таким:
#!/bin/sh
/usr/sbin/pppd 57600 auth
Цифра 57600 - хорошо знакомая скорость портов и терминалов, параметр auth предписывает
демону аутентифицировать с помощью PAP или CHAP.
Если же решено использовать, например, только CHAP, так как Windows предпочитает именно
его, то работу pppd можно облегчить, запретив в скрипте /root/pppd.sh PAP:
#!/bin/sh
/usr/sbin/pppd 57600 auth refuse-pap require-chap
Логи - один из основных инструментов системного администратора, а их чтение - ежедневная
рутина, как мытье рук перед едой :). Вести их для pppd будет syslogd, и складывать
в /var/log/pppd.log. В файл syslog.conf
добавим строки:
!pppd
*.* /var/log/pppd.log
Ротацию pppd.log по достижению им размера 100 Кбайт организуем
добавлением в newsyslog.conf строки:
/var/log/pppd.log root:network 640 3 100 * Z
Права доступа лучше оставить именно такие. В любом случае
root должен иметь возможность писать в файл.
Теперь осталось только создать сам файл логов и перезагрузить syslogd, чтобы он перечитал конфигурационные файлы:
dial-in-server# touch /var/log/pppd.log
dial-in-server# kill -HUP `cat /var/run/syslogd.pid`
Кроме командной строки, по умолчанию pppd воспринимает опции из определенных файлов, расположенных в /etc/ppp/. Файлом, общим для всех терминалов, является /etc/ppp/options, для определенного терминала pppd ищет /etc/ppp/options.ttydN (например, для sio0 это будет файл /etc/ppp/options.ttyd0). Опции в них перечисляются по одной в строке. Самый высокий приоритет у опций, перечисленных непосредственно в командной строке (у нас это вызов в /root/pppd.sh), ниже у /etc/ppp/options, и самый низкий приоритет имеют опции для каждого терминала из /etc/ppp/options.ttydN.
Растаскивать опции по терминалам или же сконцентрировать их в одном месте - личное дело каждого,
но из соображений удобства, единства конфигураций и избежания путаницы практичнее, все же,
последнее. Файл /etc/ppp/options:
57600
modem
crtscts
passive
mtu 576
ms-dns 192.168.0.1
ms-dns 192.168.1.1
ms-wins 192.168.0.100
name dialin
debug
Опция 57600 лишний раз напоминает pppd о скорости терминалов.
Строки modem и crtscts говорят, что общение с терминальным девайсом
происходит посредством присущих модемам сигналов (DCD) с аппаратным управлением потоком.
После установки соединения модемом pppd отсылает LCP-кадры инициализации PPP-соединения. Чтобы pppd не сбрасывал соединение, а терпеливо ждал, не получив в ответ правильные LCP-кадры от удаленной стороны, служит опция passive. Размер пакета по умолчанию - mtu равен 576 байт. На медленных линиях документация pppd рекомендует mtu 296 (40 байт на заголовок TCP/IP и 256 байт данных), в Ethernet по умолчанию mtu равен 1500 байт.
Сервер dial-in заставляет клиента принять и пользоваться DNS и WINS серверами из ms-dns и ms-wins, на самом деле к Microsoft эти опции никакого отношения не имеют. Нужда в адресах WINS мыслима только при логине в домен Microsoft, а хотя бы один адрес DNS указать стоит. Причем самым разумным будет указание DNS-форвардера (он же кэширующий DNS) шлюза в Internet из сегмента сети клиента, а не DNS провайдера. Этим заметно сокращается время ответа на запрос разрешения имени, значит, субъективно, браузер будет загружать страницы быстрее.
Имя, необходимое при аутентификации CHAP, берется из опции name. В принципе, опция может отсутствовать, тогда pppd воспользуется полным именем хоста hostname из /etc/rc.conf. Для PAP параметр name не имеет абсолютно никакого значения.
С помощью опции debug можно заставить pppd вести очень подробные протоколы всех своих действий. Ценой этому будет лог, в который умещается меньше десятка соединений, но на первое время, особенно на период «знакомства» с dial-in и/или траблшутинга, содержимое /var/log/pppd.log окажет неоценимую помощь.
Если планируется выделять IP-адреса для dial-in клиентов из пула локальной сети, стоит воспользоваться опцией:
proxyarp
В этом случае в ARP-таблице сервера каждый раз будет создаваться соответствующая запись с
фиктивным MAC-адресом. Со стороны такое соединение будет выглядеть как Ethernet-соединение.
Раздача dial-in клиентам IP-адресов из пула локальной сети привлекательна еще и тем, что,
скорее всего, не придется добавлять и/или править правила для брандмауэра.
Список можно дополнить опцией, определяющей IP-адрес dial-in сервера, общего для всех клиентов:
192.168.1.1:
Тогда, в рассмотренных ниже файлах аутентификации, указать нужно только IP-адреса
dial-in клиентов. Все зависит от личных предпочтений и от того, будут ли в клиенты
разделяться по адресам сервера.
Еще одной опцией может быть
login
В этом случае pppd будет проверять базу со списком пользователей системы
/etc/master.passwd на предмет наличия запрашивающего соединение
пользователя и его валидности. То есть соединение будет возможно только с реквизитами пользователя,
реально имеющего возможность входа в систему. Соответственно логике вещей, pppd запротоколирует
такое соединение аналогично обычной консольной сессии пользователя. На первый взгляд, опция
login может показаться очень удобной для организации биллинга. Не буду настаивать,
но, на мой взгляд, есть способы гораздо более гибкие. Если dial-in пользователь один,
то поменять его реквизиты, например, пароль - проблем нет, а если их десяток - путаницы не
избежать, ведь изменять пароль придется дважды.
По умолчанию файлы аутентификации располагаются в /etc/ppp/ и
называться должны pap-secrets и
chap-secrets соответственно.
Настоятельно рекомендую установить им права
400 и владельца root:wheel, pppd
сможет их прочесть, так как запускается от имени rootа, а
неблагонадежные посторонние - нет. В целом, их структура одинакова. Одна строка соответствует одной записи.
Вообще-то, запись представляет собой не что иное, как список параметров для передачи функциям в недрах pppd:
client1 dialin "guessable1" 192.168.1.1:192.168.1.2
client2 dialin "guessable2" 192.168.1.1:192.168.1.3
Клиент client1 может соединяться с сервером с хоста dialin с паролем guessable1 по протоколу PPP.
Кавычки здесь служат символами-ограничителями пароля. При соединении ему будет присвоен адрес
192.168.1.2, а интерфейсу pppN (ppp0 - если client1 единственный) сервера pppd
присвоит 192.168.1.1, если в файле опций /etc/ppp/options не указан иной адрес.
Как показала практика, никакой проверки на принадлежность хостов к доменам pppd не делает
(или делает, но упорно об этом умалчивает), поэтому с одинаковым успехом с сервером
соединяются dial-in клиенты FreeBSD и Windows с произвольным именем хоста.
Вместо dialin смело можно ставить «*», позволив тем самым соединяться клиентам с любого хоста:
client3 * "guessable3" 192.168.1.1:192.168.1.4
client4 * "guessable4" 192.168.1.1:192.168.1.5
Стоит заметить, что pap-secrets, в отличие
от chap-secrets, позволяет
хранить пароли не только в открытом виде.
При аутентификации PAP pppd после первой неудачной попытки сравнения исходного и полученного паролей
хэширует исходный пароль функцией crypt и сравнивает повторно:
client5 * "gul87U6yPydXI" 192.168.1.1:192.168.1.6
client6 * "gupH5.1VDmOSA" 192.168.1.1:192.168.1.7
Более того, можно пойти дальше и, указав в /etc/ppp/options опцию login,
заставить pppd брать образцы паролей dial-in клиентов из /etc/master.passwd.
Тогда pap-secrets может вообще не содержать паролей:
client7 * "" 192.168.1.1:192.168.1.8
client8 * "" 192.168.1.1:192.168.1.9
Неудобство состоит в том, что смешивать пароли не удастся - для всех клиентов они будут браться либо из файла secrets, либо из системной базы /etc/master.passwd по опции login. На мой взгляд, для сокрытия содержимого файлов аутентификации вполне достаточно установки прав и владельца, а опция login - от лукавого. К тому же, наверняка в качестве PPP-клиента будет использоваться Windows, мягко говоря, предпочитающая протокол CHAP.
Резюмируя, мои рекомендации в плане аутентификации таковы: