LINUX.ORG.RU

VPN несколько потоков. Просветите...

 


0

2

Есть два хоста с гигабитными каналами. Между ними VPN туннель. Пробовал OpenVPN и PPTPD Один хост в Германии(Hetzer), второй в Питере(Selectel). Проблема в том, что по туннелю удается протолкнуть до 35-37 Mbit. Но, при тестировании пропускной способности канала(на прямую, т. е. без VPN) с помощью iperf3, при одном потоке получаю 40-45 Mbit при 10 400-450 Mbit, при 30 и выше 900-950 Mbit.

Провайдеры, на претензии заявляют, что все Ок. Но, мне-то надо передавать инфу по VPN каналу. Который больше 40 Mbit пропускать не хочет. Что с этим делать? Может есть, какой-то vpn умеющий многопоточность?

Либо играться с шифрами, либо переходить на wireguard.

anonymous ()

iperf-ом мерил по tcp ?

Прочитай по настройку tcp для каналов с большой задержкой.

vel ★★★★★ ()

Есть несколько вариантов:

  1. Если OpenVPN уже настроен, и не хочется настраивать что-то другое, то в конфигурационные файлы на обеих сторонах можно попробовать добавить:
mssfix 0
tun-mtu 32000
  1. Использовать ядерные туннели. Из шифрованных: IPsec и WireGuard, из нешифрованных: ipip, gre, foo-over-udp (fou)
ValdikSS ★★★★★ ()

SoftEther VPN попробуй, я видел там такую настройку. Но сервак надо свой поднять. И удобный клиент есть только под винду, под онтопик не осилил консоль.

anonymous ()
Ответ на: комментарий от ValdikSS

Забыл упомянуть. На одном узле стоит мастдайка). Поставил Softether. Ничего не изменилось… Пробовал из сети другого провайдера, аналогично. Ну и с чего бы меняться если скорость без VPN(т. е. напрямую) на 5-10% всего выше. То бишь, OVPN настроен и работает корректно, практически на всю ширину предоставляемой полосы пропускания потока. Такое впечатление, что режется скорость на поток…

Печально все это. Гигабитные каналы и такая финя(

AndrK189100 ()
Ответ на: комментарий от Legioner

За публичными хостами внутренние сети. Тут, как понимаю надо поверх ipsec пускать, какой-то туннель. Gre или l2tp. Те же яйца… Читал, что можно, через acl настроить, не поднимая туннель. Предположим, что я даже осилю. Только, что это даст?

AndrK189100 ()
Ответ на: комментарий от AndrK189100

Вроде обычный VPN поднимается без всяких Gre, но сам не пробовал. Производительность по моему опыту гораздо выше. У OpenVPN какие-то серьёзные косяки в реализации или в архитектуре, хз.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

В моем случае дело не в VPN. Между узлами скорость не больше 40Мбит при одном потоке и прямом соединении( т. е. по «белым» IP с обоих сторон. Если запустить несколько, все честно, ~1Гбит. О чем провайдеры мне с радостью сообщают.

AndrK189100 ()
Ответ на: комментарий от Legioner

Проблема в том, что меня интересует не скорость, как таковая. А скорость, к примеру, копирования файла по SMB. Которая не поднимется больше 30 Мбит. По HTTP, FTP аналогично. Т. е. есть сети за хостами, там пользовательские машины. Естественно на офтопике. При копировании файла не выше 30Мбит. Но, с этим еще можно смирится. По специфике работы, пользователи отправляют по туннелю на печать файлы в PostScript. Иногда, сотни мегабайт, вот тут начинаются претензии. Мол на локальный принтер, быстро, а вот на питерский, в разы дольше… Сами принтеры/плоттеры уровня Enterprise. Я к ним отношения не имею, сторонняя контора обслуживает. У них тоже все хорошо. Т. е. у всех, все хорошо, а вот у меня, крайнего, все плохо)))

По UDP все в пределах заявленных провайдерами.

AndrK189100 ()
Ответ на: комментарий от AndrK189100

Я детали не помню, но суть в том, что TCP-соединение не разгоняется выше определённого предела, ограниченного пингом. Грубо говоря чем выше пинг, тем дольше ждать подтверждения о приёме, а максимальный буфер ограничен. Соответственно или уменьшать пинг или тюнить ОС.

Legioner ★★★★★ ()

Vpn умеющий многопоточность есть, называется multipath tcp. Только кастомные ядра должны стоять на сервере и клиенте, и можно сделать несколько tcp flows между ними, а поверх этого openvpn.

А вообще зачем vpn? Есть всякие простые туннели типа ipip, gre. Явно они быстрее.

Bers666 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.