Описанная проблема присуща только ветке OpenVPN 2.3, в 2.4 размеры буферов не меняются без требования пользователя.
Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN - userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC"и. Абсурд!
Если же по какой-то причине нет возможности поменять конфигурационные файлы клиента, следует отдавать достаточно большие размеры буферов с сервера:
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
UDP несколько отличается от TCP. У него нет аналога Window Scale, ему не требуются подтверждения о доставке пакета на транспортном уровне, но низкий размер буфера приема может замедлить и его, если буфер забивается раньше, чем OpenVPN успевает его считывать. Если скорость внутри туннеля кажется вам низкой даже с изменениями, описанными выше, то, возможно, имеет смысл либо увеличить размер буфера для всей системы целиком, увеличив net.core.rmem_default и net.core.wmem_default, либо всегда указывать определенный размер буфера в конфигурационном файле:
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN — userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC"и. Абсурд!
Если же по какой-то причине нет возможности поменять конфигурационные файлы клиента, следует отдавать достаточно большие размеры буферов с сервера:
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
UDP несколько отличается от TCP. У него нет аналога Window Scale, ему не требуются подтверждения о доставке пакета на транспортном уровне, но низкий размер буфера приема может замедлить и его, если буфер забивается раньше, чем OpenVPN успевает его считывать. Если скорость внутри туннеля кажется вам низкой даже с изменениями, описанными выше, то, возможно, имеет смысл либо увеличить размер буфера для всей системы целиком, увеличив net.core.rmem_default и net.core.wmem_default, либо всегда указывать определенный размер буфера в конфигурационном файле:
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
Некоторые из нас не пользуются интернетом без VPN по тем или иным причинам: кому-то нужен выделенный IP, и проще и дешевле купить VPS с двумя IP, чем покупать адрес у провайдера, кто-то хочет получать доступ ко всем веб-сайтам, а не только разрешенным на территории РФ, третьим нужен IPv6, а провайдер его не предоставляет…
Чаще всего VPN-соединение устанавливают на самом устройстве, которое используется в определенный момент, что вполне оправданно, если у вас только один компьютер и один телефон, и вы их редко используете одновременно. Если же в вашей домашней сети множество устройств, или, например, есть такие, на которых VPN настроить нельзя, было бы удобнее поднимать туннель прямо на домашнем роутере, чтобы не задумываться о настройке каждого устройства по отдельности.
Если вы хоть раз устанавливали OpenVPN на свой маршрутизатор, вы, вероятно, были неприятно удивлены скоростью его работы. SoC "и даже дешевых роутеров без особых проблем пропускают через себя окологигабитный трафик, за счет выноса функций маршрутизации и NAT на отдельный чип, предназначенный исключительно для выполнения этой задачи, а основные процессоры таких роутеров довольно слабы, т.к. нагрузки на них практически никакой нет. Такой компромисс позволяет достигнуть высокой скорости работы роутера и заметно снизить цену готового устройства - маршрутизаторы с мощными процессорами стоят в несколько раз дороже, и позиционируются уже не только как коробка для раздачи интернета, но и в качестве NAS, торрентокачалки и домашней мультимедиа-системы.
Мой роутер, TP-Link TL-WDR4300, нельзя назвать новым - модель появилась в середине 2012 года, и обладает 560 МГц-процессором архитектуры MIPS32 74Kc, мощности которого хватает лишь на 20-23 Мб/с шифрованного трафика через OpenVPN, что по меркам скорости современного домашнего интернета совсем немного.
Как бы нам повысить скорость шифрованного туннеля? Мой роутер довольно функциональный, поддерживает 3x3 MIMO, да и вообще, хорошо работает, не хотелось бы его менять.
Так как сейчас принято делать 10-мегабайтные интернет-страницы, писать десктопные приложения на node.js и паковать их в 100-мегабайтный файл, наращивать вычислительные мощности вместо оптимизации, мы совершим нечто ужасное - переложим VPN-подключение на производительный одноплатный «компьютер» Orange Pi One, который установим в корпус роутера, не занимая существующие сетевые и USB-порты, всего за $9.99*!
* + доставка, + налоги, + на пиво, + MicroSD.
Микросхема USB-хаба GL850G, которая используется в роутере, поддерживает работу 4 USB-портов, два из которых не распаяны. Неясно, почему производитель не стал их распаивать, предполагаю, чтобы не дать возможность пользователям подключить сразу 4 устройства с высоким потреблением тока (например, жестких дисков), т.к. штатный блок питания роутера не рассчитан на такую нагрузку. В любом случае, это нам на руку.
Для того, чтобы получить еще один USB-порт, достаточно допаять два провода к 8(D-) и 9(D+) или 11(D-) и 12(D+) пинам.
Однако недостаточно просто так подключить два USB-устройства и надеяться, что все заработает само собой, как это бы произошло с Ethernet. Во-первых, нам нужно заставить одного из них работать в режиме USB Client, а не USB Host, во-вторых, нам нужно определиться с тем, как устройства будут определять друг друга. Существует множество драйверов так называемых USB Gadgets (по названию подсистемы Linux-ядра), которые позволяют эмулировать различные типы USB-устройств: сетевой адаптер, аудиокарту, клавиатуру и мышь, флешку, фотоаппарат, консоль через последовательный порт. Так как наше устройство будет работать с сетью, нам лучше всего подойдет эмуляция Ethernet-адаптера.
Существует три стандарта Ethernet-over-USB:
Ядро соберется в deb-пакет, который не составит труда установить на плату через dpkg .
Остается только подключить плату по USB и настроить наш новый сетевой адаптер на получение адреса через DHCP. Для этого необходимо добавить примерно следующее в /etc/network/interfaces:
auto usb0
iface usb0 inet dhcp
hwaddress ether c2:46:98:49:3e:9d
pre-up /bin/sh -c "echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role"
MAC-адрес лучше задать вручную, т.к. он будет случайным при каждой перезагрузке устройства, что неудобно и хлопотно.
Подключаем MicroUSB-кабель к OTG-разъему, подключаем питание с роутера (его можно подавать на 2 и 3 пины гребенки, а не только на разъем питания).
Осталось настроить роутер. Достаточно установить пакет с EEM-драйвером и добавить наше новое сетевое USB-устройство в бридж локальной firewall-зоны:
opkg install kmod-usb-net-cdc-eem
Чтобы маршрутизировать весь трафик в VPN-туннель, нужно либо добавить SNAT-правило на IP-адрес платы на стороне роутера, либо раздавать в качестве адреса шлюза адрес платы через dnsmasq. Последнее делается добавлением следующей строки в /etc/dnsmasq.conf:
dhcp-option = tag:lan, option:router, 192.168.1.100
где 192.168.1.100 - IP-адрес вашей платы. Не забудьте прописать адрес машрутизатора в настройках сети на самой плате!
Для изоляции контактов платы от контактов роутера использовалась меламиновая губка. Получилось как-то так:
Описанная проблема присуща только ветке OpenVPN 2.3, в 2.4 размеры буферов не меняются без требования пользователя.
Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN - userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC"и. Абсурд!
Если же по какой-то причине нет возможности поменять конфигурационные файлы клиента, следует отдавать достаточно большие размеры буферов с сервера:
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
UDP несколько отличается от TCP. У него нет аналога Window Scale, ему не требуются подтверждения о доставке пакета на транспортном уровне, но низкий размер буфера приема может замедлить и его, если буфер забивается раньше, чем OpenVPN успевает его считывать. Если скорость внутри туннеля кажется вам низкой даже с изменениями, описанными выше, то, возможно, имеет смысл либо увеличить размер буфера для всей системы целиком, увеличив net.core.rmem_default и net.core.wmem_default, либо всегда указывать определенный размер буфера в конфигурационном файле:
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN - userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC"и. Абсурд!
На дворе июль 2004 года. Типичная скорость домашнего интернета в развитых странах составляет 256 Кбит/с-1 Мбит/с, в менее развитых - 56 Кбит/с. Ядро Linux 2.6.7 вышло не так давно, а 2.6.8, в котором TCP Window Scale включен по умолчанию, выйдет только через месяц. Проект OpenVPN развивается уже 3 года как, к релизу готовится версия 2.0.
Один из разработчиков добавляет код, который устанавливает буфер приема и отправки сокета по умолчанию в 64 КБ, вероятно, чтобы хоть как-то унифицировать размер буфера между платформами и не зависеть от системных настроек. Однако в Windows что-то поломали, и указание размера буферов у сокета приводит к странным проблемам с MTU на всех адаптерах в системе. В конечном итоге, в релиз OpenVPN 2.0-beta8 попадает следующий код:
#ifndef WIN32 o->rcvbuf = 65536; o->sndbuf = 65536; #endif
Если вы пользовались OpenVPN, вы знаете, что он может работать как через UDP, так и через TCP. Если на TCP-сокете установить какое-то маленькое значение буфера, в нашем случае 64 КБ, то алгоритм подстройки TCP-окна просто не сможет выйти за это значение.
Что же это значит? Предположим, вы подключаетесь к серверу в США из России через OpenVPN со стандартными значениями буферов сокета. У вас широкий канал, скажем, 50 МБит/с, но в силу расстояния, пинг составляет 100 мс. Как вы думаете, какой максимальной скорости вы сможете добиться? 5.12 Мбит/с. Вам необходим буфер размером как минимум 640 КБ, чтобы загрузить ваш 50 Мбитный канал.
OpenVPN через UDP будет работать несколько быстрее из-за собственной реализации пересылки пакетов, но тоже далеко не идеально.
Как вы могли уже догадаться, данный размер буфера все еще применяется в самом последнем релизе OpenVPN. Как же нам исправить ситуацию? Самый корректный вариант - запретить OpenVPN менять размер буферов у сокета.
Нужно добавить следующие строки как в серверный, так и в клиентский конфигурационные файлы:
Sndbuf 0 rcvbuf 0
В этом случае, размер буфера будет задаваться настройками ОС. Для Linux и TCP это значение будет меняться согласно значениям из net.ipv4.tcp_rmem и net.ipv4.tcp_wmem, а для UDP - фиксированное значение net.core.rmem_default и net.core.wmem_default, деленное на два.
Если же по какой-то причине нет возможности поменять конфигурационные файлы клиента, следует отдавать достаточно большие размеры буферов с сервера:
Sndbuf 0 rcvbuf 0 push "sndbuf 393216" push "rcvbuf 393216"
UDP несколько отличается от TCP. У него нет аналога Window Scale, ему не требуются подтверждения о доставке пакета на транспортном уровне, но низкий размер буфера приема может замедлить и его, если буфер забивается раньше, чем OpenVPN успевает его считывать. Если скорость внутри туннеля кажется вам низкой даже с изменениями, описанными выше, то, возможно, имеет смысл либо увеличить размер буфера для всей системы целиком, увеличив net.core.rmem_default и net.core.wmem_default, либо всегда указывать определенный размер буфера в конфигурационном файле:
Sndbuf 393216 rcvbuf 393216 push "sndbuf 393216" push "rcvbuf 393216"
Если у вас и OpenVPN-сервер работает на Windows-машине, и все клиенты подключаются только из-под Windows, то поздравляю - вам ничего менять не нужно, у вас и так все должно работать быстро.