Ключевые слова:freebsd, pppoe, mpd, vpn, (найти похожие документы)
From: Николаев Дмитрий <virus (at) subnets.ru>
Date: Mon, 24 Nov 2009 14:31:37 +0000 (UTC)
Subject: Настройка PPPoE сервера во FreeBSD
Оригинал: http://subnets.ru/blog/?p=1110PPPoE сервер на встроенном во FreeBSD демоне pppoed
Как известно на FreeBSD одну и ту же задачу можно решить несколькими
способами.
Задача поднять PPPoE сервер никак не отрицает данного утверждения.
Это можно сделать как и на демоне mpd5, который находится в портах
/usr/ports/net/mpd5 и который придется собрать и установить , так и
на уже встроенном во FreeBSD демоне pppoed:
pppoed - handle incoming PPP over Ethernet connections
который нужно только настроить и все.
Располагается файл pppoed тут: /usr/libexec/pppoed
Упреждая вопросы:
* Что такое PPPoE ?
* Как работает протокол PPPoE ?
* и т.д. и т.п.
Отвечаю:
PPPoE :: Теория вопроса
В виду участившихся вопросов по работе PPPoE, для правильного
понимания обсуждаемого вопроса необходимо разобраться с основными
понятиями изучаемого явления.
PPPoE (Point-to-point protocol over Ethernet) -- сетевой протокол
передачи кадров PPP через Ethernet. Предоставляет дополнительные
возможности (аутентификация, сжатие, шифрование).
PPPoE - это туннелирующий протокол (tunneling protocol), который
позволяет настраивать (или инкапсулировать) IP, или другие протоколы,
которые наслаиваются на PPP, через соединения Ethernet, но с
программными возможностями PPP соединений, и поэтому используется для
виртуальных "звонков" на соседнюю Ethernet-машину и устанавливает
соединение точка-точка, которое используется для транспортировки
IP-пакетов, работающее с возможностями PPP.
PPPoE - это метод передачи PPP поверх Ethernet. Пакеты PPP
инкапсулируются (включаются) в Ethernet фреймы.
Действующими лицами являются с одной стороны Access Concentrator (AC)
- это сервер доступа, а с другой клиент PPPoE. Клиент и сервер должны
быть соединены с использованием любых Ethernet устройств (повторители,
коммутаторы).
Для именования сервера доступа используется Access Concentrator Name.
В свою очередь, Access Concentrator может предоставлять некоторое
количество PPPoE сервисов, называемых Service Name.
Парадигма PPPoE включает две стадии: Discovery stage и PPP Session
stage.
Клиент, желающий установить PPPoE соединение, сначала должен пройти
Discovery stage. При этом между ним и сервером передаются Ethernet
фреймы с Ether_type=0 *8863.
Наблюдать можно следующим образом:
tcpdump -n -e -i fxp0 ether proto 0 *8863
В свою очередь, Discovery stage подразделяется на: initiation, offer,
request, and session confirmation.
Сначала клиент должен инициировать PPPoE сессию (initiation). Для
этого он посылает специальный пакет Active Discovery Initiation
(PADI). Данный пакет посылается на broadcast Ethernet адрес
(ff:ff:ff:ff:ff:ff), что логично, так как клиент пока не знает адреса
сервера доступа. Опционно пакет может содержать запрашиваемый клиентом
Service Name (и только, хотя многие считают, что здесь может быть и
Access Concentrator Name).
Пример PADI-пакета:
Frame 1 (44 bytes on wire, 44 bytes captured)
Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff
PPP-over-Ethernet Discovery
Version: 1
Type 1
Code Active Discovery Initiation (PADI)
Session ID: 0000
Payload Length: 24
PPPoE Tags
Tag: Service-Name
Tag: Host-Uniq
Binary Data: (16 bytes)
Src. (=source) представляет MAC-адрес машины, пославшей PADI.
Dst. (=destination) является широковещательным Ethernet-адресом.
PADI-пакет может быть получен более чем одним AC.
Сервер доступа отвечает пакетом Active Discovery Offer (PADO), в
который включает свое название Access Concentrator Name и название
предоставляемого сервиса Service Name. Данный пакет уже юникастовый и
содержит мак адрес конкретного сервера.
Вот пример PADO-пакета:
Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:d7:df
PPP-over-Ethernet Discovery
Version: 1
Type 1
Code Active Discovery Offer (PADO)
Session ID: 0000 Payload Length: 36
PPPoE Tags
Tag: Service-Name
Tag: AC-Name
String Data: IpzbrOOl
Tag: Host-Uniq
Binary Data: (16 bytes)
AC-Name - String Data представляет строковое AC имя, в данном случае
"Ipzbr001"
Src. представляет MAC-адрес AC.
Теперь клиент может выбрать нужное (Service Name и Access Concentrator
Name) из возможно нескольких предложений (PADO пакетов) и ответить уже
конкретному серверу пакетом Active Discovery Request (PADR).
Согласный на предоставление связи сервер посылает клиенту Active
Discovery Session-confirmation (PADS) пакет, включающий уникальный
идентификатор сессии (SID), необходимый для дальнейшего
взаимодействия. На этом Discovery stage заканчивается и начинается PPP
session stage.
PPP session stage начинается с использованием уже обозначенного
идентификатора (SID) и Service Name и включает стандартные PPP
процедуры: link control, network layer control, authentication. При
этом согласуются различные параметры связи и, самое главное,
происходит аутентификация.
На данном этапе (и далее, вплоть до отключения) между клиентом и
сервером передаются Ethernet фреймы с Ether_type=0 *8864.
Наблюдать можно следующим образом:
tcpdump -n -e -i fxp0 ether proto 0 *8864
В итоге устанавливается PPPoE соединение и передаются данные.
Для окончания соединения PPPoE клиент (или сервер, что реже) посылает
пакет Active Discovery Terminate (PADT).
Типичный обмен пакетами между участниками PPPoE выглядит так (mac
сервера s:s:s:s:s:s, mac клиента c:c:c:c:c:c):
подключение клиента:
c:c:c:c:c:c ff:ff:ff:ff:ff:ff 8863 60: PPPoE PADI [Host-Uniq UTF8]
s:s:s:s:s:s c:c:c:c:c:c 8863 49: PPPoE PADO [AC-Name "Provider"]
[Service-Name] [Host-Uniq UTF8] [AC-Cookie UTF8]
c:c:c:c:c:c s:s:s:s:s:s 8863 60: PPPoE PADR [Host-Uniq UTF8]
[AC-Cookie UTF8] [AC-Name " Provider "]
s:s:s:s:s:s c:c:c:c:c:c 8863 49: PPPoE PADS [ses 0x15] [AC-Name "
Provider "] [Service-Name] [Host-Uniq UTF8] [AC-Cookie UTF8]
...обмен данными
...
...отключение клиента
c:c:c:c:c:c s:s:s:s:s:s 8863 60: PPPoE PADT [ses 0x1a]
Более подробное описание PPPoE содержится в RFC 2516
Итак приступим к настройке pppoed1. Конфигурационные файлы
Располагаются в папке /etc/ppp/
* ppp.conf
* ppp.secret
вот два основных файла, дальше я расскажу ещё о нескольких.
Правим файл ppp.conf, простой пример:
default:
set log Phase tun Chat Command Warning Error Alert Connect ipcp LQM
pppoe:
allow mode direct
set cd 5
enable lqr echo chap chap81 MSCHAPv2 mssfixup
disable pap deflate pred1 acfcomp protocomp
deny deflate pred1 acfcomp
set timeout 0
set lqrperiod 10
set echoperiod 10
set mtu 1492
set mru 1492
set dns 10.1.1.1 10.1.2.254
accept lqr dns
Внимание: Все строчки после "метка:" (label) начинаются с пробела !
(в данном случае метки (labels): default, pppoe)
Данного конфига вполне достаточно, чтобы принимать подключения.
Я не буду подробно описывать каждую строчку этого конфига, т.к. это
вполне вменяемо написано в мануале:
man ppp
Смотрите раздел: "PPP COMMAND LIST"
Теперь нам нужно задать логины и пароли, с которыми наши пользователи
будут подключаться к серверу.
Правим файл ppp.secret:
user1 passwd1 10.255.254.158 * *
user2 passwd2 10.255.254.248 * *
и так далее. Первая "колонка" - логин, вторая - пароль, третья -
IP-адрес, который будет выдан пользователю.
Если необходимо указать диапазон IP-адресов, то сделать это можно
указав его в "колонке" IP-адресов, например гостевой вход:
guest guest 10.255.255.129-10.255.255.158 * *
2. Запуск
Синтаксис:
pppoed [-Fd] [-P pidfile] [-a name] [-e exec | -l label] [-n ngdebug] [-p provider] interface
Обеспечим запись логов, куда же без них:
Правим файл /etc/syslog.conf и добавляем в него:
!pppoed
*.* /var/log/pppoed.log
Создаем файл /var/log/pppoed.log:
touch /var/log/pppoed.log
Перезапускаем демон syslogd чтобы применить изменения:
killall -1 syslogd
Готовимся к запуску.
Допустим, что:
* наш PPPoE сервер имеет имя: vpn-01
* имя нашей службы (Service Name): mycoolprovider
* сетевой интерфейс для приема подключений: em1
Таким образом команда для запуска демона будет такой:
/usr/libexec/pppoed -a vpn-01 -p mycoolprovider -l pppoe em1
Обратите внимание что -l pppoe это метка из нашего ppp.conf.
Имя vpn-01 (с которым вы запустили демон, указано после ключа "-a")
внесите в ваш файл /etc/hosts, т.к. это влияет на то какой IP-адрес
сервера будет отображаться у пользователя, пример:
127.0.0.1 localhost localhost.mydomain.ru
1.1.1.1 vpn-01 vpn-01.mydomain.ru
Таким образом когда пользователь (например Windows), после установки
соединения, нажмет "свойства соединения" то в колонке "IP-адрес"
сервера он будет видеть именно этот адрес 1.1.1.1
Каким вы сделаете IP-адрес сервера абсолютно по барабану, т.е. его
физически может и не присутствовать на этом сервере, т.к. это P2P
соединение между сервером и клиентом и пакеты все равно дойдут до
конца туннеля.
После подключения клиента к серверу, вы увидите, что на сервере
поднимется новый интерфейс и называться он будет tunX (где Х это число
от нуля и далее по кол-ву туннелей):
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
inet 1.1.1.1 --> 10.255.254.158 netmask 0xffffffff
Opened by PID 66176
Если пользователь не может подключиться, то смотрите в лог
/var/log/pppoed.log, например возможно, что пользователь не правильно
написал логин или пароль.
Если в логах о нем вы ничего не нашли, то "послушайте" что приходит
от MAC-адреса пользователя (допустим он 00:14:2a:b6:92:2c) на сетевом
интерфейсе (в нашем примере это em1 c МАС-адресом 00:15:17:61:d0:a9):
tcpdump -ni em1 ether host 00:14:2a:b6:92:2c
Возможно, что пользователь не правильно указал имя службы (Service
Name), какое имя он указал вы сразу увидите в tcpdump`е.
Запрос от пользователя:
14:15:09.379885 00:14:2a:b6:92:2c > ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863)
, length 60: PPPoE PADI [Service-Name "coolprovider"] [Host-Uniq 0x0100000001000000]
Видим что пользователь указал в кач-ве имени службы (Service Name):
coolprovider
Если оно не соответствует тому, что указано при запуске демона pppoed
(ключ -p) на сервере, а в нашем примере оно не соответствует, то
сервер PPPoE ничего не ответит данному пользователю и соответственно
подключения не состоится.
Существует возможность "избавиться" от имени службы (Service Name)
вообще. Точнее будет сказать, что будет абсолютно все равно что
пользователь указал в кач-ве имени службы (Service Name).
Для этого нужно при запуске демона в кач-ве имени службы (Service
Name) указать символ *:
/usr/libexec/pppoed -a vpn-01 -p "*" -l pppoe em1
Если сервер запущен с "*", то вернувшись к примеру выше, в tcpdump`е
мы увидим следующую картину:
Запрос пользователя -> "ищу PPPoE службу coolprovider":
14:15:09.379885 00:14:2a:b6:92:2c > ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863),
length 60: PPPoE PADI [Service-Name "coolprovider"] [Host-Uniq 0x0100000001000000]
Ответ сервера пользователю -> "я vpn-01 готов принять запрос на
данную службу, т.к. мне все равно, я принимаю любой service name":
14:15:09.383270 00:15:17:61:d0:a9 > 00:14:2a:b6:92:2c, ethertype PPPoE D (0x8863),
length 58: PPPoE PADO [AC-Name "vpn-01"] [Service-Name] [Service-Name "*"]
[Host-Uniq 0x0100000001000000] [AC-Cookie 0x004606CB]
Надеюсь теперь вам с подключением все понятно.
Далее рассмотрим ещё два конфигурационных файла:
* ppp.linkup
* ppp.linkdown
Как и следует из названия файлов их содержимое читается при каждом
подключении (поднятие линка (интерфейса tunX)) и при отключении
(падение линка (интерфейса tunX))
Для чего они вам могут пригодится ? Область применения этих файлов
очень широка. Начиная от сбора какой либо статистики, заканчивая
выполнением какой либо команды на сервере.
В мануале вы сможете найти названия переменных, которые можно
использовать в этих файлах.
Приведу примеры содержимого файлов ppp.linkup и ppp.linkdown.
Файл ppp.linkup:
pppoe:
! sh -c "/etc/ppp/up.pl USER HISADDR &"
Файл ppp.linkdown:
pppoe:
! sh -c "/etc/ppp/down.pl USER HISADDR UPTIME"
Как вы видите, все опять начинается со строки название метки (label),
которая идентифицирует метку в ppp.conf из которой и идет поднятие
соединения.
Далее идет строка с выполнением скрипта PERL и передача ему некоторых
параметров.
/etc/ppp/up.pl и /etc/ppp/down.pl - скрипты на PERL
USER, HISADDR, UPTIME - параметры
USER - это логин указанный пользователем при подключении
HISADDR - IP-адрес присвоенный пользователю
UPTIME - время, которое интерфейс провел online (был подключен)
Соответственно переданные PERL скрипту параметры помещаются в массив
@ARGV. Первый переданный параметр будет @ARGV[0], второй @ARGV[1] и
т.д.
Дальше вы в скрипте можете делать с этими данными что угодно.
Вот список всех возможных параметров (все они перечислены в мануале):
AUTHNAME This is replaced with the local authname value. See
the ``set authname'' command below.
COMPILATIONDATE This is replaced with the date on which ppp was compiled.
DNS0 & DNS1 These are replaced with the primary and secondary
nameserver IP numbers. If nameservers are negotiated by IPCP, the values of these macros will change.
ENDDISC This is replaced with the local endpoint discriminator value. See the ``set enddisc'' command below.
HISADDR This is replaced with the peers IP number.
HISADDR6 This is replaced with the peers IPv6 number.
INTERFACE This is replaced with the name of the interface thatis in use.
IPOCTETSIN This is replaced with the number of IP bytes received since the connection was established.
IPOCTETSOUT This is replaced with the number of IP bytes sent since the connection was established.
IPPACKETSIN This is replaced with the number of IP packets received since the connection was established.
IPPACKETSOUT This is replaced with the number of IP packets sent since the connection was established.
IPV6OCTETSIN This is replaced with the number of IPv6 bytes received since the connection was established.
IPV6OCTETSOUT This is replaced with the number of IPv6 bytes sent since the connection was established.
IPV6PACKETSIN This is replaced with the number of IPv6 packets received since the connection was established.
IPV6PACKETSOUT This is replaced with the number of IPv6 packets sent since the connection was established.
LABEL This is replaced with the last label name used. A label may be specified on the ppp command line, via
the "load" or "dial" commands and in the ppp.secret file.
MYADDR This is replaced with the IP number assigned to the local interface.
MYADDR6 This is replaced with the IPv6 number assigned to the local interface.
OCTETSIN This is replaced with the number of bytes received since the connection was established.
OCTETSOUT This is replaced with the number of bytes sent sincethe connection was established.
PACKETSIN This is replaced with the number of packets receivedsince the connection was established.
PACKETSOUT This is replaced with the number of packets sent since the connection was established.
PEER_ENDDISC This is replaced with the value of the peers endpoint discriminator.
PROCESSID This is replaced with the current process id.
SOCKNAME This is replaced with the name of the diagnostic socket.
UPTIME This is replaced with the bundle uptime in HH:MM:SS format.
USER This is replaced with the username that has been authenticated with PAP or CHAP. Normally,
this variable is assigned only in -direct mode.
This value is available irrespective of whether utmp logging is enabled.
VERSION This is replaced with the current version number of ppp.
Вы можете использовать любой параметр из этого списка. Если вам
необходимо передавать несколько парамтров, то, как вы наверно уже
поняли, они перечисляются через пробел.
* Подведем итог. Итак с помощью файлов ppp.linkup и ppp.linkdown вы
можете анализировать параметры подключения и на их основе
выполнять какие либо действия:
добавлять статичный роутинг
* запускать какой либо процесс (например natd)
* добавлять правила в firewall
* и т.д. и т.п.
Покажу применение ppp.linkup на одном жизненном примере, с которым сам
столкнулся, а именно баг с роутингом.
(freebsd 7.2 routing problem, freebsd ppppoe routing problem, wrong
route set by ppppoed)
Если у вас установлена FreeBSD версия 7.2-RELEASE (в этой версии баг
точно есть) вы сможете заметить такую штуку, что после подключения
пользователей к серверу по PPPoE и соответственно поднятия интерфейсов
tunX у некоторых клиентов все равно отсутствует соединение с сетью
(или доступ в Интернет) несмотря на то, что туннель успешно
устанавливается и в логах нет никаких ошибок. Вы можете подумать, что
вы что-то не так настроили, но это не так. Рассмотрим ситуацию
подробнее.
Допустим есть 3 клиента, они подключаются к серверу и он выдает им
IP-адреса:
* 10.255.255.130
* 10.255.255.131
* 10.255.255.132
На сервере их туннели присутствуют, убедимся в этом выполнив команду:
ifconfig -a
что мы видим:
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
inet 1.1.1.1 --> 10.255.255.130 netmask 0xffffffff
Opened by PID 4238
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
inet 1.1.1.1 --> 10.255.255.131 netmask 0xffffffff
Opened by PID 4377
tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
inet 1.1.1.1 --> 10.255.255.132 netmask 0xffffffff
Opened by PID 6674
Вроде бы все хорошо, но пользователи с IP-адресами 10.255.255.131 и
10.255.255.132 жалуются, что у них ничего не работает. Почему ? А вот
почему:
Смотрим в таблицу роутинга (выполняем команду netstat) и наблюдаем
примерно такую картину:
netstat -rn | grep 10.255.255.131
Destination Gateway Flags Refs Use Netif Expire
10.255.255.131 tun0 US 0 0 tun0
netstat -rn | grep 10.255.255.132
Destination Gateway Flags Refs Use Netif Expire
10.255.255.132 tun0 US 0 0 tun0
Обратите внимание на колонки Gateway и Netif, если вы были
внимательны, то сразу заметите разницу в "показаниях" вывода команды
ifconfig и netstat.
А именно, что по ifconfig IP-адрес 10.255.255.131 находится за
интерфейсом tun1, а 10.255.255.132 за интерфейсом tun2, но вывод
netstat утверждает, что все эти адреса находятся за интерфейсом tun0!
А за tun0 должен быть только один IP-адрес и это 10.255.255.130 !
netstat -rn | grep tun0
Destination Gateway Flags Refs Use Netif Expire
10.255.255.130 tun0 US 0 0 tun0
10.255.255.131 tun0 US 0 0 tun0
10.255.255.132 tun0 US 0 0 tun0
Вот это и есть "корень" проблемы. Т.к. получается исходя из таблицы
роутинга все пакеты для IP-адресов 10.255.255.131 и 10.255.255.132
отправляются в туннель tun0, а самт то IP-адреса надохятся за tun1 и
tun2, поэтому то у этих клиентов ничего и не работает.
Как решить эту проблему ?
Опять же двумя способами:
* порыться в инете на тему патча (я встречал где то при поиске через гугл)
* или воспользоваться конфигурационным файлом ppp.linkup
Я выбрал второй вариант, т.к. уже пользуюсь возможности файла
ppp.linkup. Способ моего решения такой:
в файл /etc/ppp/ppp.linkup пишем:
pppoe:
! sh -c "/etc/ppp/fix_route.sh INTERFACE &"
в моем случае полная "версия" файла /etc/ppp/ppp.linkup выглядит
так:
pppoe:
! sh -c "/etc/ppp/up.pl USER HISADDR &"
! sh -c "/etc/ppp/fix_route.sh INTERFACE &"
содержимое файла /etc/ppp/fix_route.sh:
#!/bin/sh
sleep 3
`/etc/ppp/kill_route_tun0.pl`
iface=${1}
ip=`/sbin/ifconfig $iface | /usr/bin/grep inet | /usr/bin/cut -f 4 -d " " -`
/sbin/route delete $ip
/sbin/route add $ip/32 -iface $iface
Что делает fix_route.sh:
* запускает PERL скрипт kill_route_tun0.pl
* присваевает переменной iface переданный скрипту параметр имя
интерфейса на который подключен клиент
* узнает IP-адрес присвоенный клиенту на интерфейсе (переменная ip)
* удаляет из таблицы роутинга IP-адрес клиента
* добавляет в таблицу роутинга IP-адрес клиента (ip) через интерфейс
(iface)
Посмотрим скрипт /etc/ppp/kill_route_tun0.pl:
#!/usr/bin/perl
my $tun="tun0";
my $ip;
my $trash;
open TUN, "/sbin/ifconfig -a | /usr/bin/grep -A2 '\\\(^".$tun.":\\\)' |" or die
"Can't find tunnel";
while (){
if (/^\s+inet\s+\d+\.\d+\.\d+\.\d+\s+\-\-\>\s+(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s+netmask\s+0xffffffff\s+\n$/){
$ip=$1;
}
}
close (TUN);
open NET, "/usr/bin/netstat -rn | /usr/bin/grep $tun |" or die "Can't open netstat";
while (){
if (/^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/){
$trash=$1;
if ($ip ne $trash){
# print "tun0 has $ip but trash route for $trash found on it... delete...\n";
`/sbin/route delete $trash`;
}
}
}
close (NET);
Что делает kill_route_tun0.pl:
* смотрит вывод команды и запоминает какой IP-адрес висит на
интерфейсе tun0
* смотрит вывод команды netstat -rn | grep tun0 и запоминает все
строки роутинга через интерфейс tun0
* если IP-адрес на tun0 не совпадает с адресом полученным из таблицы
роутинга, то такой маршрут (строка с роутингом) убивается
Таким образом мы избавляемся от этого бага и у каждого пользователя в
таблице роутинга появляется правильная строчка:
netstat -rn | grep 10.255.255.130
Destination Gateway Flags Refs Use Netif Expire
10.255.255.130/32 tun0 US 0 0 tun0
netstat -rn | grep 10.255.255.131
Destination Gateway Flags Refs Use Netif Expire
10.255.255.131/32 tun1 US 0 0 tun1
netstat -rn | grep 10.255.255.132
Destination Gateway Flags Refs Use Netif Expire
10.255.255.132/32 tun2 US 0 0 tun2
После того как вы создали скрипты fix_route.sh и kill_route_tun0.pl на
забудьте сделать их исполняемыми:
chmod a+x fix_route.sh
chmod a+x kill_route_tun0.pl
Вот такой вот пример области применения файла ppp.linkup
Патч (patch) для демона pppoed
В Сети можно найти патч для демона, который позволяет ограничивать
минимальное время между приемом нового соединения, для защиты от флуда
на подключение к PPPoE серверу.
Для того, что бы применить патч, в системе должны присутствовать
исходные коды (sources), т.е. папка /usr/src/ не должна быть пустой.
Если вы установили систему без исходных кодов, то их можно получить
отдельно с установочного диска или через Инет, воспользовавшись
командой:
sysinstall
После запуска передвигаемся по меню:
Configure Do post-install configuration of FreeBSD
Distributions Install additional distribution sets
Далее отмечаем "крестиком" (жмем пробел) на пункте:
[Х] src Sources for everything
Затем жмем:
All Select all of the below
и два раза
<<< X Exit Exit this menu (returning to previous)
Потом вам предложат выбрать откуда брать выбранное в меню,
соответственно выберите нужное, например:
1 CD/DVD Install from a FreeBSD CD/DVD
или
2 FTP Install from an FTP server
или любой другой подходящий вам вариант
и соответственно ждем пока исходные коды перенесутся на HDD
Скачать патч можно здесь: http://subnets.ru/saved/pppoed_patch.tar.gz
Распакуйте архив в папку /usr/local/sbin, получится /usr/local/sbin/pppoed
В /usr/local/sbin/pppoed находится файл patch.sh, запустив который вы
тем самым пропатчите демон pppoed
Либо после рапаковки архива вы сами можете последовательно выполнить
команды:
cd /usr/local/sbin/pppoed
mv /usr/libexec/pppoed /usr/libexec/pppoed_orig
mv /usr/src/libexec/pppoed/pppoed.c /usr/src/libexec/pppoed/pppoed.c_orig
cp /usr/local/sbin/pppoed/pppoed.c /usr/src/libexec/pppoed/
cd /usr/src/libexec/pppoed/
make
make install
make clean
После применения патча нам станет доступна опция -с, воспользовавшись
котором можно выставить задержку в секудах на подключение.
Например я выставляю задержку флуда на 20 секунд:
/usr/libexec/pppoed -a vpn-01 -p * -l pppoe -c 20 em1
Обламываем домашние роутеры
Многие провайдеры озадачиваются вопросом как бы сделать так, чтобы
пользователь не "раздавал" Интернет соседям через домашний роутер.
Т.е. подключается один пользователь, который покупает себе домашний
роутер (например тот же Dlink) и "раздает" подключение к Интернету
своим соседям.
В процессе пользования демоном pppoed мной случайно была обнаружена
следующая фишка.
Если при запуске pppoed демона вы в ключе "-a" указали имя, но в
файле /etc/hosts не опишите соответствие этого имени к IP-адресу, то в
кач-ве IP-адреса сервера у клиента будет IP-адрес 127.0.0.1
(localhost).
Не поняли ? Покажу на примере.
запускаем демон pppoed с именем сервера vpn-01:
/usr/libexec/pppoed -a vpn-01 -p * -l pppoe -c 20 em1
пример файла /etc/hosts:
127.0.0.1 localhost localhost.mydomain.ru
10.0.0.1 my-cool-gw my-cool-gw.mydomain.ru
Иными словами в /etc/hosts может содержаться сколько угодно хостов
главное, чтобы там не было соответствия имени vpn-01 (с которым вы
запустили демон, указано после ключа "-a") к какому либо IP-адресу.
После установки подлючения по PPPoE к серверу мы увидим на сервере
такую картину, смотрим вывод команды:
ifconfig -a
tun171: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
inet 127.0.0.1 --> 10.255.255.132 netmask 0xffffffff
Opened by PID 11017
127.0.0.1 - адрес сервера
10.255.255.132 - адрес выданный клиенту
Если подключается обычный компьютер, то он нормально "проглатывает"
IP-адрес 127.0.0.1 в кач-ве IP-адреса сервера, а вот если это домашний
роутер.... то у роутера сносит крышу и он отказывается выполнять свою
прямую работу, а именно "раздавать" Интернет подключение :) .
Сказать что все роутеры подвержены этому багу-фиче я не могу, как и
назвать точные модели роутеров, но точно могу сказать что многие.
Почему я так уверен ?
Ну как я говорил выше я обнаружил баг случайно, когда однажды, мой
клиент попросил меня настроить PPPoE сервер для общежития, чтобы там
предоставлять услуги доступа в Интернет.
Я настроил, но вот в файлик hosts забыл внести имя :) Ну с кем не
бывает.
Так вот посыпались звонки из общежития на тему того, что Интернет не
работает. Все звонившие "сидели" за домашними роутерами. Вот так я и
обнаружил эту баг-фичу :)
Может кому нить и пригодится данная информация ;)
Как подключить свой компьютер под FreeBSD к PPPoE серверу ?
Ну и напоследок рассморим как самому, с компа-клиента под ОС FreeBSD
установить PPPoE туннель до сервера.
Делается это с помощью того же ppp.conf, добавим "метку" (label)
pppoe-client:
pppoe-client:
set log Phase Chat LCP IPCP CCP tun command
set device PPPoE:IFACE:SERVICE-NAME
set authname login
set authkey password
enable lqr
set dial
set login
set ifaddr 0.0.0.0/0 0.0.0.0/0
add default HISADDR
Помним, что все строчки после "метка:" (label) начинаются с пробела!
(в данном случае "метка" это pppoe-client)
Вам необходимо заменить IFACE на Ваше имя интерфейса в сторону
провайдера (например, rl0), а SERVICE-NAME заменить на service-name
вашего провайдера
Запуск подключения:
ppp -ddial pppoe-client
Остановка подключения:
killall -9 ppp
ifconfig delete tun0
Для запуска подключения при загрузке необходимо добавить в
/etc/rc.conf:
ppp_enable="YES"
ppp_mode="ddial"
ppp_profile="pppoe"
ppp_nat="NO"
ppp_user="root"
Так же на эту тему можно почитать хендбук: http://www.freebsd.org/doc/ru/books/handbook/pppoe.htmlПоиск "левого" PPPoE сервера в локальной сети
Провайдеры предоставляющие доступ по PPPoE зачастую сталкиваются с
проблемой, когда кто-то из клиентов поднимает PPPoE сервер смотрящий в
локалку провайдера.
Т.к. "левый" PPPoE сервер принимает подключения для любого
service-name, то как результат:
абоненты провайдера не могут подключиться по PPPoE и получить доступ к
услуге.
Предлагаем вашему вниманию скрипт по поиску "левых" PPPoE серверов.
Файл pppoe_search.pl:
#!/usr/bin/perl
if ($#ARGV<0){
die "Usage: $0 <iface> [service name] [debug]\n";
}else{
$iface=$ARGV[0];
if ($ARGV[1] ne '' && $ARGV[1] ne 'debug'){
$sn=":".$ARGV[1];
$debug=$ARGV[2];
}else{
$debug=$ARGV[1];
}
}
open F, "netstat -Wni | grep Link | grep -v tun | grep -v ng | grep -v '*' | grep -v lo0 | grep $iface |"
or die "Can't exec finding MAC addresses\n";
while (<F>){
if ($_=~/^$iface\s+\d+\s\<Link#\d{1,3}\>\s+(\S{17})\s/){
$mac=$1;
}
}
if (!$mac){
die "Can't find MAC for [$iface]. Exit...\n";
}
open F, ">/tmp/ppp.conf";
print F "client:
set device PPPoE:$iface$sn
set redial 2 2
";
close F;
open F , "grep -w '/tmp/ppp.conf' /etc/ppp/ppp.conf |" or die "Can't exec grep\n";
while (<F>){
$c=$_;
}
close F;
if (!$c){
die "Can't find include client's section\n";
}else{
print "Found MAC [$mac] at $iface\n";
}
if(($pid = fork)) {
$SIG{CHLD} = 'IGNORE';
$cmd=sprintf "/usr/sbin/tcpdump -e -n -c 1 -i %s ether proto 0x8863 and ether dst %s and 'ether[0xF:1]=0x7' 2>&1 |",$iface,$mac;
if ($debug){
print "DEBUG: ===>[$cmd]<===\n";
}
open F,$cmd or die "Can't start tcpdump\n";
while (<F>){
chomp($_);
if ($debug){
print "DEBUG: ===>[$_]<===\n";
}
if ($_=~/^.+\s(.{17})\s\>\s(.{17}).+PPPoE\sPADO\s\[(.*)\]\s\[(.*)\]\s\[(.*)\]\s\[Host\-Uniq.+/){
print "\nFound asshole on iface $iface (iface's MAC: $2)\n
======================================================\n
PPPoE at MAC: [$1]\nComp name: [$3]\nListening servicename: [$5]\n
======================================================\n\n";
}elsif ($_=~/^.+\s(.{17})\s\>\s(.{17}).+PPPoE\sPADO\s\[(.*)\]\s\[(.*)\]\s\[Host\-Uniq.+/){
print "\nFound asshole on iface $iface (iface's MAC: $2)\n
======================================================\n
PPPoE at MAC: [$1]\nComp name: [$3]\nListening servicename: [$4]\n
======================================================\n\n";
}elsif ($_=~/ Device not configured/){
die "Wrong iface name [$iface]\n";
}
}
close F;
}else{
`/usr/sbin/ppp -foreground client`;
}
Далее в файл /etc/ppp/ppp.conf добавляем строчку:
!include /tmp/ppp.conf
Внимание, эта строка НЕ должна начинаться с пробела.
Осталось сделать файл запускным:
chmod a+x pppoe_search.pl
Ну и запускаем его на исполнение и видим:
Usage: ./getto.pl <iface> [service name] [debug]
Т.е. для того что бы скрипт начал поиск ему необходимо передать
параметры: имя интерфейса, на котором будем искать, и имя
service-name, который ищем.
Пример:
/getto.pl bge1 myservicename
тоже самое, но в выводом дебага:
/getto.pl bge1 myservicename debug
Скрипт желательно запускать со своего PPPoE сервера, скрипт исключит
мак адрес своего сервера (на котором он был запущен).
Настраиваем PPPoE server на FreeBSD используя порт MPD5
В данной статье рассматривается возможность использование MPD 5-й
версии в качестве сервиса PPPoE на серверах FreeBSD.
Введение
Mpd - реализация multi-link PPP протокола для FreeBSD, основанная на
netgraph(4). В его основу легли концепции скорости и гибкости
настроек. Исходя из этих принципов настройка соединений происходит на
пользовательском уровне (user land), в то время как передача данных
является функцией ядра (kernel).
Mpd поддерживает множество типов соединений:
* модем - для соединения различных асинхронных последовательных
соединений (asychronous serial connections), включая модем, ISDN
адаптеры, и нуль-модемное соединение (null-modem). Mpd включает в
себя скриптовый язык обработки данных основанный на событиях
(event-driven scripting language) для установки типа модема,
утановки соединения, авторизации и т.д.
* pptp - соединение точка-точка через Internet по протоколу PPTP
(Point-to-Point Tunnelling Protocol). Данный протокол
поддерживается большинством производителей операционных систем и
оборудования.
* l2tp - соединение через Internet используя протокол 2-го уровня
L2TP (Layer Two Tunnelling Protocol). L2TP является дальнейшей
реализацией протокола PPTP и также поддерживается современными
производителями операционных систем и оборудования.
* pppoe - соединение поверх Ethernet по протоколу PPP
(PPP-over-Ethernet). Данный протокол в основном используется DSL
провайдерами.
* tcp - тунелирование PPP сессии поверх TCP соединения. Кодирование
фреймов (Frames) происходит по аналогии с асинхронным соедиениеним
(asychronous serial connections).
* udp - туннелирование PPP сессии поверх UDP соединения. Каждый
фрейм инкапсулируется в пакет с UDP датаграммой (UDP datagram
packet).
* ng - соединение различных устройств, поддерживаемых netgraph.
Netgraph - система сетевых модулей уровня ядра, поддерживает
синхронные последовательные соединения (synchronous serial
connections), Cisco HDLC, Frame Relay, и многие другие протоколы.
MPD поддерживает некоторые реализации субпротоколов PPP и их
расширений, таких как:
* Multi-link PPP
* PAP, CHAP, MS-CHAP и EAP автроризация
* сжатие трафика (traffic compression (MPPC, Deflate, Predictor-1))
* криптование трафика (traffic encryption (MPPE, DESE, DESE-bis))
* IPCP и IPV6CP параметры согласования
В зависимости от конфигурационных правил и параметров соединения, mpd
может функционировать как обычный PPP клиент/сервер (client/server)
или передавать пакеты без изменения другому хосту, используя
поддерживаемый тип соединения, обеспечивая при этом LAC/PAC/TSA
функциональность для построения распределенных сетей.
Mpd включает в себя следующие дополнительлные возможности:
* поддержка IPv4 и IPv6.
* управление по Telnet и HTTP.
* различные типы авторизации и методы подсчета трафика (RADIUS, PAM,
авторизация по скрипту, авторизация по файлу, ...)
* подсчет трафика по NetFlow
* Network address translation (NAT)
* Dial-on-demand с выключением по неактивности (idle timeout)
* Динамическое управление соединением (Dynamic demand based link
management (также известное как "rubber bandwidth"))
* Функциональный язык написания скриптов для асинхронных
последовательных соединений (synchronous serial ports)
* Готовые скрипты для некоторых основных типов модемов и ISDN
адаптеров
* Интерфейс, независимый от типа устройств
* Обширные возможности авторизации
Mpd изначально разрабатывался Whistle Communications, Inc. для
ипользования во внутренней сети Whistle InterJet. В его основе лежит
iij-ppp user-mode PPP код, сильно изменившийся до сего дня. Домашняя
страница разработчиков Mpd в настоящее время хостится на сайте
sourceforge.net MPD Project Page
Отличия от 4 версии:
* Изменения структуры:
* Устранены статические линки (static link) - реализация
зависимостей бандла (bundle). Линки выбирает бандл, используя
параметры согласования на сетевой стадии (NETWORK phase).
Этим достигается простота и полная работоспособность клиента
и мультифункциональность сервера. Также это дает возможность
реализовать боелее сложные LAC, PAC и TSA настройки, чем было
до 5 версии.
* Внедрены шаблоны, основанные на динамическом создании
линках/бандлах. Это позволило значительно сократить
конфигурацию для серверов с большим количеством клиентов.
Линк может автоматически создаваться входящим запросом (call
request) от устройства или DoD/BoD запросом (Dial on
Demand/Brake on Demand) из бандла. Бандл может автоматически
создаваться при достижении сетевой стадии NETWORK phase.
* Для упрощения объединена конфигурация физического и
канального уровня, разделенных с верии 4.2.
* Новые возможности:
* PAM авторизация.
* Добавлена поддержка динамического пула IP адресов.
* Добавлена поддержка внешних скриптов авторизации `ext-acct'
как альтернатива `radius-acct'.
* Изменения:
* Значительные изменения в конфигурации комманд. Следует
прочитать мануал и примеры.
* FreeBSD 4.x и старые релизы DragonFly не поддерживаются.
Установка
Перед установкой следует решить для себя, как MPD будет загружать
модули netgraph - через ядро или самостоятельно по мере необходимости.
Опции:
# netgraph options
options HZ=1000
options NETGRAPH
options NETGRAPH_PPPOE
options NETGRAPH_SOCKET
options NETGRAPH_CISCO
options NETGRAPH_ECHO
options NETGRAPH_FRAME_RELAY
options NETGRAPH_HOLE
options NETGRAPH_KSOCKET
options NETGRAPH_LMI
options NETGRAPH_RFC1490
options NETGRAPH_TTY
options NETGRAPH_ASYNC
options NETGRAPH_BPF
options NETGRAPH_ETHER
options NETGRAPH_IFACE
options NETGRAPH_KSOCKET
options NETGRAPH_L2TP
options NETGRAPH_MPPC_ENCRYPTION
options NETGRAPH_PPP
options NETGRAPH_PPTPGRE
options NETGRAPH_TEE
options NETGRAPH_UI
options NETGRAPH_VJC
Можно включать в конфиг ядра не все подряд, а только то, что нужно вам.
При установке на FreeBSD черед пэкедж или порт, mpd автоматически
установится в /usr/local/sbin/mpd5 с компиллированием дефолтового
набора поддерживаемых устройств. Для запуска mpd требуются несколько
конфигурационных файлов, которые находятся в директории
/usr/local/etc/mpd5. В этой директории вы можете найти примеры
конфигурационных файлов.
Перед запуском mpd, нужно выполнить настроики следующих файлов:
mpd.conf
Файл описывает одну или более конфигурации. При старте mpd
через консоль указывается название конфигурации (которая может
состоять из нескольких mpd комманд), которая и загружается.
Если название не указывается, загружается конфигурация,
описанная в разделе `default'. Каждая конфигурация определяет
один или несколько бандлов (bundle), линков (link) или
репитеров (repeater). Их описание начинаются с комманды create.
Последующие комманды в конфигурации описывают различные уровни
этих блоков.
mpd.secret
Файл содержит пары логин-пароль. MPD просматривает файл при
авторизации. Файл должен быть доступен для чтения только root.
mpd.script
Файл содержит скрипты для модемных устройств.
Прикручиваем логи:
В файл /etc/syslog.conf добавляем:
!mpd
*.* /var/log/mpd.log
Создаем файл /var/log/mpd.log ручками командой:
touch /var/log/mpd.log
Задаем ротацию логов в файле /etc/newsyslog.conf
/var/log/mpd.log 600 7 100 * JC
Файл /etc/rc.conf должен содержать запись:
mpd_enable="YES"
иначе система не даст запустить процесс mpd.
Старт MPD проходит через загрузчик /usr/local/etc/rc.d/mpd5 с опцией
start.
/usr/local/etc/rc.d/mpd5 start
Стандартные опции {start|stop|restart}.
Системные настройки сервера
Есть некоторые моменты, которые следует учесть, если ваш сервер имеет
большое количество соединений. Например, можно столкнуться с
ситуацией, когда при выводе комманды ngctl list будет выдававаться No
buffer space available. Чтобы этого избежать следует добавить в
/boot/loader.conf:
kern.ipc.nmbclusters=16384
kern.ipc.maxsockets=16384
net.graph.maxalloc=2048
kern.maxusers=512
kern.ipc.maxpipekva=32000000
в /etc/sysctl.conf:
net.graph.maxdgram=128000
net.graph.recvspace=128000
Более подробную информацию об этих настройках можно найти здесь.
Если MPD работает на вланах (vlan), которые поднимаются из
/etc/rc.local, я наблюдал такую картину. Процесс MPD стартует раньше,
чем поднимаются вланы на интерфейсах. В итоге получается, что вроде
как сервер рабоатет нормально, только никто подключиться не может. Из
этой ситуации есть два выхода (напоминает: из любой ситуации всегда
есть два выхода). Либо поднимать вланы через /etc/rc.conf, либо в
загрузчик MPD /usr/local/etc/rc.d/mpd5 в начало добавляем строчку:
`/bin/sh /etc/rc.local`
Будьте осторожны, возможно через этот файл у вас прописывается
маршрутизация или еще что-нибудь.
Убедитесь, что этот способ не затронет другие сервисы в вашей системе.
Файл конфига mpd.conf
В этой главе я постараюсь по подробнее рассмотреть файл своего
рабочего конфига. Если вы мигрируете с более ранней версии MPD,
конфигурационный файл придется переписывать. Напомню также, что в 5-ой
версии отказались от mpd.links. Для начала полный листинг mpd.conf:
startup:
#configure mpd users
set user admin PASSWORD
#configure the console
set console self 127.0.0.1 5005
set console open
#configure the web server
set web self 0.0.0.0 5006
set web open
default:
load def_conf
def_conf:
create bundle template B
set iface up-script /usr/local/etc/mpd5/vpn_up_mpd.pl
set iface down-script /usr/local/etc/mpd5/vpn_down_mpd.pl
set bundle enable compression
set bundle enable encryption
set iface idle 0
set iface disable proxy-arp
set iface enable tcpmssfix
set ipcp yes vjcomp
set ipcp ranges aaa.bbb.ccc.ddd/32 0.0.0.0/0
set ipcp dns xxx.yyy.zzz.ddd qqq.www.eee.rrr
set ccp yes mppc
set mppc yes e40
set mppc yes e56
set mppc yes e128
set mppc yes stateless
set ecp disable dese-bis dese-old
log -echo -ipv6cp -radius -rep
load common
common:
create link template PPPoE pppoe
set link enable no-orig-auth
set link max-children 300
set auth max-logins 0
load pppoe
pppoe:
set link action bundle B
set link enable multilink
set link yes acfcomp protocomp
set link disable chap pap eap
set link enable chap chap-msv1 chap-msv2 chap-md5
set link keep-alive 10 60
#pppoe on bge1 with service name "service_name0"
create link template bge1_0 PPPoE
set pppoe iface bge1
set link enable incoming
set pppoe service service_name0
#pppoe on bge1 with service name "service_name1"
create link template bge1_1 PPPoE
set pppoe iface bge1
set link enable incoming
set pppoe service service_name1
#pppoe on bge2 with service name "service_name0"
create link template bge2_0 PPPoE
set pppoe iface bge2
set link enable incoming
set pppoe service service_name0
Примечание:
Все строки, кроме комментариев и ссылок (строки которые заканчиваются
на ":"), в файле mpd.conf должны начинаться с отступа (пробела).
Блок startup:
В этом блоке описываются юзеры для консольного и web интерфейса MPD, а
также сами настройки консоли и web сервера. Если вам это не нужно, то
конфигурация может начинаться с блока default, а блока startup может
вообще не быть.
Блок default:
В сущности здесь описываются дефолтовые действия, в частности
загрузить дефолтовый конфиг, который загружается если не указывать
называние конфигурации при загрузке, как было описано выше.
Блок def_conf:
С этого блока начинается конфигурация самого сервера. Если в конфиг
файле описаны несколько конфигураций, у каждой должно быть свое
уникальное имя.
Далее будем описывать построчно:
create bundle template B - создаем бандл "B", он же будет выступать
в качестве шаблона
set iface up-script /usr/local/etc/mpd5/vpn_up_mpd.pl
set iface down-script /usr/local/etc/mpd5/vpn_down_mpd.pl - цепляем
внешние скрипты на события создания и закрытия туннеля ppp.
MPD может передавать данные в качестве аргументов на события
подключения и отключения пользователя к серверу:
$ARGV[0] - ngXX - номер тунеля
$ARGV[1] - inet
$ARGV[2] - aaa.bbb.ccc.ddd/32 - IP адрес сервера
$ARGV[3] - IP адрес, выданный пользователю
$ARGV[4] - логин пользователя
Эти аргументы вы можете использовать в perl скриптах vpn_up_mpd.pl и
vpn_down_mpd.pl
set bundle enable compression - разрешаем CCP (Compression Control
Protocol). Разрешаем только использование протокола, выбор протокола
сжатия описан ниже.
set bundle enable encryption - разрешаем ECP (Encryption Control
Protocol). Аналогично предыдущему пункту, выбор протокола сжатия
описан ниже.
set iface idle 0 - таймаут в секундах неактивности, по истечении
которого соединение принудительно разрывается со стороны сервера.
"0" - не разрывать (стоит по дефолту).
set iface disable proxy-arp - запрещаем proxy-arp. Этот параметр
полезен для имитации единой локалки для удаленных хостов.
set iface enable tcpmssfix - позволяет MPD управлять настройкой
входящих и исходящих TCP SYN сегментов таким образом, чтобы не
превышать MTU, допустимый на интерфейсе.
set ipcp yes vjcomp - разрешает компрессию заголовков (Van Jacobson TCP).
set ipcp ranges aaa.bbb.ccc.ddd/32 0.0.0.0/0 - пул IP адресов
сервера/клиентов
set ipcp dns xxx.yyy.zzz.ddd qqq.www.eee.rrr - dns сервера, отдаваемые
клиенту
set ccp yes mppc - включаем MPPC субпротокол сжатия/шифрования
set mppc yes e40 - включаем 40-bit MPPE шифрование
set mppc yes e56 - включаем 56-bit MPPE шифрование
set mppc yes e128 - включаем 128-bit MPPE шифрование
set mppc yes stateless - настройка, полезная при пакетлоссах (потерях)
log -echo -ipv6cp -radius -rep - уровни логгирования
load common - загрузка другого блока с именем common
Переходим к блоку common:
create link template PPPoE pppoe - создаем линк, он же будет выступать
в качестве шаблона
set link enable no-orig-auth - Обычно при использовании PAP или CHAP
авторизация происходит в начале соединения. Эта опция временно
выключает данное требование в случае если наш сервер является
единственным в сети, а клиенту вдруг не нравится запрос от сервера на
авторизацию.
set link max-children 300 - максимальное количество соединений для
этого шаблона
load pppoe - подгружаем следующий блок
set link action bundle B - накладываем на линк настройки бандла
set link enable multilink - опция позволяет создавать множественное
подключение PPP. Но в данном случае опция позволяет пропускать большие
пакеты (больше MTU) фрагментами. Что-то вроде фрагментации пакетов.
set link yes acfcomp protocomp - сжатие адресного поля, поля
заголовков и поля протокола. Для экономии нескольких байтов во фрейме.
set link disable chap pap eap - запрещаем данные протоколы проверки
пароля
set link enable chap-msv1 chap-msv2 chap-md5 - разрешаем протоколы
проверки пароля (необходимы для возможности включения шифрования
(Microsoft)).
set link keep-alive 10 60 - разрешает LCP пакеты. По умолчанию 5 40.
Можно отказаться от этой опции, поставив первое значение в "0".
create link template bge1_0 PPPoE - создаем линк bge1_0 и накладываем
настройки шаблона PPPoE
set pppoe iface bge1 - задаем интерфейс, где будет поднят наш сервис.
Может быть как физическим интерфейсом, так и вланом (vlan).
set link enable incoming - разрешаем входящие соединения
set pppoe service service_name0 - поднимаем сервис-нейм (service-name)
на заданном интерфейсе
Если у вас множество интерфейсов, то достаточно дописывать в конец
конфига последний видоизмененный блок, как показано в общем листинге.
Заключение
Из плюсов использования MPD в качестве PPPoE сервера хочу отметить
меньшую загрузку CPU, особенно в сочетании с использованием поллинга
(polling).
Для этого нужно собрать ядро с поддержкой поллинга:
options DEVICE_POLLING
options HZ=1000
После этого можно включить поллинг через /etc/sysctl.conf:
kern.polling.enable=1
kern.polling.user_frac=10
Последнее означает что система будет делить ресурсы CPU в соотношении
userland/kernel как 10/90. По умолчанию это значение 50/50.
Конфиг работает на версиях порта mpd-5.0, mpd-5.1. С версией mpd-5.1_1
наблюдались проблемы на серверной стороне. При невыясненных
обстоятельствах запускался второй процесс mpd5, который грузил CPU в
100%, а пользователи не могли подключиться. Пришлось откатываться на 5.1.
Вот, решил таки поспрошать народ, бо сам не справляюсь.
Итак.
Две машинки.
A)FreeBSD5.3, mpd3.18, role:PPPoE&PPTP server
B)FreeBSD7.2, mpd5.5, role:PPPoE client
Машина "А" с сессиями PPTP справляется на ура (и шифрование, и компрессия). А вот с PPPoE -- без шифрования и компрессии "B" подключается. А вот с шифрованием -- нет. Компрессия в последнем случае неактуальна, хотя и хотелось бы. А вот шифрование критично.
Теперь вопрос. Кто-то поднимал PPPoE с шифрованием на mpd?
В принципе, пробовал gif с racoon-ом. Хреновенько работает. Пока нет нагрузки на туннель -- всё замечательно. А вот сетевой сканер после сканирования листа пытается отдать картинку через туннель на файлохран, и обламывается. При этом в логах выползает потеря ключа сессии и переконнект обеих связных машинок. Аналогично и с RDP-клиентами, отваливаются сессии. Но там проще, закрыл-открыл и работай. Хотя юзвери негодуют. Да, пока канал между связными был узкий -- таких проблем не было. А как юзверей побольшало -- так канал сделали потолще. И пошло-поехало...
Кто-то с таким сталкивался?
а у меня проблема при старте mpd5 в логах нечто следующее
[bge1] system:command "/sbin/ifconfig" returned 256
PPPoE: can't bring up interface bge1
[bge1_0] PPPoE Error creating ng_pppoe node on bge1
