Приоритизация VPN-трафика?

Приоритет VPN'a не поднимается, можно только поднять приоритет процессу требующему больший приоритет.

Ну вообще биты diffserv можно через iptables установить...

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

Я так понимаю, что кроме голосового траффика через PPTP у вас есть ещё и юзеровский трафик на Интернет. Значит, Вам нужно приоритизировать PPTP тунель. Соответственно, QoS нужно настраивать на WAN-овском интерфейсе, а не на VPN-овском. Какая технология организации VPN подойдёт больше в данном случае, imho - не так и существенно.

> Я так понимаю, что кроме голосового траффика через PPTP у вас есть ещё и юзеровский трафик на Интернет. Значит, Вам нужно приоритизировать PPTP тунель.

Совершенно справедливо. Приоритизировать туннель ВЫШЕ, чем юзерский траф.

> ...QoS нужно настраивать на WAN-овском интерфейсе...

Несомненно. Но как? У меня за маскарадом серверная ферма и полсотни виланок - зарубить полосу каждой?

А по протоколам никак?

Разве по айпишникам. Но это может стать геморроем на рутере удаленного офиса.

Мне кажется, если это действительно важно, качество VoIP-трафика надо обеспечивать несколько иначе. Например, поднять для этого другой канал :)

Приоритезировать трафик на ppp+ интерфейсах можно, но если надо идеальная связь, врядли это сильно поможет.

Если я не ошибаюсь, то voip трафик идет с IPTOS 0x02?
Хотя возможно ошибаюсь :).

Раскрашывай трафик через tos флаги и регулируй полосу пропускания,
как тебе хочется.

fagot, переведи плз... :) Как это - другой канал?

anonymous, я как раз про это. Где толково почитать? Спасибо.

Я много чего делал на "авось", да подешевле, а лучше - еще и все вместе на одной машине/канале. Практика показала, что все это ВСЕГДА работает не совсем так, как хотелось бы.

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

Какой у текя канал на провайдера, DSL? Тогда пробуй использовать встроенные возможности QoS. Или Ethernet? Тогда чтобы ты не делал, лаги будут всегда, разве что может меньше :) О том, где брать информацию по настройке линуксовых средств качества обслуживания, если море ссылок в поиске.

Попробуйте посмотреть тут.
Посмотрите, с каким TOS уходят пакеты VOIP'ные и выделяйте
гарантированную скорость пропускания :)
Желаю удачи.


http://book.itep.ru/4/4/mpls17.htm
P.s.
смортеть с каким TOS уходят пакеты, можно обычным tcpdump

fagot, ты не сильно прав, но флейм разводить не буду. Все рутера - это компы с соответствующим софтом, и линух - не из худших. Да, у меня не dsl, и это радует :)

anonymous, штука в том, что они уходят в туннель, а не в очередь сетевого устройства, которое я могу контролировать. Следственно, мне нужно назначить хороший приоритет пакетам ТУННЕЛЯ, а не VoIP. Это первое. И второе: какой приоритет (и КАК!) я могу проставить самому демону pptp (openvpn, etc...), чтобы туннель не вносил лаги.

Привет billy :-)
Давай попробую разобраться,
если у тебя уходят пакеты в туннель, то ведь в какойнибудь gre,
тогда можешь разукрасить этот протокол нужным TOS'ом или
сразу выделить под gre, постоянную полосу пропускания,
впринципе (я точно не знаю, проверь через tcpdump), весь
VoIP трафик должен генерироватся с определенным TOS.

Из твоего сообщения, я понял что последнее ты не можешь делать?
верно?

Желаю удачи.

>Следственно, мне нужно назначить хороший приоритет пакетам ТУННЕЛЯ

Ну и маркируй GRE-пакеты (proto #47) с помошью iptables и давай им приоритет на ethernet устройстве. В чем проблема-то?

fagot: bebebe :P

И че это было?

я бы стер твое сообщение как дубляж :)
ладно, если что не так, прости.