Vraag:
Low bandwidth internet over VPN
dbrane
2013-01-24 12:30:22 UTC
view on stackexchange narkive permalink

Ik ben net klaar met het opzetten van een VPN-NAS met mijn nieuw verworven, niet-overgeklokte Raspberry Pi Model-B en ik ben iets tegengekomen waar ik elders geen antwoord op kan vinden.

De internetbandbreedte, zoals bepaald met

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

is veel langzamer dan wat ik zou verwachten te krijgen. Ik krijg ongeveer 1,34 MBps op mijn Pi via ethernet wanneer ik bijna 7 MBps benader wanneer het ethernet rechtstreeks op mijn laptop is aangesloten.

Het probleem is met OpenVPN, maar ik kan niet achterhalen wat precies is het. Hier is hoe ik dit weet.

Ik vergeleek de downloadsnelheden op de Pi met de VPN in- en uitgeschakeld - het was 5,03 MBPS versus 1,34 MBPS.

Toen probeerde ik het op mijn laptop (bedraad) - het was 6,9 MBPS (perfect) versus 6,7 MBPS (bijna perfect).

Dus de fout ligt niet helemaal bij mijn VPN-service (PrivateInternetAccess) die een korting van 3% oplevert in bandbreedte op mijn laptop - maar heeft te maken met de manier waarop OpenVPN op de Pi draait, wat een vermindering van 74% in bandbreedte oplevert.

Enig idee waarom OpenVPN op Raspbian zo verschrikkelijk is?

UPDATE: Het grootste deel van die vermindering van 6,9 MBPS op de laptop zonder VPN naar 5,03 MBPS op de Pi zonder VPN lijkt te komen van de schrijfsnelheid van de SD-kaart, waarvan ik heb vastgesteld dat deze ongeveer 4,9 MBPS is. Het is die enorme reductie van 5,03 MPBS op de Pi zonder VPN naar 1,3 MBPS met VPN die moet worden uitgelegd.

UPDATE 2: Nog enkele aanwijzingen van suggesties uit de opmerkingen: 1) OpenVPN gebruikt 70% van de CPU als het draait en wget op de achtergrond 2) Op de Pi krijg ik 1,34 MBPS van een Amerikaanse VPN-server en ongeveer 500-600 KBPS van ALLE Europese VPN-servers, MAAR op mijn laptop krijg ik 6,7 MBPS van de Amerikaanse VPN server en een zeer vergelijkbare 6.6MBPS van sommige Europese servers zoals die in Nederland. Wat ik bedoel is dat de afstand tot de server een onevenredig grote invloed heeft op de Pi in plaats van op mijn laptop.

Het kan een combinatie zijn van een slechte schrijfsnelheid en VPN-overhead. Ik heb VPN's nooit graag gebruikt omdat ze gewoon traag waren via internet en SSH-tunneling altijd de snelste was. Zijn er opties om compressie op OpenVPN in te schakelen? Speel daar mogelijk mee, misschien veroorzaakt on-the-fly codering problemen. Het is een goede vraag. Ik ben ook geïnteresseerd in de antwoorden met betrekking tot de Pi
Kijk naar de CPU-belasting met `top` tijdens het testen, dat zou iets moeten zeggen over de coderingsoverhead.
@Frepa Uitstekende suggestie! Als de VPN is ingeschakeld, gebruikt OpenVPN 70% van de CPU. Denk je dat dit het enorme verschil in overdrachtssnelheden veroorzaakt?
@dbrane, het klinkt alsof de CPU de beperkende factor is. Waar gaat de resterende 30% CPU-tijd naartoe? Inactief? Vanaf update 2 klinkt het alsof netwerklatentie (dus niet alleen doorvoer) belangrijk is voor de prestaties. Misschien is er wat handdruk aan de hand in VPN.
@Frepa De meeste resterende CPU-tijd wordt gebruikt door wget zelf, de opdracht die ik gebruik om de overdrachtssnelheid te testen. Al het andere in de lijst gebruikt elk minder dan 1%. Ik gebruik een CA-certificaat met de VPN, als die informatie helpt. Misschien moet ik overklokken proberen en kijken of dat helpt?
@dbrane, OK, dus de CPU is constant bezig. Dan is het zeker de bottleneck. Het dynamisch overklokken heeft een goede reputatie en zou veilig moeten zijn, je hoeft alleen maar te zoeken welke instellingen stabiel zijn op jouw specifieke Pi.
@Frepa Nou, overklokken hielp niet. Bevestigde dat het in de turbomodus ging op 1 GHz toen wget actief was, maar er was geen verbetering in de snelheid.
Bovendien, terwijl het eigenlijk torrents is, gaat het CPU-gebruik voor OpenVPN niet boven de 15% en toch overschrijdt de torrent-snelheid nooit 900 KBPS.
Wat vreemd is, is dat je met torrents zo dicht bij je maximale limiet van 1,3 MB / s komt zonder de CPU te maximaliseren.
Een antwoord:
Blaisorblade
2013-03-02 09:34:05 UTC
view on stackexchange narkive permalink

Op apparaten met een laag stroomverbruik, althans bij het gebruik van SSH, heb ik goede ervaring met het gebruik van de RC4-codering om de prestaties te verbeteren, aangezien het rekenkundig sneller is, dus minder CPU gebruikt voor de bandbreedte / hogere bandbreedtes toestaat voor hetzelfde CPU-gebruik. In deze handleiding wordt uitgelegd hoe u de code kunt wijzigen in een code die wordt ondersteund door OpenSSL, zoals RC4:

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

Merk op dat RC4 niet het veiligste algoritme is dat beschikbaar is, maar SSL gebruikt het nog steeds op veilige manieren (die bestaan, zoals hier beschreven: http: //en.wikipedia. org / wiki / RC4). Update : dit is nu minder waar dan in het verleden. Het vertrouwen in de beveiliging van RC4 neemt nog meer af, aangezien de technieken om het te verbreken voortschrijdend, en 2013 heeft ons verschillende vooruitgang opgeleverd bij het doorbreken van RC4 en speculaties dat de NSA erin geslaagd is. Wikipedia citeren:

Vanaf 2013 wordt gespeculeerd dat sommige cryptologische overheidsinstanties de mogelijkheid hebben om RC4 te breken, zelfs wanneer ze in het TLS-protocol worden gebruikt. [3] Microsoft raadt aan om RC4 uit te schakelen waar mogelijk. [4] [5]

Kan ik RC4 nog steeds aanbevelen? Niet echt in het algemeen. Natuurlijk moet je veiligheid en prestaties inruilen, en misschien heb je niet echt veel beveiliging nodig - elke cryptografie, zelfs RC4, zal nog steeds de bewaking van sleepnetten vertragen, zoals die van NSA. Maar ik zou heel voorzichtig zijn met echt gevoelige gegevens en het algoritme zo mogelijk veranderen in iets anders (ik ben begonnen mijn Raspberry te benchmarken om naar snelle alternatieven te zoeken).

Update 2 : op mijn (overgeklokte) Raspberry is AES niet zo traag, als je voldoende CPU beschikbaar hebt. De onderstaande tabel laat zien dat RC4 ~ 57 MB / s kan versleutelen, terwijl AES-128-CBC ~ 21,4 MB / s kan versleutelen. Dit verklaart natuurlijk niet waarom u zulke slechte prestaties behaalt - maar misschien gebruikt u standaard een langzamere codering, of misschien is er een andere inefficiëntie die kan worden verbeterd. 

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

Overklokinstellingen van /boot/config.txt:

  arm_freq = 950 # voor meer opties zie http: // elinux.org/RPi_config.txtcore_freq=250sdram_freq=450over_voltage=6
Elk type versleuteling (ssh / vpn) zal extra CPU-gebruik veroorzaken, wat waarschijnlijk uw bottleneck is.
Mijn punt was dat RC4 minder CPU gebruikt dan andere cijfers, dus het zou in deze situatie goed kunnen zijn. Maar ik weet niet zeker of u het eens of oneens bent met mijn antwoord.
@earthmeLon: Ik heb mijn antwoord bijgewerkt om mijn punt expliciet te vermelden, omdat het sowieso onduidelijk was. Ik weet niet zeker of dit uw opmerking betreft.
Absoluut. Ik was erg dankbaar om te weten dat RC4 een goede oplossing is met minimale overhead, vanwege de implementatie ervan door SSH2. Bedankt voor de informatie: D. Jammer dat je niet kon zien dat ik je een upvote gaf, hè?
Inderdaad - ik merkte pas later dat uw opmerking qua timing samenviel met de upvote. Bedankt!
Ik heb mijn VPN ingesteld met PPTP. Niet bepaald veilig, maar het is heel gemakkelijk voor de processor. Ik ga niet echt voor beveiliging met mijn setup. Ik gebruik het als een VPN-gateway om verbinding te maken met mijn VPN-provider met apparaten die geen VPN ondersteunen, zoals mijn Wii.


ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...