ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Метки статьи: ‘pppoe’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Получил очередное письмо с вопросом о демоне pppoed.

Решил, написать несколько статей на эту тему. Я конечно понимаю, что многое уже в Инете написано, но я, как обычно, изложу свое видение данного вопроса.

Как известно на FreeBSD одну и ту же задачу можно решить несколькими способами.

Задача поднять PPPoE сервер никак не отрицает данного утверждения.

Это можно сделать как и на демоне mpd5, который находится в портах  /usr/ports/net/mpd5 и который придется собрать и установить , так и на уже встроенном во FreeBSD демоне pppoed:

pppoed — handle incoming PPP over Ethernet connections

который нужно только настроить и все.

Располагается файл pppoed тут:  /usr/libexec/pppoed

Упреждая вопросы:

  • Что такое PPPoE ?
  • Как работает протокол PPPoE ?
  • и т.д. и т.п.

Отвечаю: Читайте статью «PPPoE :: Теория вопроса»

Итак приступим к настройке.

1. Конфиг файлы

Располагаются в папке  /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 that is 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 since the connection was established.
         PACKETSIN        This is replaced with the number of packets received since 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

Что ещё можно рассказать.

I. Патч (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

II. Обламываем домашние роутеры 🙂

Многие провайдеры озадачиваются вопросом как бы сделать так, чтобы пользователь не «раздавал» Интернет соседям через домашний роутер.

Т.е. подключается один пользователь, который покупает себе домашний роутер (например тот же 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 забыл внести имя 🙂 Ну с кем не бывает.

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

Может кому нить и пригодится данная информация 😉

III. Как подключить свой комп под 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

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 5, среднее: 2,60 из 5)
Загрузка...
Отправить на почту Отправить на почту

Заметка

итак, OpenBSD 4.4

user level ppp (т.к. kernel level ppp мне не удалось подружить с chap-ом)

для «автозапуска рррое» достаточно создать файл
/etc/hostname.tun0, в котором написать:

!/usr/sbin/ppp -ddial pppoe

все настройки относительно самого pppoe находятся в файле:
/etc/ppp/ppp.conf

пример содержимого:

default:
Set log Phase Chat LCP IPCP CCP tun command
Disable ipv6cppppoe:
set device "!/usr/sbin/pppoe -i xl0"
set mtu max 1492
set mru max 1492
set speed sync
disable acfcomp protocomp
deny acfcomp
set authname my-pppoe-login
set authkey my-pppoe-password
add default HISADDR

xl0 — «имя» реальной сетевой карточки, через которую цепляемся к pppoe-серверу
логин-пароль необходимо указывать без кавычек

к сожалению, правильно бы было указать пару «логин-пароль» не в конфиге ррр, а в специальном файле /etc/ppp/chap-secrets (а в конфиге оставить только «логин»)
но — при удалении пароля из ppp.conf соединение не поднимается

ну и самое главное — как рестартовать такое pppoe-соединение

# kill -9 `cat /var/run/tun0.pid`
# ifconfig tun0 destroy
# sh /etc/netstart tun0

пара ньюансов:

  1. увы, не факт, что в tun0.pid окажется «правильный» process-id
  2. мне не нравится «sh /etc/netstart tun0«, так что «когда будет время» — расковыряю netstart и сделаю «как надо»
  3. не забываем про sysctl:

net.inet.gre.allow=1
net.inet.ip.forwarding=1

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: GrayCat
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 3,50 из 5)
Загрузка...
Отправить на почту Отправить на почту

Провайдеры предоставляющие доступ по 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 service name: [$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 service name: [$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 сервера, скрипт исключит мак адрес своего сервера (на котором он был запущен).

Удачного вам поиска 😉

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Авторы: Николаев Дмитрий (virus (at) subnets.ru) и Панфилов Алексей (lehis (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 3,67 из 5)
Загрузка...
Отправить на почту Отправить на почту

В виду участившихся вопросов по работе 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=0x8863.

Наблюдать можно следующим образом:

tcpdump –n –e -i fxp0 ether proto 0x8863

В свою очередь, 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=0x8864.

Наблюдать можно следующим образом:

tcpdump –n –e -i fxp0 ether proto 0x8864

В итоге устанавливается 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

Ссылки:

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 4,75 из 5)
Загрузка...
Отправить на почту Отправить на почту

В данной статье рассматривается возможность использование 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.

Ссылки:

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Folio
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту