Ограничение скорости для пользователей, подключающихся к PPTP-серверу

Не, я про pptp с динамикой

>pptp в линупсе - полное гамно. корбиновские линупсоеды с ним мучаются.

ага. мучаемся. решение (кроме перехода на l2tp) есть?

>не говоря уже о косячных маршрутах pppd

чёрт с ними с маршрутами, главное разрыв соединения удалённым сервером вылечить.

>ага. мучаемся. решение (кроме перехода на l2tp) есть?

Есть - купить корбине нормальное железо или сетку как следует свою организовать, я у одного прова на VPN сидел 2 года, и не парился.

а торрент клиент на 10 мегабитах запускал при нескольких соединениях (нескольких сидах) при скачивании? если просто в 1 поток качать так нет проблем. при отдаче не всегда соединение рвётся - чаще при скачивании.

> может кто расскажет, как настроить pptp через нат. натом, естественно, рулишь не ты.

Никак. Если NAT на Linux, то там можно коннтраковский модуль подгрузить для корректной работы GRE. Но для этого всё же ты должен рулить натом:)

Запускал, качал так что аж винт хрустел - не отваливалось.

> И если очередное быдло купило себе например роутер или просто другую сетевую карту - два часа выяснять по телефону MAC? "Спасыба, дарагой, я лючши пэшком пастаю" (ц).
> svr4 (*) (06.05.2008 5:15:57)

А чо, на автомате это уже не сдэлать, да?
Нормальный свич тебе все логи засрёт при попытках подмены MAC/IP. Естественно, по желанию.



> Особенно "приятно" общение с ТП в случае проблем с работой провайдера. Когда они спрашивают номер ошибки в венде (особенно если это проблемы с туннелем типа pptp). В таком случае я соединяю кабель провайдера со старым компом с вендой. Ну или иметь на всякий случай на другом разделе венду. Вы такое предлагаете нам? Выключать комп и вынимать сетевую карту я не буду. Привязка по MAC - это ещё и смена его провайдером за деньги. Спасибо, не надо такого "счастья". Советы типа "а вы не подключайтесь к быдлопровайдерам" - не принимаются.
> tommy (*) (06.05.2008 5:30:02)


Это же на самом деле быдлопровайдер, судя по вашему описанию. Неужели нет альтернатив?
Туннели не нужны, если стоит нормальное железо, никакие номера ошибок само собой тоже. Венда - в печь, неужели современный саппорт не умеет работать с Линукс и пугается, если нет кнокпи Пуск? Смена MAC за деньги - это тоже явная быдлятина.
Вы знаете, Вам очень не повезло с провайдером.

freebsd + mpd (в качестве клиента для pptp) - с тех же торрентов качал со скоростями больше 8МБ/c (именно мегабайт), естественно с кучи источников, - ничего не рвется.

> Никак. Если NAT на Linux, то там можно коннтраковский модуль подгрузить для корректной работы GRE. Но для этого всё же ты должен рулить натом:)

Во-во. А в расейской глубинке провы часто любят клиентов за наты сажать, причем грешный трафик, как правило, не натят. Так что тут pptp идет лесом. Да и OpenVPN только через TCP можно, со всеми вытекающими.

anonymous, провайдер Corbina? :) если да - то не верится :) Хотя вот иногда не рвётся ничего. А иногда не успеет клиент нару гигов слить на большой скорости и уже сервер рвёт соединение.

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

>>pptp в линупсе - полное гамно. корбиновские линупсоеды с ним мучаются.

>ага. мучаемся. решение (кроме перехода на l2tp) есть?

Поставил маршрутизатором винду + nat32. Стоит некоторую сумму, зато гемора меньше на порядок порядков.

Хотя сейчас в кабинете статистики Корбины уже указано, что, дескать, L2TP лучше-устойчивее и, если можете, переходите на него. Ну-ну. xl2tpd в убунте ещё то дерьмо.

tommy, провайдер netbynet, московский

> anonymous, провайдер Corbina? :) если да - то не верится :) Хотя вот иногда не рвётся ничего. А иногда не успеет клиент нару гигов слить на большой скорости и уже сервер рвёт соединение.

логи-то видел? /var/log/syslog наполнен: packet lost or reordered, и так мегабайт 200 за сутки.

>Обидно что почти все отписались в духе "PPTP не нужен" и ни одного поста по теме. MooSE (*) (06.05.2008 8:06:43)

А на что вы рассчитывали? ) Статья неплоха в качестве примера для начинающих осиливать tc/htb. Всё.

>tommy, провайдер netbynet, московский

ясно

>логи-то видел? /var/log/syslog наполнен: packet lost or reordered, и так мегабайт 200 за сутки.

мдям. так оно и было до того как я запись подобного мусора выключил + nobuffer включил.

>"PPTP не нужен" и ни одного поста по теме

Пока что всё ещё хуже. pptp - зло. Про mpd не знаю, но в linux pptp клиент крив и давно никем не поддерживается.

Причём если не ошибаюсь то вроде в новых версиях что-то поломали и в стабильных дистрах версия более старая (хотя и "новая" давно вышла). Пишу по памяти и могу ошибиться.

> Пока что всё ещё хуже. pptp - зло. Про mpd не знаю, но в linux pptp клиент крив и давно никем не поддерживается.

> Причём если не ошибаюсь то вроде в новых версиях что-то поломали и в стабильных дистрах версия более старая (хотя и "новая" давно вышла). Пишу по памяти и могу ошибиться.

Периодически сталкиваюсь с PPTP на Linux. Вобщем-то всё работает и очень даже не плохо. Хотя сам предпочитаю роутеры аппаратные:)

> мдям. так оно и было до того как я запись подобного мусора выключил + nobuffer включил.

и что случается с теми пакетами, которые nobuffer?

> Периодически сталкиваюсь с PPTP на Linux. Вобщем-то всё работает и очень даже не плохо. Хотя сам предпочитаю роутеры аппаратные:)

А аппаратные на чём, не на линупсе?

> Пока что всё ещё хуже. pptp - зло.

Откуда такой вывод? Линупс плохо поддерживает pptp и на этом основании вы называете его злом? По-моему, зло - это ваш мозг и линупс

>>pptp в линупсе - полное гамно. корбиновские линупсоеды с ним мучаются.

>ага. мучаемся. решение (кроме перехода на l2tp) есть?

>>не говоря уже о косячных маршрутах pppd

>чёрт с ними с маршрутами, главное разрыв соединения удалённым сервером >вылечить.

Чтоб вылечить, настраивать надо правильно. Провы, у которых используется unix в качестве сервра доступа с pptp сервером, используют механизм lcp-echo (man pppd). При большой нагрузке на канал к клиенту, особенно если используется шейпинг позволяющий терять пакеты - часть lcp-echo-* пакетов теряется, в результате чего на стороне сервера срабатывает lcp-echo-failure и он рвёт соединение.

Как побороть: верно настроить mtu, увеличитьт буфферы передачи данных на стороне сервера, узбаится от потерь пакетов на последней миле и использовать шейпинг без потерь пакетов.

> Никогда не настраивал pptp со стороны провайдера, но не удивлюсь, если и тут можно здорово выиграть у цисок и по гибкости, и по цене, если энное количество времени провести над тестированием/глубокой настройкой сервера с pptpd на писюке. По гибкости настройки точно. По цене, возможно, расклад будет одинаковый.

как не странно, использование класстера PC-ков как vpn доступа получается выгоднее (дешевле, надежнее, наращивание класстера прозрачно для клиента, практически линейная маштабируемость), когда клиентов от 0 до 50к. И получается дешевле. Но есть и свои проблемы - обслуживание кластера.

>и что случается с теми пакетами, которые nobuffer?

что надо - то и случается. скорость не так проседает.

>Откуда такой вывод? Линупс плохо поддерживает pptp и на этом основании вы называете его злом?

Ну хорошо. У пользователей венды всё будет Ok. А мы будет включать nobuffer, ловить глюки и обходить кривое прописывание маршрутов клиентом. Тогда уж лучше действительно по ftp раздавать клиенты openvpn виндузятникам.

> Ну хорошо. У пользователей венды всё будет Ok. А мы будет включать nobuffer, ловить глюки и обходить кривое прописывание маршрутов клиентом.

Так вся работа в линупсе из этого состоит. Разве вы от этого не получаете странное удовольствие? Зато "Свобода" (детский крем такой).

> Это же на самом деле быдлопровайдер, судя по вашему описанию. Неужели нет альтернатив?

Это нормальный провайдер, который делает привязку IP/MAC для локалки, и pptp для доступа вовне со скоростью согласно тарифа.

> Особенно "приятно" общение с ТП в случае проблем с работой провайдера. Когда они спрашивают номер ошибки в венде

У моего провайдера PPTP. У меня винды нет. Ни разу не возникало проблем. Просто, когда пропадает соединение, я не звоню сразу со словами "у меня интернет кончился", а смотрю лог и проверяю пинги до основных узлов сети и звоню уже с точным описанием симптомов. Ни разу после этого "номер ошибки в винде" не спросили.

> ага. мучаемся. решение (кроме перехода на l2tp) есть?

Ну это сомнительное решение, тоже не самая приятная штука для настройки (да и толку от ихнего l2tp, который только в москве и существует?). Но можно сменить провайдера. Я вот сменил на eltel - там pppoe, совсем другое дело.

давно уже работает связка pptp+HTB

причем скорость берется из муськи p.s. статья ни о чем

Ууууу... как все плохо.. великие аналити ЛОРа - неужели вы первый раз слышите про выдач уперсональных RADIUS параметров? Можно даже организовывать динамическое шейпирование! Уберите новость с главной страницы - это ужасный кастыль для начинающих сисадминов - не надо опускать ЛОР до такого "уровня".

Персонально для того, кто написал данную статью, ссылка на RFC RADIUS - вот сначала вкуриваем а потмо пишем всякие бесполезные поделки. http://www.ietf.org/rfc/rfc2865.txt

Вот добрый человек правильно рассказал про причины, но не рассказал до конца решение.

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

Чтобы PPTP в такой среде хорошо жил, надо lcp вытаскивать отдельной очередью, на которой не стоит drop, и приоритет обслуживания выше. Это дополнительные ресурсы и настройка оборудования - думаю будет и такое сделано, когда у Корбины пройдет период роста.

Пользовательская стратегия весьма интересна - хочу качать больше, даром, и качество. Все это противоречит друг другу, вот и не работает зачастую. Структура р2р трафика вообще плохо поддается управлению, и это проблема во всем мире - решим как-нибудь... (:

Еще пару сентенций по темам обсуждения.

QoS нарезка трафика по моему скромному опыту лучше всего работает в ALTQ, причем под OpenBSD естественно стабильнее чем под FreeBSD. Эта связка уделывает и Linux/HTB и Cisco.

Если Linux так плох в сетевых приложениях почему такие уважаемые среди энтерпрайзов конторы как СheckPoint и Cisco - мигрируют на этот самый Linux?

>неужели вы первый раз слышите про выдач уперсональных RADIUS параметров? Можно даже организовывать динамическое шейпирование!

Ну и как можно сделать динамический шейпер желательно с разделением полосы и ее отбором при необходимости? Про атрибуты SPPED-IN и SPEED-OUT знаю...

> Да и OpenVPN только через TCP можно, со всеми вытекающими

Дядь, книжку почитай или хотя бы man openvpn.

>Пользовательская стратегия весьма интересна - хочу качать больше, даром, и качество. Все это противоречит друг другу, вот и не работает зачастую.

Ну так в венде то проблем нет... Кто бы допилил linux-pptp до совместимости с вендовым софтом... Сам сую кабель в комп с вендой - отлично всё пашет при 100% нагрузке канала. Тоже самое в pptp-linux - чаще всего соединение рвёт удалённый сервер через несколько скачанных гигов при даже не при 100% загрузке канала. Железо конечно надо провайдеру настроить, но из-за несколькох десятков линуксоидов возиться никто не будет (и даже думать над этим не будут).

> QoS нарезка трафика по моему скромному опыту лучше всего работает в ALTQ, причем под OpenBSD естественно стабильнее чем под FreeBSD. Эта связка уделывает и Linux/HTB и Cisco.

Секта OpenBSD растет с каждым днем. Это надо остановить. А сколько пользователей обслуживает этот ваш OpenBSD-рутер и какой там packetrate?

1. OpenBSD ложится под пакетрейтами около 40-50 kpps, потому что для приема пакетов используются прерывания. на однопроцессорных машинах FreeBSD и Linux расходуют намного меньше процессорного времени, чем OpenBSD по причине того, что в них реализован polling. Многопроцессорные рутеры под FreeBSD и Linux работают естественно стабильнее чем под OpenBSD, т.к. в последней до сих пор ядро из 4.4BSD с кучей блокировок.

2. ALTQ не умеет эффективно классифицировать трафик, в отличие от iproute2 и dummynet. Для каждого пользовательского канала приходится создавать отдельное правило. Когда таких каналов становится несколько тысяч, рутер тратит большую часть процессорного времени на обход этих правил.

Вывод: OpenBSD и ALTQ в лучшем случае пригодны для слабонагруженных систем.

>в линупсе >линупсоеды

К логопеду, быдло!

В биореактор, быдло!

>в линупсе

В биореактор, быдло!

Кто-нибудь поднимал Linux/tc/HTB на bond'ах (в ынтырпрайзе EtherChannel'ы) ?

Наблюдаю жуткие потери пакетов и скачущую скорость.

Стоит зароутить через одну сетевуху и классы повесить не на bond, а на стандартный eth -- всё в порядке. На виланах, насколько я помню, проблем тоже никогда не было.

> Кто-нибудь поднимал Linux/tc/HTB на bond'ах (в ынтырпрайзе EtherChannel'ы) ?

> Наблюдаю жуткие потери пакетов и скачущую скорость.

> Стоит зароутить через одну сетевуху и классы повесить не на bond, а на стандартный eth -- всё в порядке. На виланах, насколько я помню, проблем тоже никогда не было.
> anonymous (*) (07.05.2008 3:03:03)


Бугага.
Нашёл более-менее рабочий вариант. :)
Делить канал поровну между сетевухами в бонде, чуток завышая скорость, пакеты слать по Round-Robin, классы htb вешать на все сетевухи, состоящие в бонде (с учётом деления канала поровну между всеми).
Потери уходят, и, за счёт round-robin, скорость получается "как по тарифу". :)

У кого какие ещё есть варианты? :)

rshaper для 2.6.24 ftp://ftp.simtreas.ru/pub/my/rshaper.tgz

Возможно на SMP будет работать уже нормально без kernel panic - надо тестить

Вот фикс для pptpclient (works for me)

--- pqueue-orig.h       2008-05-07 21:35:26.000000000 +0400
+++ pqueue.h    2008-05-07 21:35:36.000000000 +0400
@@ -9,7 +9,7 @@
 extern int packet_timeout_usecs;
 
 /* assume packet is bad/spoofed if it's more than this many seqs ahead */
-#define MISSING_WINDOW 300
+#define MISSING_WINDOW 2048
 
 /* Packet queue structure: linked list of packets received out-of-order */
 typedef struct pqueue {

Проверяю. Отпишусь.

Почти 8 часов тестирования на канале 12,5 мегабит - 100% нагрузил torrent (Azureus) одним или несколькими торрентами на скачивание (специально разное число, с разным числом сидов). На торрентах от 4 до нескольких десятков Gb. Падений не было.

Сколько падений могло быть на не патченном pptp на Корбине - непредсказуемо. Потом буду пробовать ещё.

> 1. OpenBSD ложится под пакетрейтами около 40-50 kpps, потому что для приема пакетов используются прерывания. на однопроцессорных машинах FreeBSD и Linux расходуют намного меньше процессорного времени, чем OpenBSD по причине того, что в них реализован polling. Многопроцессорные рутеры под FreeBSD и Linux работают естественно стабильнее чем под OpenBSD, т.к. в последней до сих пор ядро из 4.4BSD с кучей блокировок.

ну да, а поллинг даёт потери пакетов из буфера под большой нагрузкой.. вдобавок нормальные сетевухи умеют irq mitigation, но в общем на бумаге и в бенчмарках openbsd медленнее, согласен. Зато маны в опенке вменяемые и вообще система оставляет приятное впечатление. Скорости бы ей вот добавить и smp допилить..

хотя хеннинг в мл всё похваляется что можно до 500kpps раскочегарить, но рецепт почему-то не даёт - пустозвон в общем.

> логи-то видел? /var/log/syslog наполнен: packet lost or reordered, и так мегабайт 200 за сутки.

pptp --loglevel 0 --nobuffer

mtu поставь где-то 1400, ну и mss надо менять в пакетах (см. например TCPMSS в manе по iptables

у меня мегабитный канал работает без проблем.

> ну и mss надо менять в пакетах (см. например TCPMSS в manе по iptables)

это только если у тебя клиенты за натом а инет по pptp...

> rshaper для 2.6.24 ftp://ftp.simtreas.ru/pub/my/rshaper.tgz

> Возможно на SMP будет работать уже нормально без kernel panic - надо тестить

> anonymous (*) (07.05.2008 11:48:34)


Kernel panic после десяти минут работы на 2500 правил (обычный натящий писишный роутер с четырьмя процессорными ядрами и четырьмя сетевыми картами).

> И pptp, pppoe в основном используются не как средство для > шифрования канала, а как удобный механизм предоставления > клиенту услуги доступа в инет и его, клиента, тарификации.

Вчерашний день. Юзайте per user vlan.

> ну да, а поллинг даёт потери пакетов из буфера под большой нагрузкой.. вдобавок нормальные сетевухи умеют irq mitigation

Потери пакетов от поллинга -- это миф, порожденный людьми не осилившими sysctl kern.polling. Потери происходят от неоптимальных настроек, идущих по умолчанию. Во FreeBSD можно выставить максимальный размер буфера burst_max в 1000 пакетов. В сочетании с частотой опроса 1000 раз в секунду это теоретически позволяет принимать миллион пакетов в секунду. На практике рутеры держат без потерь около 200 kpps. Этого мало? В Linux реализация опроса более интеллектуальна и практически не требует настроек. IRQ mitigation, по опыту, под нагрузками приводит к большему (в разы) расходу процессорного времени, чем NAPI и polling.

В связи с началом массового использования многоядерных процессоров, 4.4BSD-based системы теряют всякую актуальность для серьезного использования. Их нужно радикально переписывать, но за это вряд ли возьмутся OpenBSD и NetBSD teams. Гораздо проще писать драйвера устройств, портировать свой устаревший код на все новые и новые тостеры и выпускать релизы точно по расписанию два раза в год.