Internet bandwidth rendah melalui VPN

10

Saya baru saja menyelesaikan pengaturan NAS VPN dengan Raspberry Pi Model-B saya yang baru saja diakuisisi dan saya telah menemukan sesuatu yang tidak dapat saya temukan jawabannya di tempat lain.

Bandwidth internet, sebagaimana ditentukan menggunakan

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

jauh lebih lambat dari yang saya harapkan. Saya mendapatkan sekitar 1,34 MBps pada Pi saya melalui ethernet ketika saya hampir 7MBps ketika ethernet dicolokkan langsung ke laptop saya.

Masalahnya dengan OpenVPN, tapi saya tidak tahu persis apa itu. Begini cara saya mengetahui hal ini.

Saya membandingkan tingkat unduhan pada Pi dengan VPN dimatikan dan on - itu 5,03 MBPS vs 1,34 MBPS.

Kemudian saya mencobanya di laptop saya (kabel) - itu 6,9 MBPS (sempurna) vs 6,7 MBPS (hampir sempurna).

Jadi kesalahannya tidak sepenuhnya terletak pada layanan VPN saya (PrivateInternetAccess) yang memberikan pengurangan 3% dalam bandwidth pada laptop saya - tetapi ada hubungannya dengan cara OpenVPN berjalan pada Pi yang memberikan pengurangan 74% dalam bandwidth.

Adakah ide mengapa OpenVPN tentang Raspbian begitu mengerikan?

PEMBARUAN: Sebagian besar pengurangan dari 6.9MBPS pada laptop tanpa VPN menjadi 5.03 MBPS pada Pi tanpa VPN tampaknya berasal dari kecepatan tulis kartu SD, yang saya tentukan sekitar 4.9MBPS. Ini adalah pengurangan besar dari 5.03 MPBS pada Pi tanpa VPN ke 1.3MBPS dengan VPN yang perlu dijelaskan.

UPDATE 2: Beberapa petunjuk dari saran dari komentar: 1) OpenVPN menggunakan 70% dari CPU ketika sedang berjalan dan wget di latar belakang 2) Pada Pi, saya mendapatkan 1,34 MBPS dari server VPN AS dan sekitar 500- 600 KBPS dari SEMUA server VPN Eropa, TETAPI di laptop saya, saya mendapatkan 6.7MBPS dari server VPN AS dan 6.6MBPS yang sangat mirip dari beberapa server Eropa seperti yang ada di Belanda. Apa yang saya katakan adalah bahwa jarak ke server tampaknya secara tidak proporsional mempengaruhi Pi daripada laptop saya.

dbrane
sumber
Bisa jadi kombinasi antara kecepatan tulis yang buruk dan overhead VPN. Saya tidak pernah suka menggunakan VPN karena mereka hanya lambat di internet dan tunneling SSH selalu yang tercepat. Apakah ada opsi untuk mengaktifkan kompresi pada OpenVPN? Mungkin bermain dengan itu, mungkin enkripsi sambilan menyebabkan masalah. Ini adalah pertanyaan yang bagus. Saya juga tertarik pada jawaban sehubungan dengan Pi
Piotr Kula
Lihatlah beban CPU dengan topsaat pengujian, yang seharusnya mengatakan sesuatu tentang overhead enkripsi.
Frepa
@Repa saran yang sangat baik! Ketika VPN diaktifkan, OpenVPN menggunakan 70% dari CPU. Apakah Anda pikir ini yang menyebabkan perbedaan besar dalam tingkat transfer?
dbrane
@ Debrane, kedengarannya seolah-olah CPU adalah faktor pembatas. Ke mana 30% sisa waktu CPU pergi? Diam? Dari pembaruan 2 sepertinya latensi jaringan (yaitu tidak hanya throughput) penting untuk kinerja. Mungkin ada beberapa goncangan di VPN.
Frepa
@Frepa Sebagian besar waktu CPU yang tersisa digunakan oleh wget sendiri, yang merupakan perintah yang saya gunakan untuk menguji kecepatan transfer. Segala sesuatu yang lain dalam daftar menggunakan masing-masing kurang dari 1%. Saya menggunakan sertifikat CA dengan VPN, jika informasi itu membantu. Mungkin saya harus mencoba overclocking dan melihat apakah itu membantu?
dbrane

Jawaban:

4

Pada perangkat berdaya rendah, setidaknya saat menggunakan SSH, saya memiliki pengalaman yang baik menggunakan cipher RC4 untuk meningkatkan kinerja karena lebih cepat secara komputasi, jadi gunakan lebih sedikit CPU untuk bandwidth / memungkinkan bandwidth lebih tinggi untuk penggunaan CPU yang sama. Panduan ini menjelaskan cara mengubah sandi ke sembarang yang didukung oleh OpenSSL - seperti RC4:

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

Perhatikan bahwa RC4 bukan algoritma yang paling aman yang tersedia, tetapi SSL masih menggunakannya dengan cara yang aman (yang ada, seperti yang dijelaskan di sini: http://en.wikipedia.org/wiki/RC4 ). Pembaruan : ini kurang benar sekarang daripada di masa lalu. Kepercayaan terhadap keamanan RC4 semakin berkurang, seiring teknik untuk memecahnya lebih lanjut, dan 2013 telah memberi kami berbagai kemajuan dalam memecahkan RC4 dan spekulasi tentang NSA yang telah dikelola . Mengutip Wikipedia:

Pada 2013, ada spekulasi bahwa beberapa lembaga kriptologis negara dapat memiliki kemampuan untuk memecahkan RC4 bahkan ketika digunakan dalam protokol TLS. [3] Microsoft merekomendasikan untuk menonaktifkan RC4 jika memungkinkan. [4] [5]

Jadi, masih bisakah saya merekomendasikan RC4? Tidak juga secara umum. Tentu saja Anda perlu menukar keamanan dan kinerja, dan mungkin Anda tidak benar-benar membutuhkan banyak keamanan - kriptografi apa pun, bahkan RC4, masih akan memperlambat upaya pengawasan jaring-jaring seperti yang dari NSA. Tapi saya akan benar-benar berhati-hati dengan data yang benar-benar sensitif, dan mengubah algoritma ke sesuatu yang lain jika memungkinkan sama sekali (saya sudah mulai membuat tolok ukur Raspberry saya untuk mencari alternatif cepat).

Pembaruan 2 : pada Raspberry (overclocked) saya, AES tidak terlalu lambat, jika Anda memiliki cukup CPU. Tabel di bawah ini menunjukkan bahwa RC4 dapat melakukan crypt ~ 57MB / s, sementara AES-128-CBC dapat melakukan crypt ~ 21.4MB / s. Tentu saja, ini tidak menjelaskan mengapa Anda mendapatkan kinerja yang buruk - tetapi mungkin Anda menggunakan cypher yang lebih lambat secara default, atau mungkin ada beberapa inefisiensi lain yang dapat ditingkatkan.

$ 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

Pengaturan overclocking dari /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
Blaisorblade
sumber
1
Setiap jenis enkripsi (ssh / vpn) akan menyebabkan penggunaan CPU tambahan, yang mungkin merupakan hambatan Anda.
earthmeLon
1
Maksud saya adalah bahwa RC4 menggunakan CPU lebih sedikit daripada cipher lainnya, jadi mungkin baik dalam situasi ini. Tetapi saya tidak yakin apakah Anda setuju atau tidak dengan jawaban saya.
Blaisorblade
@earthmeLon: Saya memperbarui jawaban saya untuk menyatakan maksud saya secara eksplisit, karena toh itu tidak jelas. Tidak yakin yang membahas komentar Anda.
Blaisorblade
Benar. Saya sangat menghargai mengetahui bahwa RC4 adalah solusi yang baik dengan overhead yang minimal, karena implementasi SSH2 itu. Terima kasih atas informasinya: D. Sayang sekali Anda tidak bisa melihat saya memberi Anda suara keras, eh?
earthmeLon
Memang - saya hanya memperhatikan kemudian bahwa komentar Anda bertepatan dengan waktu dengan upvote. Terima kasih!
Blaisorblade