Wireguard VPN ... ARM procin

Megnéztem, milyen sebességű VPN-re képes egy ARM Cortex A53 processzoros hardver.
   - Wireguard esetén
   - összehasonlítva OpenVPN-nel

Teszt során felhasznált eszközök:
  - kliens: Intel Core i5-3357u laptop, Ubuntu 20.04
  - szerver: Odroid-C2 (Amlogic s905 ... ARM Cortex-A53  1.5GHz quad core CPUs), Armbian Bullseye 64 bit & Linux kernel 5.4

Sebességtesztet az eszközökön futtatott iperf3 szoftverrel végeztem.

Mérési eredmények:
   Natív vonal: 933 Mbps (switchelt hálózat)
   Wireguard: 880 Mbps ... 8 kernel szál futott a 4 magon, átlagosan 55 % körüli CPU terhelét adva az összes magnak. Látszólag van még CPU tartalék.
   OpenVPN: 107 Mbps ... 1 szálon futó OpenVPN démon kiterhelte az ARM processzor egyik magját.

A Wireguard tempója ezek alapján
   ARM processzoron, például OpenWRT-s SOHO routerek esetén nagy előrelépést hoz.
   MIPS processzoros SOHO routerek esetén szintén. Mások tesztjei alapján például mt7621 dual core MIPS procin 200 Mbps (WG) <--> 20 Mbps (OVPN) szintén bíztató.

 

Update#1: kíváncsiságból megnéztem a 10 wattos Intel J1900 processzoron futó szerverrel (otthon futó kis szerverem):
     Wireguard: 880 Mbps
     OpenVPN: 101 Mbps
 

Update#2: ősrégi TL-WR842ND v1 (Atheros AR7241 rev 1, egymagos 400 MHz MIPS 24Kc) került a kezembe, OpenWRT 19.07.2 -t húztam rá.
   Tűzfal táblákat kiürítettem, viszont benne futtattam az iperf3-at. Így tűzfalszabályok nem, de iperf3 terhelte az egyetlen magját.

   Wireguard: 45 Mbps
   OpenVPN: 8,4 Mbps alapértelmezett GCM
                  8,6 Mbps AES-256-CBC esetén
                  9,1 Mbps AES-128-CBC esetén

 

Update#3: Ez azért komoly: https://tools.ietf.org/html/rfc8439
A Wireguard által is használt ChaCha20 és Poly1305 RFC szinten is rögzítésre került.

Hozzászólások

Azt is lenne jó tudni, hogy OpenVPN-nél milyen titkosítást használtál - méréseim szerint az AES-256-CBC-ről AES-256-GCM-re váltás felezi a CPU terhelést. Mondjuk az tény, hogy egy OpenVPN processz egy magot használ, ami szerver módban nem túl jó dolog.

Köszi az észrevételt. Default "sample.conf"-ot vettem alapul a kísérlethez.

# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC

# továbbá egy opció még kellett, hogy esetemben el tudjam hagyni az AES-256-CGM -et.
ncp-disable      # nélküle AES-256-GCM -et egyeztetnek le automatikusan, hiába a fenti, alapból ott levő cipher sor.

Nálam nem nőtt meg jelentősen a tempó (~ 10%) és éppen a "lassabbal". Oka alább.

Az következő táblázat szerint tényleg jelentősen megnő a tempó a két titkosítás között, ha van AES-NI a prociban: https://github.com/mdaxini/howto-openssl/wiki/OpenSSL-Cipher-Speed
A tesztkonfigurációkban a VPN szerveroldali CPU-kban nincs AES-NI támogatás, így itt a kb. 10% eltérés volt csak mérhető és pont a "lassabb" titkosító eljárás javára.

Az következő táblázat szerint tényleg jelentősen megnő a tempó a két titkosítás között, ha van AES-NI a prociban:

Ez tény, magam is tapasztaltam.

 

A tesztkonfigurációkban a VPN szerveroldali CPU-kban nincs AES-NI támogatás, így itt a kb. 10% eltérés volt csak mérhető és pont a "lassabb" titkosító eljárás javára.

Az én mérésemnél mindkét oldalon volt AES-NI támogatás, és mindkét mérést ugyanazokon a hardvereken végeztem.

ha egyszerre futtatsz tobb openvpn server, es mindegyiket meghajtod iperffel akkor is marad a 100Mbit, vagy skalazodik?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Mivel egyetlen szálon fut az OpenVPN, így többmagos esetben minden magra egyet elképzelhetsz. De mindet másik UDP portra rakva, így a felhasználók eloszthatóak. Ez végülis többfelhasználós esetben segíthet, viszont a felhasználók hullámzó hálózathasználati szokásait nem tudod vele kiszolgálni, mivel egyazon felhasználó nem lát csak egyetlen VPN-nyi adatsebességet.

A Wireguard kernelben fut és szétbomlik szálakra. Ez egy 4 magos procinál eleve 4-szeres tempó ... egyetlen felhasználó hirtelen kapacitásigénye esetén is.
Az ennél is nagyobb nyereség viszont a ChaCha20-Poly1305 titkosító algoritmusban van, amely kb. 5-ször gyorsabbra implementálható az AES-hez képest. Legalábbis abban az esetben, ha nincs hardvergyorsítás.
Hoppá: RFC 8439 -ben írnak erről a titkosításról. Ahogy elnézem, a Google-t nem a tempó oldal motiválta, inkább a mobil eszközök akkujának kímélése volt az algoritmus kifejlesztésének elsődleges célja.

Akit érdekel forráskód szinten, az alább mappákat érdemes átnézni, itt található a teljes forráskódja:
   linux-5.7-rc2/drivers/net/wireguard/
   linux-5.7-rc2/lib/crypto/
 

> ChaCha20-Poly1305 [...]
> Ahogy elnézem, a Google-t nem a tempó oldal motiválta, inkább a mobil eszközök akkujának kímélése volt az algoritmus kifejlesztésének elsődleges célja.

Varjal-varjal-varjal! Ezeket DJ Bernstein talalta ki, koze nincs a Google-hoz. De majd a kripto-szakertok helyre tesznek, ha valamirol lemaradtam...

Hány szálon tesztelted az iperfet (-P)? Azt vettem észre itthon, hogy az alapértelmezett teszt 1 szálon tesztel, és akkor az openvpn daemon processz átlag 33%-on pörgeti ki a cput. Ha növelem a párhuzamos adatfolyamok számát, akkor közel lineárisan emelkedik a CPU terheltség, és valamelyest megnő az átvitt adatok mennyisége is.

Parallelnél terheletlen szerver, terheletlen vonal esetén nem éreztem semmi javulást OpenVPN esetén. Wireguard pedig kihajtotta a vonalat.
De nézzük két irányban (elvileg dupla tempó). Tehát iperf3 -c ....  és vele egyidőben egy iperf3 -c .... -p másikport -R

Wireguard teszt: Intel J1900  a kettő összege 1310 Mbps,
                         Odroid-C2 esetén ugyanez 940 Mbps ... alig javult, holott van CPU.

Titkosítatlan kétirányú: Intel J1900   1730 Mbps,
                                  Odroid C2: 1089 Mbps - hehe, "real gigabit support" marketingszöveg... de csak egyirányú terhelés esetén.
                                  Laptopból a fentiek egyikét tolva, másikat húzva 1815 Mbps
 

Szerkesztve: 2020. 04. 27., h - 14:22

Amit a legvégén linkeltél, az azért még közel sem az út vége: "Category: Informational". Pl. ezek is informational kategóriájú RFC-k :)

Ez egy a sok közül, és egész vicces is: https://tools.ietf.org/html/rfc3251

"While reading this document, at various points the readers may have
   the urge to ask questions like, "does this make sense?", "is this
   feasible?," and "is the author sane?".  The readers must have the
   ability to suppress such questions and read on.  Other than this, no
   specific technical background is required to read this document.  In
   certain cases (present document included), it may be REQUIRED that
   readers have no specific technical background."

Szóval az, hogy valamiből "RFC" lesz, még nem jelenti szökségképpen, hogy az fontos/hasznos/végül sztenderddé válik, bár itt tényleg látszik, hogy ebben az RFC-ben azért sok meló volt eddig és abból vélhetően így vagy úgy, de sztenderd lesz. Akkor válik a buli igazán érdekessé, amikor már "proposed standard" kategóriába kerül bele, vagy "current best practice"-szé válik. Érdekességképpen, ezek a szabályok is RFC-ben vannak rögzítve: https://tools.ietf.org/html/rfc2026 és https://tools.ietf.org/html/rfc6410