Internet o niskiej przepustowości przez VPN

10

Właśnie skończyłem konfigurować NAS z VPN z moim nowo nabytym, nie podkręconym Raspberry Pi Model-B i natknąłem się na coś, na co nie mogę znaleźć odpowiedzi gdzie indziej.

Przepustowość internetu, jak określono za pomocą

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

jest znacznie wolniejszy niż się spodziewałem. Dostaję około 1,34 MB / s na moim Pi przez sieć Ethernet, kiedy zbliżam się do 7 MB / s, gdy sieć Ethernet jest podłączona bezpośrednio do mojego laptopa.

Problem dotyczy OpenVPN, ale nie mogę zrozumieć, co to dokładnie jest. Oto jak to wiem.

Porównałem prędkości pobierania na Pi z wyłączoną i włączoną siecią VPN - było to 5,03 MBPS vs 1,34 MBPS.

Potem spróbowałem na moim laptopie (przewodowym) - było to 6,9 MBPS (idealne) vs 6,7 MBPS (prawie idealne).

Tak więc wina nie leży całkowicie w mojej usłudze VPN (PrivateInternetAccess), która zapewnia 3% zmniejszenie przepustowości na moim laptopie - ale ma związek ze sposobem, w jaki OpenVPN działa na Pi, co daje 74% zmniejszenie przepustowości.

Jakieś pomysły na to, dlaczego OpenVPN na Raspbian jest tak straszny?

AKTUALIZACJA: Większość tego zmniejszenia z 6,9 MBPS na laptopie bez VPN do 5,03 MBPS na Pi bez VPN wydaje się wynikać z prędkości zapisu na karcie SD, którą ustaliłem na około 4,9 MBPS. To ogromna redukcja z 5,03 MPBS na Pi bez VPN do 1,3 MBPS z VPN, który należy wyjaśnić.

AKTUALIZACJA 2: Kilka innych wskazówek z sugestii komentarzy: 1) OpenVPN zużywa 70% procesora, gdy jest uruchomiony, a wget jest w tle 2) Na Pi otrzymuję 1,34 MBPS z amerykańskiego serwera VPN i około 500- 600 KBPS ze WSZYSTKICH europejskich serwerów VPN, ALE na moim laptopie, dostaję 6,7 MBPS z amerykańskiego serwera VPN i bardzo podobny 6,6 MBPS z niektórych europejskich serwerów, takich jak ten w Holandii. Mówię o tym, że odległość do serwera wydaje się nieproporcjonalnie wpływać na Pi, a nie na mój laptop.

dbrane
źródło
Może to być kombinacja niskiej prędkości zapisu i narzutu VPN. Nigdy nie lubiłem korzystać z VPN, ponieważ były one po prostu wolne przez Internet, a tunelowanie SSH zawsze było najszybsze. Czy są jakieś opcje włączenia kompresji w OpenVPN? Być może baw się tym, może szyfrowanie w locie powoduje problemy. To dobre pytanie. Interesują mnie również odpowiedzi w odniesieniu do Pi
Piotr Kula
Spójrz na obciążenie procesora toppodczas testowania, co powinno powiedzieć coś o narzutu szyfrowania.
Frepa
@Frepa Doskonała sugestia! Gdy VPN jest włączony, OpenVPN wykorzystuje 70% procesora. Czy uważasz, że to właśnie powoduje ogromną różnicę w szybkości transferu?
dbrane
@dbrane, wydaje się, że procesor jest czynnikiem ograniczającym. Gdzie idzie pozostałe 30% czasu procesora? Bezczynny? Od aktualizacji 2 wydaje się, że opóźnienie sieci (tj. Nie tylko przepustowość) jest ważne dla wydajności. Być może w VPN odbywa się uścisk dłoni.
Frepa
@Frepa Większość pozostałego czasu procesora jest wykorzystywana przez sam wget, czyli polecenie, którego używam do testowania szybkości transferu. Cała reszta na liście wykorzystuje mniej niż 1% każdy. Używam certyfikatu CA z VPN, jeśli te informacje pomogą. Może powinienem spróbować przetaktowania i sprawdzić, czy to pomoże?
dbrane

Odpowiedzi:

4

Na urządzeniach o niskim poborze mocy, przynajmniej podczas korzystania z SSH, miałem dobre doświadczenie z użyciem szyfru RC4 w celu poprawy wydajności, ponieważ jest on obliczeniowo szybszy, więc zużywa mniej procesora na przepustowość / pozwala na większą przepustowość przy takim samym wykorzystaniu procesora. Ten przewodnik wyjaśnia, jak zmienić szyfr na dowolny obsługiwany przez OpenSSL - na przykład RC4:

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

Zauważ, że RC4 nie jest najbezpieczniejszym dostępnym algorytmem, ale SSL nadal używa go w bezpieczny sposób (który istnieje, jak opisano tutaj: http://en.wikipedia.org/wiki/RC4 ). Aktualizacja : teraz jest to mniej prawdziwe niż w przeszłości. Zaufanie do bezpieczeństwa RC4 zmniejsza się jeszcze bardziej, ponieważ techniki jego przełamywania postępują , a 2013 rok przyniósł nam różne postępy w łamaniu RC4 i spekulacjach na temat zarządzania NSA . Cytując Wikipedię:

Od 2013 r. Spekuluje się, że niektóre stanowe agencje kryptologiczne mogą mieć zdolność do łamania RC4, nawet jeśli są używane w protokole TLS. [3] Microsoft zaleca wyłączenie RC4 tam, gdzie to możliwe. [4] [5]

Czy nadal mogę polecić RC4? Niezupełnie ogólnie. Oczywiście musisz obniżyć bezpieczeństwo i wydajność, a być może nie potrzebujesz tak naprawdę wielu zabezpieczeń - każda kryptografia, nawet RC4, nadal spowolni działania związane z nadzorem magnetycznym, takie jak te z NSA. Byłbym jednak bardzo ostrożny z naprawdę wrażliwymi danymi i, jeśli to możliwe, zmieniłem algorytm na coś innego (zacząłem testować moją Raspberry, aby znaleźć szybkie alternatywy).

Aktualizacja 2 : na moim (podkręconym) Raspberry AES nie jest tak wolny, jeśli masz wystarczająco dużo procesora. Poniższa tabela pokazuje, że RC4 może szyfrować ~ 57 MB / s, podczas gdy AES-128-CBC może szyfrować ~ 21,4 MB / s. Oczywiście nie wyjaśnia to, dlaczego uzyskuje się tak niską wydajność - ale może domyślnie używasz wolniejszego szyfru, a może istnieje inna nieefektywność, którą można poprawić.

$ 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

Ustawienia podkręcania z /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
źródło
1
Każdy rodzaj szyfrowania (ssh / vpn) spowoduje dodatkowe użycie procesora, co prawdopodobnie jest wąskim gardłem.
earthmeLon
1
Chodzi mi o to, że RC4 zużywa mniej procesora niż inne szyfry, więc może być dobrze w tej sytuacji. Ale nie jestem pewien, czy zgadzasz się z moją odpowiedzią, czy nie.
Blaisorblade
@earthmeLon: Zaktualizowałem swoją odpowiedź, aby wyraźnie wyrazić swój punkt widzenia, ponieważ i tak był niejasny. Nie jestem pewien, czy to dotyczy Twojego komentarza.
Blaisorblade
Absolutnie. Byłem bardzo wdzięczny za to, że RC4 jest dobrym rozwiązaniem z minimalnym narzutem, ze względu na implementację SSH2. Dzięki za informację: D. Szkoda, że ​​nie widziałeś, że dałem ci głos, prawda?
earthmeLon
Rzeczywiście - dopiero później zauważyłem, że twój komentarz zbiegł się w czasie z głosowaniem. Dzięki!
Blaisorblade,