Spørsmål:
Internett med lav båndbredde over VPN
dbrane
2013-01-24 12:30:22 UTC
view on stackexchange narkive permalink

Jeg har nettopp ferdig med å konfigurere en VPN-NAS med min nylig ervervede ikke-overklokkede Raspberry Pi Model-B, og jeg har kommet inn på noe jeg ikke finner svar på andre steder.

Internett-båndbredden, som bestemt ved hjelp av

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

er mye tregere enn hva jeg forventer å få. Jeg får rundt 1,34 MBps på Pi-en via ethernet når jeg nærmer meg 7MBps når ethernet er koblet direkte til den bærbare datamaskinen min.

Problemet er med OpenVPN, men jeg kan ikke finne ut hva akkurat det er det. Slik vet jeg dette.

Jeg sammenlignet nedlastningshastighetene på Pi med VPN slått av og på - det var 5,03 MBPS vs 1,34 MBPS.

Så prøvde jeg det på den bærbare datamaskinen min (kablet) - den var 6,9 MBPS (perfekt) mot 6,7 MBPS (nesten perfekt).

Så feilen ligger ikke helt hos VPN-tjenesten min (PrivateInternetAccess) som gir en reduksjon på 3% i båndbredde på min bærbare datamaskin - men har å gjøre med måten OpenVPN kjører på Pi, noe som gir 74% reduksjon i båndbredde.

Noen ideer til hvorfor OpenVPN på Raspbian er så forferdelig?

OPPDATERING: Det meste av den reduksjonen fra 6.9MBPS på den bærbare datamaskinen uten VPN til 5.03 MBPS på Pi uten VPN ser ut til å være fra skrivehastigheten på SD-kortet, som jeg har bestemt meg for å være rundt 4,9MBPS. Det er den enorme reduksjonen fra 5.03 MPBS på Pi uten VPN til 1.3 MB med VPN som må forklares.

OPPDATERING 2: Noen flere ledetråder fra forslag fra kommentarene: 1) OpenVPN bruker 70% av CPU når den kjører og wget er i bakgrunnen2) På Pi får jeg 1,34 MBPS fra en amerikansk VPN-server og rundt 500-600 KBPS fra ALLE europeiske VPN-servere, MEN på min bærbare datamaskin får jeg 6,7 MBBPS fra US VPN server og en veldig lik 6.6MBPS fra noen europeiske servere som den i Nederland. Det jeg sier er at avstanden til serveren ser ut til å påvirke Pi i uforholdsmessig grad enn den bærbare datamaskinen min.

Det kan være en kombinasjon av dårlig skrivehastighet og VPN-overhead. Jeg likte aldri å bruke VPN-er fordi de bare var sakte over internett og SSH-tunneling var alltid den raskeste. Er det noen alternativer for å aktivere komprimering på OpenVPN? Muligens leke med det, kanskje kryptering forårsaker problemer. Det er et godt spørsmål. Jeg er også interessert i svarene i forhold til Pi
Se på CPU-belastningen med `topp` mens du tester, det skal si noe om krypteringsomkostningene.
@Frepa Utmerket forslag! Når VPN er aktivert, bruker OpenVPN 70% av CPUen. Tror du dette er det som forårsaker den store forskjellen i overføringshastigheter?
@dbrane, det høres ut som om CPU er den begrensende faktoren. Hvor går den gjenværende 30% CPU-tiden? Tomgang? Fra oppdatering 2 høres det ut som om nettverksforsinkelse (dvs. ikke bare gjennomstrømning) er viktig for ytelsen. Kanskje det er noe håndrysting som skjer i VPN.
@Frepa Det meste av gjenværende CPU-tid brukes av wget selv, som er kommandoen jeg bruker for å teste overføringshastigheten. Alt annet i listen bruker mindre enn 1% hver. Jeg bruker et CA-sertifikat med VPN, hvis denne informasjonen hjelper. Kanskje jeg burde prøve å overklokke og se om det hjelper?
@dbrane, OK, så CPU er konstant opptatt. Da er det definitivt flaskehalsen. Den dynamiske overklokkingen har et godt rykte og skal være trygg, du må bare finne hvilke innstillinger som er stabile på din spesifikke Pi.
@Frepa Vel, overklokking hjalp ikke. Bekreftet at det gikk inn i Turbo-modus ved 1 GHz når wget kjørte, men det var ingen forbedring i hastigheten.
Dessuten, mens du faktisk torrent, går ikke CPU-bruken for OpenVPN over 15%, og likevel overstiger torrentfrekvensen aldri 900KBPS.
Det som er rart det er for det meste at du får med torrents så nær maksimum 1,3 MB / s grense uten å maksimere CPU.
En svar:
Blaisorblade
2013-03-02 09:34:05 UTC
view on stackexchange narkive permalink

På enheter med lav effekt, i det minste når jeg bruker SSH, har jeg hatt god erfaring med å bruke RC4-kryptering for å forbedre ytelsen siden den er beregningsmessig raskere, så bruker mindre CPU for båndbredden / tillater høyere båndbredder for samme CPU-bruk. Denne guiden forklarer hvordan du endrer krypteringen til hvilken som helst som støttes av OpenSSL - som RC4:

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

Merk at RC4 ikke er den sikreste algoritmen som er tilgjengelig, men SSL bruker den fortsatt på sikre måter (som finnes, som beskrevet her: http: //en.wikipedia. org / wiki / RC4). Oppdatering : dette er mindre sant nå enn tidligere. Tillit til sikkerheten til RC4 reduseres enda mer, ettersom teknikker for å bryte den avanserer, og 2013 har gitt oss ulike fremgang i å bryte RC4 og spekulasjoner om at NSA har klart. Sitering av Wikipedia:

Fra og med 2013 er det spekulasjoner om at enkelte statlige kryptologiske byråer kan ha muligheten til å bryte RC4, selv når de brukes i TLS-protokollen. [3] Microsoft anbefaler at du deaktiverer RC4 der det er mulig. [4] [5]

Kan jeg likevel anbefale RC4? Ikke egentlig generelt. Selvfølgelig må du avveie sikkerhet og ytelse, og kanskje du faktisk ikke trenger mye sikkerhet - noe kryptografi, til og med RC4, vil fremdeles bremse dragnetovervåkning som de fra NSA. Men jeg ville være veldig forsiktig med faktisk sensitive data, og endre algoritme til noe annet hvis det er mulig i det hele tatt (jeg har begynt å måle bringebæren min for å se etter raske alternativer).

Oppdatering 2 : på mitt (overklokket) bringebær er AES ikke så sakte, hvis du har nok CPU tilgjengelig. Tabellen nedenfor viser at RC4 kan kryptere ~ 57MB / s, mens AES-128-CBC kan kryptere ~ 21,4MB / s. Dette forklarer selvfølgelig ikke hvorfor du får så dårlig ytelse - men kanskje du bruker som standard en langsommere cypher, eller kanskje det er en annen ineffektivitet som kan forbedres. 

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

Innstillinger for overklokking fra /boot/config.txt:

  arm_freq = 950 # for flere alternativer se http: // elinux.org/RPi_config.txtcore_freq=250sdram_freq=450over_voltage=6
Enhver type kryptering (ssh / vpn) vil føre til ekstra CPU-bruk, som sannsynligvis er din flaskehals.
Poenget mitt var at RC4 bruker mindre CPU enn andre krypter, så det kan være bra i denne situasjonen. Men jeg er ikke sikker på om du er enig eller uenig i svaret mitt.
@earthmeLon: Jeg oppdaterte svaret mitt for å uttrykke poenget mitt eksplisitt, fordi det uansett var uklart. Ikke sikker på at det adresserer kommentaren din.
Absolutt. Jeg var veldig takknemlig for å vite at RC4 er en god løsning med minimal overhead på grunn av SSH2s implementering av den. Takk for informasjonen: D. Synd at du ikke kunne se at jeg ga deg en oppstemning, ikke sant?
Faktisk - Jeg la merke til senere at kommentaren din falt sammen når det gjaldt oppstemningen. Takk!
Jeg har satt opp VPN-en min ved hjelp av PPTP. Ikke akkurat sikkert, men det er veldig enkelt på prosessoren. Jeg går egentlig ikke for sikkerhet med oppsettet mitt. Jeg bruker den som en VPN-gateway for å koble til VPN-leverandøren min med enheter som ikke støtter VPN, for eksempel Wii.


ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...