Назад | Перейти на главную страницу

Samba через OpenVPN - ужасно медленно

Я настроил сервер для запуска OpenVPN с целью удаленного доступа клиентов к общим ресурсам Samba.

Сервер работает под управлением CentOS 5.6, приличного четырехъядерного процессора Xeon и большого количества оперативной памяти. Клиент, на котором я его тестировал, - это машина с Windows 7 x64, также с довольно высокими характеристиками.

В результате загрузка и загрузка на клиент выполняются со скоростью около 60 КБ / с. Я понимаю, что Samba очень неэффективна из-за того, что она совершает много повторных поездок, но даже в этом случае - клиент имеет пропускную способность 50 Мбит / с в нисходящем направлении и 4 Мбит / с в восходящем направлении. Даже если скорость загрузки клиента была узким местом, она все равно примерно в 9 раз ниже.

Использование ЦП на сервере и клиенте незначительно во время передачи, поэтому это должно исключать скорость шифрования.

Соответствующий порт OpenVPN открыт как на сервере, так и на клиенте; шифр OpenVPN - AES-128-CBC со 160-битным SHA1 HMAC; также используется ключ TLS и сжатие comp-lzo.

Есть идеи, что это может быть? Я знаю, что Samba медленная ... но это точно не может быть правдой!

Убедитесь, что ваш туннель OpenVPN использует UDP, а не TCP. Кроме того, убедитесь, что туннель использует сжатие, используя директиву comp-lzo в файле конфигурации OpenVPN на обоих концах.

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

tun-mtu 1500
mssfix 1212

Для самого PPP-соединения необходимо также установить ограничение MSS на что-то вроде 1300 на один уровень ниже, чем OpenVPN. Однако, как я уже сказал, я понятия не имею, какой тип подключения вы используете - ограничение MSS будет полезно только в сети без Ethernet, такой как ADSL и т. Д.

В моем случае (OpenMediaVault NAS, на базе Debian) у меня была такая же проблема. Также с PPTP VPN на Synology NAS.

Мое решение помимо настройки MTU заключалось в том, что мне пришлось настроить VPN-сервер для отправки адреса DNS-сервера через DHCP.

После этого я мог использовать всю свою пропускную способность.

Надеюсь, это поможет вам и другим!

Я уже использовал samba для соединения vpn (openvpn) в течение некоторого времени, и я обнаружил, что единственный способ работать на машинах с Windows - это копировать файлы, работать и возвращать их ... в то время как машины linux с установленным ssh диском или общими ресурсами samba работали "нормально" на одном и том же vpn-соединении, но моя скорость соединения была в 10 раз меньше вашей.

У вас установлен openvpn для использования TCP? Это может вызвать проблему, которую вы видите. Вам следует использовать UDP.

Как сказал ErikA, вы должны выполнить передачу SCP (или ftp) (через Интернет и через VPN) для целей сравнения.

Я понимаю, что это отчасти запоздалый ответ, но, помимо очевидной проблемы с транспортом (UDP или TCP), важную роль также играют шифр, MSS, MTU и метод фрагментации.

Там есть очень хорошая статья на вики OpenVPN о том, как добиться максимальной производительности в гигабитной сети. Факты, которые можно найти там, довольно информативны даже ниже гигабитной скорости.

Основные выводы

  • Шифр Blowfish обеспечивает лучшую скорость в целом. Оптимально MTU в сети Gigabit было 48000.
  • Даже с Шифр AES-256 вы можете добиться большей скорости, используя MTU 24000 вместо default.

У меня также была проблема> Я попытался получить доступ из клиента Windows 7 к общему ресурсу SAMBA через OPENVPN ... сначала я мог получить доступ к различным каталогам, но когда я попытался открыть файл, это было возможно с 1kb-Textfiles , никаких шансов с pdf или docx - тогда я добавил параметр mssfix в openvpn-файл> тоже без разницы .. потом я попытался поиграть с количеством MTU и mssfix, наконец, у меня был MTU 1500 и уменьшил mssfix до 500 и Voila> тогда я мог открывать файлы, просматривать каталоги, и SSH-туннель тоже больше не ломался ...