| 1.1, kveler (ok), 17:13, 26/01/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 объясните мне глупому - зачем использовать два файрвола (ipfw и pf) ? | | |
| |
| 2.2, suntech (?), 17:49, 26/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
некоторые люди привыкли к синтаксису ipfw, но им также приятны возможности pfnat | | |
|
| 1.3, BB (??), 18:11, 26/01/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Особенно зажгло вот это :
pass quick from $ext_ip to any # Разрешаем траф
pass quick from any to $ext_ip # на внешнем ip
зачем тогда FW городить ?:)) | | |
| |
| 2.20, Alex (??), 18:34, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Особенно зажгло вот это :
>pass quick from $ext_ip to any # Разрешаем траф
>pass quick from any to $ext_ip # на внешнем ip
>
>зачем тогда FW городить ?:))
Зажгло говоришь? А как ты интересно собираешься прикрывать сервисы, которые не должны быть доступны клиенту из локально сети? | | |
|
| 1.4, Daemon (??), 18:14, 26/01/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
А нет ли возможности хранить в mysql хеши паролей(sha256 к примеру)? Не хоцца очень в открытом виде... | | |
| |
| 2.5, cybersun (?), 18:28, 26/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
 > А нет ли возможности хранить в mysql хеши паролей(sha256
>к примеру)? Не хоцца очень в открытом виде...
abills.sourceforge.net - там хранение паролей в мускуле происходит в шифрованном виде.
| | |
| |
| |
| 4.7, kir (??), 20:22, 26/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
можно в хеше - токо это должна позвонять сама бил систем) | | |
| 4.31, AsmodeuS (?), 13:06, 30/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
>Тогда ты не сможешь испльзовать CHAP, только PAP. Выбирай что безопасней?
Abills - Auth method: PAP, CHAP, MS-CHAP, MS-CHAPv2
Если шыфровать с ключём через DECODE, ENCODE то все ок
| | |
|
| 3.13, guest (??), 09:49, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
 А какая лицензия у данного проекта?
Что-то ни слова про это не нашел... | | |
|
|
| 1.8, ABATAPA (?), 23:58, 26/01/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Не отображены проблемы w2k MTU Discovery / MSS.
Linux + pptpd + FreeRadius + FreeNibs + iptables = лучше в разы. | | |
| |
| 2.12, daff (?), 06:43, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
какие проблемы, смотри конфиг:
set iface enable tcpmssfix
> Linux + pptpd + FreeRadius + FreeNibs + iptables = лучше в разы.
куча отдельных ppp процессов = лучше в разы ?
| | |
| |
| 3.18, Dvorkin (??), 12:19, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
 да. стабильнее.
сколько раз я патчил MPD 3.xx чтобы добиться от нее не выпадание в осадок под высокой нагрузкой... нихрена! ну невозможно сделать абсолютно без ощибок такую программу. чуть где-то проиходит рассинхронизация по времени, состоянию layer'ов или еще какая фигня - бумц, и корка! и сотни пользователей Offlie. :( и рвеш на попе волосы.
не, pptpd в Линукс в этом смысле надежнее. а количество одновременных порцессов... ну и фиг что их сотни. В Линукс более разумно сделана система форков. MPD - это вчерашний день
| | |
| |
| 4.19, Alex (??), 18:25, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
poptop вполне нормально работает и под FreeBSD.......
Касательно mpd корок пока не наблюдал.... | | |
| 4.29, daff (?), 08:12, 28/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
>да. стабильнее.
>сколько раз я патчил MPD 3.xx чтобы добиться от нее не выпадание
>в осадок под высокой нагрузкой... нихрена!
не замечал
| | |
|
|
| 2.24, fa (??), 19:36, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >Не отображены проблемы w2k MTU Discovery / MSS.
>
>Linux + pptpd + FreeRadius + FreeNibs + iptables = лучше в
>разы.
Извините за оффтопик, но развивается ли FreeNibs? На nibs.net.ua уже давно нет новых версий. | | |
|
| 1.10, Jay (??), 01:00, 27/01/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Насколько я понял, в вышеописанном материале pf используется в качестве файрволла и NAT'а, а ipfw - в качестве шейпера. По идее можно было использовать altq из pf. Остается две причины для использования ipfw - NeTAMS и возможность выставлять правила ipfw с радиуса (описана в документации к mpd). Но судя по pkg-descr от netams, оно умеет получать данные о траффике и другими способами, кроме divert (netflow, например). Вторая возможность в статье не используется. Поэтому от использования ipfw в данной статье можно и отказаться.
Также очень полезно применить патч, позволяющий отбрасывать пользователей с mpd (искать на странице патчей проекта mpd на sf.net).
Насчет хешированных паролей - есть возможность хранить пароли хешированными и использовать MS-CHAPv2, но при этом хеши должны быть NTLM. Либо использовать PAP и хранить MD5-хеши паролей.
Где-то так :)
--
Jay | | |
| |
| 2.14, Alex (??), 11:03, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
Altq не годится - он вешается на конкретный интерфейс. Или я не прав?
На ngX он не вешается раз - и как шейпить клиента, интерфейс для которого постоянно меняется - это два? | | |
| |
| 3.27, Jay (??), 01:06, 28/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Да, похоже, что altq требует обязательного указания интерфейса.. И ничего не сказано, можно ли в данной конструкции указать имя драйвера (ng), как в случае с обычными правилами pf.
С другой стороны, в приведенном в конфиге примере шейпинг не зависит от конкретного клиента, а включается на всю сеть. Если не важен траффик между клиентами, можно включить altq на внешнем интерфейсе. Либо, если важен, написать N правил на каждый ngX. Все равно в большинстве случаев mpd.conf и mpd.links генерятся скриптом. Добавить туда создание правил для pf не так сложно.
Если же нужно шейпить именно конкретного клиента, то тут поможет только ipfw и соответствующая настройка радиус-сервера. Либо патчить mpd для достижения аналогичного поведения для pf. | | |
|
|
| |
| 2.15, Alex (??), 11:05, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
>pf не умеет дивертить?
Насколько я знаю IPDIVERT это фича IPFW - ничего с этим связанного в pf не нашел... | | |
|
| |
| 2.17, Alex (??), 12:17, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
Аргументы в студию?
Какие есть альтернативы?
Чем лучше pptpd poptop, создающий на каждый коннект отдельный процесс?
Касательно pptp версий >= 1.2... - там крупные траблы с Вин-клиентами - часто возникает ошибка "Замыкание на себя". У них в рассылке это обсуждалось и не пофиксили... | | |
| |
| 3.21, buzi (??), 18:41, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
аргумент один - загрузка проца под 100% при количестве пользователей около 100.. цифра не строгая.. но примерно в этом районе...
альтернатива - poptop - плохая в смысле создания на каждый коннект отдельного процесса.. в это с вами согласен..
другая альтернатива - искать другой метод доступа в интернет 8) | | |
| |
| 4.28, daff (?), 08:06, 28/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
>аргумент один - загрузка проца под 100% при количестве пользователей около 100..
1) 3.18 надо патчить для работы с ng_tcpmss
2) сетевухи надо выбираить не напряжные для процессора (em, fxp) а не rl всякие
| | |
|
| 3.23, Dvorkin (??), 19:15, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Аргументы в студию?
>Какие есть альтернативы?
>Чем лучше pptpd poptop, создающий на каждый коннект отдельный процесс?
>Касательно pptp версий >= 1.2... - там крупные траблы с Вин-клиентами - часто возникает ошибка "Замыкание на себя". У них в рассылке это обсуждалось и не пофиксили...
прочтя мои нижеизложанные мысли, как вы думаете, лучше иметь форкающийся pptp сервер или монолитный? :) ответ очевиден.
я искрене считаю, что если в системе не реализован хотя-бы "быстрый форк" как в Линукс и есть существенная разница, существует один <xxx> процесс, который ест 70% CPU или 70 дочек <xxx> в среднем по 1% CPU - это система для лузеров.
| | |
| |
| 4.30, daff (?), 08:22, 28/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
> я искрене считаю, что если в системе не реализован хотя-бы "быстрый форк" как в Линукс и есть существенная разница, существует один <xxx> процесс, который ест 70% CPU или 70 дочек <xxx> в среднем по 1% CPU - это система для лузеров.
переключение контекста весьма не бесплатная опреация | | |
| |
| 5.32, Dvorkin (??), 14:45, 30/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
>> я искрене считаю, что если в системе не реализован хотя-бы "быстрый форк" как в Линукс и есть существенная разница, существует один <xxx> процесс, который ест 70% CPU или 70 дочек <xxx> в среднем по 1% CPU - это система для лузеров.
>
>переключение контекста весьма не бесплатная опреация
переключением можно пренебречь, если использование CPU повысится даже на 5%, но при этом тебе в ухо не будут орать что ты @#@$% полтыщи юзеров, у которых отвалился коннект
| | |
|
|
|
| 2.22, Dvorkin (??), 19:10, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
>mpd начнёт кашлять примерно на сотне пользователей...
выкиньте вашу машину. это не сервер. и даже не рабочая станция :)
у меня максимум 650 клиентов тянул + Radius + локальная база Mysql
машина вполне обычная. пень четвертый. на уровне нормальной современной рабочей станции. я думаю, если его поставтиь на более быструю машину это все равно будет для MPD рекордом. ну не верю я что такой дизайн программы способен потянуть сколько-нибудь большое количество линков.
загрузка была в пике 15% Mysql + 20% MPD + 5% Radius.
проблема не в загрузке проца. проблема в том, что у MPD сносит крышу, когда в некоторых состояниях на нескольких слоях абстракций его автомата происхоит рассинхронизация состояний этих самых слоев. причиной может быть некоторое событие в системе, которое дает задержку в выполнении самого MPD (как тут не вспомнить прелести Линукс с его великолепным планировшиком ;)) либо просто очевидная недоработка в автомате сотояний (это есть, не спорьте со мной ;) и разработчики сами не представляют, как это исправить ) исправить мне это после нескольких неудачных попыток так и не удалось. да и не хотелось чтобы все проблемы обрыва конекта клиентов спихнули на меня.
дополнительная проблема MPD - изредка пропадание аккаунтинговых пакетов. выдает ошибку сокета и ретрансфер не делает. поскольку, например, это был стоповый пакет и линк на момент ретрансфера Radius-пакета уже исчез из таблицы. | | |
| |
| 3.26, Jay (??), 00:35, 28/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
У меня mpd-3.18 в бытность работы в ISP тянул больше сотни и не кашлял.. Только радиус-сервер пришлось затачивать. Проблему с обрывом коннектов я уже как-то описывал в данном форуме.
Связана она с тем, что mpd-3.x однопоточное приложение, соответственно, пакеты радиуса обрабатываются в том же потоке, что и все остальные. В результате, при задержке ответа от радиуса получаем затык всего и отстреливание клиентов по таймауту. Сюда же относится проблема с неким ASSERT'ом (точно не помню уже), по которому падает mpd. Сюда же относится проблема с невозможностью иногда подключиться сразу, потому что в это время осуществляется ожидание ответа от радиус-сервера. Решение - затачивать радиус-сервер для сокращения времени на ответ.
Другие варианты - переходить на mpd4, но в его стабильности я пока не уверен (скоро протестирую, он мне будет нужен), или переходить на poptop + pppd, но эта связка значительно сильнее грузит процессор (хотя для не-FreeBSD альтернативы нет).
Еще рекомендую перейти, где это возможно на pppoe, как более стабильный протокол с меньшей избыточностью в инкапсуляции. Но для корректной работы pppoe и w2k нужно патчить mpd, поскольку пропатчить w2k значительно труднее :) Проблема в том, что w2k не договаривается с NAS'ом насчет MRU. Это баг именно в w2k (доказано автором драйверов RASPPPoE), но у MS свой взгляд на мир.
| | |
| |
| 4.33, Dvorkin (??), 14:53, 30/01/2006 [^] [^^] [^^^] [ответить]
| +/– |
>У меня mpd-3.18 в бытность работы в ISP тянул больше сотни и
>не кашлял.. Только радиус-сервер пришлось затачивать.
если ты пропустил мои сообщения, повторюсь: на моей машине предел для MPD - 650 линков онлайн. Под такой нагрузкой он валился каждый день. Было очень неприятно.
случаи разные случаются. невозможно сделать так, чтобы гарантировать ответ от Радуса за ожидаемое очень короткое время. ну невозможно.
....
> Сюда же относится проблема с неким ASSERT'ом (точно не помню
>уже), по которому падает mpd. Сюда же относится проблема с невозможностью
>иногда подключиться сразу, потому что в это время осуществляется ожидание ответа
>от радиус-сервера. Решение - затачивать радиус-сервер для сокращения времени на ответ.
да. а ассерт этот возникает из-за рассинхронизации состояний логических слоев в MPD. да, из-за таймаутов.. я пытался переделать логику автомата обработки состояний, но безуспешно. от MPD пришлось отказаться. сейчас я чудовищно рад этому :)
| | |
|
|
| 2.25, atdp03 (??), 22:55, 27/01/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Вот незадача-то.
# ifconfig | grep ng | grep -c UP
139
# ps -ux | grep mpd
root 7366 5.7 0.7 8076 6952 ?? Ss 8:16AM 49:37.91 /usr/local/sbin/mpd -b
Что я не так делаю? | | |
|
| 1.36, Valera (??), 18:58, 24/04/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Привет!!!
Есть Много статей по билингу - но нигде Я не встречал освещение вопроса - как настраивать фаер...
Тоесть - у Меня все прекорасно работает и пользователи подключены к билингу и Сервер подключен к Инету - но пользователи НЕ ВИДЯТ ИНЕТ. И о том, что надо делать, что бы ОНИ ЕГО ВИДЕЛИ -НИ СЛОВА!!!! | | |
| |
| 2.38, Nu ja. (?), 19:42, 24/04/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Вот настройки...
>Есть связка FreeBSD+FreeRADIUS+FreeNIBS+MPD - все работает.
>Сервер подключен в Инет. Пользователи подключаются к Серверу - но не пингуют
>Инет!!!
>Далее подробно, что делаю...
Мил человек!
Имей совесть, не пости одно и то же по десять раз.
Ты что, нервный или спаммер?
Пропадает вся охота даже призадуматься над твоей проблемой.
| | |
|
| 1.39, Valera (??), 23:43, 24/04/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
(подключен Инет на Сервере)
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 193.238.152.25 --> 193.238.152.1 netmask 0xffffffff
(подключен пользоваетель к MPD)
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1400
inet 192.168.10.1 --> 192.168.11.200 netmask 0xffffffff
Собственно надо, что бы между ng0 и tun0 был свободный проход, или другими словами - все запросы с ng0 пересылались на tun0
Вот и все...
И еще - после подключения Винды:
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.10.1 192.168.10.97 21
0.0.0.0 0.0.0.0 192.168.11.200 192.168.11.200 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.10.0 255.255.255.0 192.168.10.97 192.168.10.97 20
192.168.10.1 255.255.255.255 192.168.10.97 192.168.10.97 20
192.168.10.97 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.10.255 255.255.255.255 192.168.10.97 192.168.10.97 20
192.168.11.200 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.11.255 255.255.255.255 192.168.11.200 192.168.11.200 50
224.0.0.0 240.0.0.0 192.168.10.97 192.168.10.97 20
224.0.0.0 240.0.0.0 192.168.11.200 192.168.11.200 1
255.255.255.255 255.255.255.255 192.168.10.97 192.168.10.97 1
255.255.255.255 255.255.255.255 192.168.11.200 192.168.11.200 1
Основной шлюз: 192.168.11.200
| | |
|
