Jump to content
Калькуляторы

pptp сервер на FreeBSD 7.2, mpd 5.3 хэппиэнд

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

Выкладываю так, для информации.

Что имеем:

Сервер m/b S5000VSA, 8Gb Ram, 2 x Xeon E5420, 2 встроенные Intel PRO/1000 EB.

Входящий канал 1Gbit/s, по нему идет интернет + городские ресурсы, так что нагрузка не хилая.

Количество онлайн клиентов pptp 800-900.

История:

Пока по входящему каналу шёл только интернет со скоростью около 50Мбит/с, pptp сервер прекрасно работал и на poptop под FreeBSD 6.3 AMD64. Но когда подключили городские ресурсы на весь гигабит, машина стала медленно умирать, все 8 процов были загружены на 100%.

Решили переходить на mpd. Сделал тюнинг системы и поставил mpd версии 5.3. Отлично, загрузка процов нравится. Idle их 75-80%. Радуемся не долго, часа через 2 сервер уходит в ребут. Почитал на форумах, оказалось я не одинок, проблема известная. Куча разных советов как с этим бороться, в основном говорят о проблеме из-за шейперов на dummynet, хреновых интеловских сетевых дровах, кривом netgraph-е и железе и т.п.

Что не делал, один черт, то сервер ребутнется, то зависнет насмерть. Попробовал версии mpd 5.2, 5.1 проблема та же. Может проработать 2 часа, а может и 8.

Прочитал что с 4 версией проблем меньше. Ставлю mpd 4.4.1, и быть не может, наконец то система работает 1 день без перезагрузки. Но... рано радоваться через некоторое время опять зависает. Перегружаем, работаем еще день и т.д.

Выношу радиус сервер и шейпер(dummynet) на другой сервер, этот пытаюсь максимально разгрузить, остается только mpd, ipcad. Ставлю драйвера на сетевухи от yandex, кручу тюнинг системы. Один черт, НЕ помогает.

Рано утром иду обновлять систему до 7.2 Amd64 релиз, ставлю mpd 5.3, сетевые драйвера 6.9.12 от интела и довольный иду спать, в надежде что в 7 версии было много изменений в сетевой подсистеме, и это должно помочь. Поспал... но не долго, через 3 часа ребут. В логах ничего интересного, одно только заметил, что перезагрузка произошла ровно в 10:30:00.

И здесь появляется мысль: у меня по крону раз в 15 минут, скриптом идет обновление arp таблицы, и у тех клиентов кто ушел в минус маки забиваются нулями. Ну что делать, и этот скрипт выношу на другой сервер...

И ВОТ ОНО ЧУДО!!! сервер работает, без перегрузов и зависонов день, два, три...

 

Пытаюсь разобраться, что происходило:

Клиент подключен к впн серверу и баланс уходит в минус, а радиус еще не успел его отключить от впн сервера. В это время проходит отработка скрипта по замене маков клиентов с минусовым балансом, и у netgrph-а похоже сносит от этого голову, а он соответственно тянет за собой всю систему.

Ну это чисто мои предположения...

 

Главное получили Vpn сервер на mpd5.3 под FreeBSD 7.2 AMD64 который работает стабильно. Idle процессоров в пиковое время 75-90%.

То что надо...

 

Выкладываю свои конфиги, которые получились после многократных тюнингов (сразу оговорюсь что они не претендуют на идеальность)

 

/boot/loader.conf:

if_em_load="YES"

vm.kmem_size=1G

vm.kmem_size_max=1G

kern.ipc.semmni=256

kern.ipc.semmns=512

kern.ipc.semmnu=256

net.inet.tcp.syncache.hashsize=1024

net.inet.tcp.syncache.bucketlimit=100

net.inet.tcp.tcbhashsize=4096

kern.ipc.nsfbufs=10240

hw.em.rxd=1024

hw.em.txd=1024

net.graph.maxalloc=2048

kern.ipc.maxpipekva=200000000

 

/etc/sysctl.conf:

kern.ipc.shmall=65536

kern.ipc.shmmax=268435456

net.inet.tcp.blackhole=2

net.inet.udp.blackhole=1

kern.ipc.nmbclusters=262144

kern.ipc.somaxconn=4096

kern.ipc.maxsockets=204800

kern.ipc.semmap=512

kern.maxfiles=204800

kern.maxfilesperproc=200000

net.inet.ip.portrange.first=1024

net.inet.ip.portrange.last=65535

net.inet.ip.portrange.randomized=0

net.inet.tcp.recvspace=65536

net.inet.tcp.sendspace=65536

net.inet.tcp.maxtcptw=40960

net.inet.tcp.msl=30000

net.inet.tcp.syncookies=1

net.inet.tcp.nolocaltimewait=1

net.inet.tcp.fast_finwait2_recycle=1

kern.ipc.shm_use_phys=1

net.inet.icmp.icmplim=1000

net.inet.ip.intr_queue_maxlen=5000

net.inet.ip.fastforwarding=1

net.graph.maxdgram=128000

net.graph.recvspace=128000

net.isr.direct=1

 

Конфиг kernel:

за основу взят GENERIC, выкинуты все ненужные дрова, и добавлено:

options IPFIREWALL

options IPDIVERT

options IPFIREWALL_VERBOSE

options IPFIREWALL_VERBOSE_LIMIT=100

options IPFIREWALL_FORWARD

options NETGRAPH

 

Mpd.conf:

startup:

set user admin mypass admin

set console self 192.168.1.1 5055

set console open

 

default:

load pptp_standart

 

pptp_standart:

create bundle template B

set iface disable proxy-arp

set iface idle 0

set iface enable tcpmssfix

set ipcp no vjcomp

set ipcp ranges 10.0.0.1/32 0.0.0.0/0

set ipcp dns 192.168.1.1

set bundle disable compression

set bundle disable encryption

set ccp no mppc

set mppc no e40

set mppc no e128

set mppc no stateless

create link template L pptp

set link action bundle B

set link disable multilink

set link no acfcomp protocomp

set link no pap chap

set link enable chap-msv2

set link keep-alive 30 90

set link mtu 1460

set link enable incoming

set link enable peer-as-calling

set pptp self 192.168.1.1

load radius

radius:

set radius config /usr/local/etc/mpd5/radius.conf

set radius server 192.168.1.2 mysecurity 1812 1813

set radius retries 3

set radius timeout 20

set radius me 192.168.1.1

set auth acct-update 300

set auth enable radius-auth

set auth enable radius-acct

set auth disable internal

Edited by vadius

Share this post


Link to post
Share on other sites

А зачем забивать нулями маки? Из того же скрипта легко можно и интерфейс через админку mpd прибить, что гораздо надежнее будет...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

не пробовали чем нибудь другим забивать? по-моему все нули не лучшая заглушка.

Share this post


Link to post
Share on other sites

в ipguard'е, к примеру, de:ad:9a:c3:20:7f

Share this post


Link to post
Share on other sites

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

В итоге обслуживанием ARP-сегмента займётся держатель ресурса в пределах своего топологического сегмента. Будьте уверены, он найдет способ ответить на arp-lookup раньше Вашего маршрутизатора, а там базу паролей уже несложно будет собрать.

Share this post


Link to post
Share on other sites

1. Поставьте ipguard из портов.

2. Почитайте на него доку и создайте настройки (база связок IP-MAC).

3. Перепишите свой скрипт, чтобы он в базе ipguard нужному IP менял MAC например на 22:22:22:22:22:22 - это автоматом вызовет блокировку IP в сети.

4. Забудьте о своих проблемах и спите спокойно.

Share this post


Link to post
Share on other sites

Тех же, кто решит обслуживать ARP-сегмент самостоятельно - отстреливайте из 300-миллиметровых орудий.

Share this post


Link to post
Share on other sites

Обьясните пожалуста на что реально влияют переменные

kern.ipc.semmni="256"

kern.ipc.semmns="512"

kern.ipc.semmnu="256"

kern.ipc.semmap="256"

kern.ipc.shmmax="134217728"

kern.ipc.nsfbufs=10240

net.graph.maxalloc=2048

shared_buffers = 16MB

max_fsm_pages = 179200

Edited by IvanI

Share this post


Link to post
Share on other sites

kern.ipc.nsfbufs: Maximum number of sendfile(2) sf_bufs available

те для впн оно вообще не нужно, а х64 и для сендфайла не нужно.

 

net.graph.maxalloc: Maximum number of non-data queue items to allocate

 

kern.ipc.nmbclusters=262144

kern.ipc.somaxconn=4096

kern.ipc.maxsockets=204800

kern.ipc.semmap=512

kern.maxfiles=204800

kern.maxfilesperproc=200000

net.inet.ip.portrange.first=1024

net.inet.ip.portrange.last=65535

net.inet.ip.portrange.randomized=0

это и ещё кое что было в рекомендациях Сысоева для веб серверов на nginx

 

kern.ipc.nmbclusters=262144

это как то много.

 

всякие про шаредмем взяты со статей про тюнинг под БД на веб сервере

Edited by Ivan_83

Share this post


Link to post
Share on other sites

Для mpd4 у меня туннели прибивались так:

ifconfig ng123 down

ifconfig ng123 delete

 

Чем такой вариант хуже игр с MAC-адресами?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this