Раздача интернета, авторизация на стороне провайдера

[talyan]

Приветствую!
Имеется задача - провайдер раздает интернет по pppoe, необходимо поднять сервер (шлюз), который бы авторизовал пользователей и пускал их каждый в свой канал.
Поясню ситуацию. Имеется сетка со своими ресурсами, несколькими шлюзами в интернет. Подключили нового провайдера, часть абонов "вытащили" в отдельный vlan и настроили (через raspppoe) каждому доступ в интернет. Система оказалась работоспособной, но не живучей - куча абонов в одной сетке, проблема при подключении их к ресурсам основной сети...
Появилась мысль - настроить шлюз, который бы подымал pppoe сессию до провайдера на каждого зарегистрированного абона (логины и пароли имеются), а пользователи из сети попадали каждый на свой канал интернета (по аналогии с другими каналами). В сети имеется свой сервер авторизации, пользователи имеют фиксированные ip-адреса, их можно отмаршрутизировать на новый шлюз. Фактически задача стоит пустить какой-то конкретный ip по какому-то конкретному маршруту.
Осталось только придумать, как такое можно соорудить. Может, кто знает?

[root]

кроме NAT`а (static NAT (адрес в адрес)) ничего и не придумаешь

т.е. натишь IPшник клиента (в локалке) в IPшник полученный по PPPoE на сервере

а зачем такие заморочки ?
почему нельзя подключить сервер одним каналом к прову (двумя каналами к разным и т.п.) и раздать инет с этого же сервера вниз (с PPPoE или без него) ?

[talyan]

заморочки еще те
тут политический вопрос - инет предоставляется анлимный и дешевый (по отношению к другим), и провайдер хочет контролировать, кого мы подключаем (фактически, мы перепродаем наших клиентов).
у меня вопроса еще 2 - на чем реализовать подключение шлюза к провайдеру - на mpd? я еще не сильно с этим знаком, но думаю познакомиться
и как можно делить скорость (предполагалось, что мы купим DSLAM, но так он фактически не нужен - мы раздаем нашу сеть по ethernet, никаких модемов ставить у абонентов не предполагалось); пока все барахтаются в общей куче, но канал постепенно будет расширятся, в зависимости от числа абонентов, и не хотелось бы, чтобы кто-то "откусил" половину пирога.... (ну, кроме админа

[lehisnoe]

заморочки еще те
тут политический вопрос - инет предоставляется анлимный и дешевый (по отношению к другим), и провайдер хочет контролировать, кого мы подключаем (фактически, мы перепродаем наших клиентов).

Я понимаю перепродавать услуги, но перепродавать клиентов это жесть - работорговлей попахивает )))

у меня вопроса еще 2 - на чем реализовать подключение шлюза к провайдеру - на mpd? я еще не сильно с этим знаком, но думаю познакомиться

Да, варианта два:
1. pppoed - входит в стандартную поставку FreeBSD. Плюсы: падение процесса ррроеd не сказывается на уже поднятых туннелях. Минусы - реализует туннелирование на юзерлевел.
2. mpd - ставится из дерева портов /usr/ports/net/mpd[45]*. Плюсы - реализует туннелирование на уровне ядра. Минусы - падение процесса mрd убивает уже поднятые туннели.

и как можно делить скорость (предполагалось, что мы купим DSLAM, но так он фактически не нужен - мы раздаем нашу сеть по ethernet, никаких модемов ставить у абонентов не предполагалось);

либо ipfw pipe либо так.

пока все барахтаются в общей куче, но канал постепенно будет расширятся, в зависимости от числа абонентов, и не хотелось бы, чтобы кто-то "откусил" половину пирога.... (ну, кроме админа

Обычно, админа не допускают к дележу пирогов

[talyan]

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

В общем, навоял пока вот такую систему (см конфиги ниже).
Сам пока ничего не придумывал, все где-нибудь по-строчке надергал. После того, как у меня "пошел интернет" стал читать мануалы и прочее, чтобы понять - как же оно все-таки работает
Сразу скажу - топорный вариант, но работало нормально примерно на количестве подключений до 70, а потом стало вылетать в kernel panic...
(в конфигах возможны где-то неточности, потому что брал из кусков рабочих конфигов... которых уже с десяток набралось

mpd.conf:

Код: Выделить всё

default:
    load n707070
    load n808080
    #load и т.д.
n707070:
    create bundle static b-n707070
    set iface route default
    set iface up-script /usr/local/etc/mpd5/up.sh
    #set iface down-script /usr/local/etc/mpd5/down.sh
    set iface enable tcpmssfix
    set ipcp ranges 0.0.0.0/0 0.0.0.0/0
    set bundle disable compression
    create link static l-n707070 pppoe
    set link action bundle b-n707070
    set auth authname n707070
    set auth password xxxxxxxxxx
    set link max-redial 0
    set ling mtu 1412
    set link enable multilink
    set link keep-alive 10 60
    set pppoe iface vr0
    set pppoe service ""
    open

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

up.sh:

Код: Выделить всё

#!/bin/sh
route delete 91.91.91.91

-этот скрипт добавил, потому что подключения, начинающиеся со 2-го и далее, при подключении не получали ip-адрес, хотя интерфейс ng создавался... в логах было примерно такое:
IFACE: Add route 0.0.0.0/0 91.91.91.91 failed: File exists
down.sh пока не пригодился

(Тут еще одна загвоздка может быть - уже несколько позже прочитал, что при такой ситуации, когда все пакеты уходят в один и тот же шлюз, может (или должно?) ничего не работать (хотя на практике убедился, что как-то оно все же работает). И что поможет только ECMP... так что пока обновляю систему до 8-й версии (с 7.1), а там посмотрим, что это такое)

PBR делал по вот такому примеру: http://ipfw.ism.kiev.ua/pbr.html
т.е. куча natd и ipfw примерно такого содержания (пример для 2-х пользователей -
тут тоже делал аналогично конфигу mpd - большая часть текста конфигов сгенерена скриптом):

nat.up:

Код: Выделить всё

#!/bin/sh
natd -n ng0 -p 8998 -dynamic
natd -n ng1 -p 8999 -dynamic

rc.ipfw:

Код: Выделить всё

#!/bin/sh
ipfw -q -f flush
ipfw -q -f pipe flush
iif="rl0"
oif="vr0"
cmd="ipfw -q add"

ng0_ip=`ifconfig ng0 | grep inet | awk '{print$2}'`
ng1_ip=`ifconfig ng1 | grep inet | awk '{print$2}'`
#и т.д.

n707070="10.1.1.1"
n808080="10.1.1.2"
#и т.д.

lan_in2="10.0.0.0/8"

$cmd 1 pipe 257 ip from $lan_in2 to any in via $iif
$cmd 2 skipto 1000 all from $lan_in2 to any
$cmd 3 pipe 256 ip from any to $lan_in2 out via $iif
$cmd 4 skipto 1000 all from any to $lan_in2

$cmd 1000 divert 8998 ip from $n707070 to any
$cmd 1001 fwd 91.185.5.169 ip from $ng0_ip to any
$cmd 1002 divert 8998 ip from any to $ng0_ip

$cmd 1003 divert 8999 ip from $n808080 to any
$cmd 1004 fwd 91.185.5.169 ip from $ng1_ip to any
$cmd 1005 divert 8999 ip from any to $ng1_ip
# и т.д. для каждого ip-адреса

ipfw pipe 256 config mask dst-ip 0xffffffff bw 256Kbits queue 30 gred 0.002/3/9/0.1
ipfw pipe 257 config mask src-ip 0xffffffff bw 512Kbits queue 30 gred 0.002/3/9/0.1

$cmd 9976 allow ip from any to any via lo0
$cmd 9977 deny ip from any to 127.0.0.0/8
$cmd 9978 deny ip from 127.0.0.0/8 to any
$cmd 9979 check-state
$cmd 9980 deny all from any to any frag
$cmd 10000 allow ip from any to any


___

Вот так вот все это "взлетело"... ненадолго, потому что начали появляться нюансы в работе...например, случился реконнект на одном из интерфейсов, сменился внешний ip-адрес, потребовалось перегрузить правила на файрволе или перезапустить natd (тоже отваливался). Летало не долго

В общем, сейчас думаю над NAT-ом, который можно поднять через конфиг mpd (правда, ни одного рабочего примера пока не нашел - одни такие же, как я, интересующиеся)
set iface enable nat
и над общей оптимизацией...

Если кто поделится интересными идеями или ссылками, буду рад.

[root]

-этот скрипт добавил, потому что подключения, начинающиеся со 2-го и далее, при подключении не получали ip-адрес, хотя интерфейс ng создавался... в логах было примерно такое:
IFACE: Add route 0.0.0.0/0 91.91.91.91 failed: File exists
down.sh пока не пригодился

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

Код: Выделить всё

set iface route default

я все равно не понимаю зачем такая мороченная схема ? описыать стока в конфиге mpd + поднимать стока натов.... жесть...
если зачада тупо сводится к тому, что нуна часть юзеров пускать в один канал, а часть в другой, подключаясь к каналам по pppoe, то я бы сделал так:
1. через стандартный ppp.conf коннекитлся к провам (см. http://subnets.ru/wrapper.php?p=51#client_pppoe)
соответственно одного из них сетил бы как шлюз по умолчанию
2. после установки ppppoe с провами поднимал бы на полученных от них ипах наты (2 прова = 2 ната), юзая UP скрипт
3. т.к. дефолт смотрит на одного из провов, то для второго поднял бы PBR на основе PF (pf.conf, пример есть в "советах" - http://subnets.ru/wrapper.php?p=32 )
4. настроил mpd для юзеров (http://subnets.ru/blog/?p=192)
5. создал бы в ipfw таблицы (table) по одной на каждого прова и соответственно правила с использованием этих таблиц
6. пихал бы юзера, в зависимости от того через какого прова он должен "ходить", в ту или иную таблицу
все

а так, с таким кол-во NATD (этот "тип" NAT`а больше всех "кушает" проц) я совсем не удивлен, что система выпадает в "корку" (kernel panic)

[talyan]

даже без опции

Код: Выделить всё

set iface route default

все равно устанавливается default route - поэтому каждый раз при поднятии нового pppoe надо запускать скрипт up.sh

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