Інтернет з низькою пропускною здатністю через VPN


10

Щойно я закінчив налаштування VPN'ed NAS за допомогою моєї недавно придбаної розблокованої Raspberry Pi Model-B, і я натрапив на те, що не можу знайти відповіді в іншому місці.

Пропускна здатність Інтернету, як визначено з використанням

wget --output-document = / dev / null http://speedtest.wdc01.softlayer.com/downloads/test500.zip

набагато повільніше, ніж те, що я очікував би отримати. На моєму Pi через Ethernet я отримую 1,34 Мбіт / с, коли я наближаюся до 7 Мбіт / с, коли Ethernet підключається безпосередньо до мого ноутбука.

Проблема в OpenVPN, але я не можу зрозуміти, що це саме. Ось як я це знаю.

Я порівняв швидкість завантаження на Pi з вимкненою VPN і включеною - вона становила 5,03 Мбіт / с проти 1,34 Мбіт / с.

Потім я спробував це на своєму ноутбуці (провідному) - це було 6,9 Мбіт / с (ідеально) проти 6,7 Мбіт / с (майже ідеально).

Таким чином, помилка не лежить повністю в моїй VPN-службі (PrivateInternetAccess), яка дає на 3% зменшення пропускної здатності на моєму ноутбуці, але пов'язана з тим, як OpenVPN працює на Pi, що дає зменшення пропускної здатності на 74%.

Будь-які ідеї, чому OpenVPN на Raspbian так жахливо?

ОНОВЛЕННЯ: Більшість цього зменшення з 6,9 Мбіт / с на ноутбуці без VPN до 5,03 Мбіт / с на Pi без VPN здається, що це швидкість запису на SD-карту, яку я визначив приблизно в 4,9 Мбіт / с. Це величезне зменшення з 5,03 MPBS на Pi без VPN до 1,3MBPS з VPN, що потрібно пояснити.

ОНОВЛЕННЯ 2: Ще кілька підказок із пропозицій із коментарів: 1) OpenVPN використовує 70% ЦП, коли він працює, а wget знаходиться у фоновому режимі 2) На Pi я отримую 1,34 Мбіт / с від американського VPN-сервера і близько 500- 600 Кбіт / с від ВСІх європейських серверів VPN, АЛЕ на своєму ноутбуці, я отримую 6,7 Мбіт / с від сервера VPN в США і дуже схожий 6,6 Мбіт / с від деяких європейських серверів, як у Нідерландах. Я говорю, що відстань до сервера, здається, непропорційно впливає на Pi, а не на мій ноутбук.


Це може бути поєднанням поганої швидкості запису та накладних витрат VPN. Мені ніколи не подобалося використовувати VPN, тому що вони просто повільно проходили через Інтернет, і тунелювання SSH завжди було найшвидшим. Чи є варіанти включення компресії на OpenVPN? Можливо, пограти з цим, можливо, на льоту шифрування спричинить проблеми. Це гарне запитання. Мене також цікавлять відповіді стосовно Пі
Петра Кули

Подивіться на завантаження процесора під topчас тестування, що повинно сказати про шифрування накладних витрат.
Фрепа

@Frepa Відмінна пропозиція! Коли VPN увімкнено, OpenVPN використовує 70% ЦП. Як ви вважаєте, саме це викликає величезну різницю в швидкості трансферу?
dbrane

@dbrane, це звучить так, ніби CPU є обмежуючим фактором. Куди йде час, що залишився 30% процесора? Холостий? З оновлення 2 звучить, ніби затримка мережі (тобто не тільки пропускна здатність) важлива для продуктивності. Можливо, в VPN відбувається певне струшування рук.
Фрепа

@Frepa Більшість залишків часу процесора використовується самим wget, що є командою, яку я використовую для тестування швидкості передачі. У всьому іншому в списку використовується менше 1%. Я використовую сертифікат CA з VPN, якщо ця інформація допомагає. Можливо, я повинен спробувати розгону і подивитися, чи це допомагає?
dbrane

Відповіді:


4

На малопотужних пристроях, принаймні при використанні SSH, я мав хороший досвід використання шифру RC4 для підвищення продуктивності, оскільки він обчислювально швидше, тому використовує менше процесора для пропускної здатності / дозволяє збільшити пропускну здатність для того ж використання процесора. Це керівництво пояснює, як змінити шифр на будь-який, який підтримується OpenSSL - як RC4:

http://openvpn.net/index.php/open-source/documentation/howto.html#security

Зауважте, що RC4 - це не найбезпечніший доступний алгоритм, але SSL все ще використовує його захищеними способами (які існують, як описано тут: http://en.wikipedia.org/wiki/RC4 ). Оновлення : це зараз менш вірно, ніж раніше. Довіра до безпеки RC4 зменшується ще більше, оскільки методи їх попереднього вдосконалення, і 2013 рік дав нам різний прогрес у руйнуванні RC4 та спекуляціях щодо того, що НСА впоралася . Цитуючи Вікіпедію:

Починаючи з 2013 року, існує припущення, що деякі державні криптологічні агентства можуть володіти здатністю руйнувати RC4 навіть при використанні в протоколі TLS. [3] Microsoft рекомендує деактивувати RC4 там, де це можливо. [4] [5]

Отже, чи можна все-таки рекомендувати RC4? Не дуже взагалі. Звичайно, вам потрібно зруйнувати безпеку та продуктивність, і, можливо, вам насправді не потрібна велика кількість безпеки - будь-яка криптовалюта, навіть RC4, все одно сповільнить зусилля по спостереженню за дранетом, як і ті, що є з NSA. Але я був би дуже обережний із фактично чутливими даними та змінив алгоритм на щось інше, якщо можливо взагалі (я почав орієнтувати свій Raspberry на пошук швидких альтернатив).

Оновлення 2 : на моїй (розігнаній) малині AES не так повільно, якщо у вас є достатня кількість процесора. З наведеної нижче таблиці видно, що RC4 може криптувати ~ 57 Мб / с, тоді як AES-128-CBC може скріптувати ~ 21,4 МБ / с. Звичайно, це не пояснює, чому ви отримуєте такі погані показники - але, можливо, ви використовуєте за замовчуванням повільнішу програму, або, можливо, є якась інша неефективність, яку можна покращити.

$ openssl speed rc4 aes
[...]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4              45281.36k    54782.67k    57196.80k    57391.48k    57570.77k
aes-128 cbc      17904.15k    20469.38k    21133.95k    21449.62k    21403.72k

Налаштування розгону з /boot/config.txt:

arm_freq=950

# for more options see http://elinux.org/RPi_config.txt
core_freq=250
sdram_freq=450
over_voltage=6

1
Будь-який тип шифрування (ssh / vpn) спричинить додаткове використання процесора, що, ймовірно, є вашим вузьким місцем.
земляLon

1
Моя думка полягала в тому, що RC4 використовує менше процесора, ніж інші шифри, тому це може бути добре в цій ситуації. Але я не впевнений, чи згодні ви чи не згодні з моєю відповіддю.
Blaisorblade

@earthmeLon: Я оновив свою відповідь, щоб чітко висловити свою точку зору, оскільки це було все одно незрозуміло. Не впевнений, що стосується вашого коментаря.
Blaisorblade

Абсолютно. Мені дуже вдячно було знати, що RC4 - це хороше рішення з мінімальними витратами, через реалізацію цього SSH2. Дякую за інформацію: D. Шкода, що ви не могли бачити, що я дав вам нагороду, так?
земляLon

Справді, - я лише пізніше помітив, що ваш коментар збігся в часі з результатом роботи. Дякую!
Blaisorblade
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.