my personal page

Jakiś czas temu rozie na swoim blogu zwrócił uwagę na wydajność szyfrowania AESem w zależności od procesora, na którym taką operację przeprowadzamy. Z krótkiego wpisu rozwinęła się całkiem ciekawa dyskusja o akceleracji szyfrowania i implementacji tego mechanizmu dla konkretnych rozwiązań. Okazuje się, że temat jest zdecydowanie nietrywialny i że na wydajność szyfrowania, niezależnie od tego, czy szyfrujemy zawartość dysku, czy przesyłane przez sieć dane, wpływa wiele ciekawych czynników.

Na początku tego roku robiłem testy wydajnościowe na potrzeby szyfrowania dysków za pomocą LUKSa. Wyniki (jak znajdę czas, to je tutaj kiedyś wrzucę) pokazały, że bardzo duży przyrost wydajności możemy osiągnąć wykorzystując rozszerzenie procesora o nazwie AES-NI. Samo załadowanie modułu aesni_intel (bo taka platforma mnie wtedy interesowała) powodowało wydajnościowego kopa na poziomie 250% (cryptsetup dla algorytmu aes-128-cbc pokazał wzrost z 219MB/s do 620MB/s).

Dzisiaj chciałbym się skupić na tym samym zagadnieniu, ale w kontekście szyfrowania danych przesyłanych przez tunel OpenVPNa. Ponieważ takich testów raczej nie należy przeprowadzać na produkcji, skleciłem na kolanie „laba”, składającego się z mojego domowego pseudo-serwera (Intel Pentium G2130, 2 rdzenie, 3.2GHz, bez AES-NI) jako koncentratora i kilku klientów:

Najpierw warto by było przedstawić benchmark samych maszynek. Żeby być jako tako spójnym z wpisem roziego, test przeprowadziłem za pomocą polecenia 'openssl speed’ (ale bez opcji –multi). Odpowiednie cyferki możemy obejrzeć w poniższej tabelce:

Dodatkowo udało mi się zmierzyć wydajność OpenSSLa na innych procesorach. Niestety testy przeprowadzałem w warunkach jeszcze bardziej polowych i nie miałem możliwości przetestowania tunelu OpenVPNa. Wyniki poniżej:

W przypadku Atoma i ARMa z Raspberry Pi nie ma sensu przedstawiać wyników z wykorzystaniem EVP, bo te procesory niewiele umieją i wyniki są niemal identyczne (lub nawet słabsze).

Warto by było przedstawić jeszcze sposób przeprowadzania testów.
Konfiguracja serwera: (cipher i comp-lzo ustawiane zgodnie z odpowiednim testem)

local 10.0.0.2
proto udp
port 1194
dev tap0
ca /etc/openvpn/certs/ca.pem
cert /etc/openvpn/certs/server.crt
key /etc/openvpn/certs/server.key
dh /etc/openvpn/certs/dh1024.pem
server-bridge 10.0.99.1 255.255.255.0 10.0.99.2 10.0.99.20
keepalive 10 120
max-clients 10
persist-key
persist-tun
verb 3
cipher XXX               
comp-lzo

Konfiguracja klienta:

client
dev tap
proto udp
remote 10.0.99.1
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
verb 3
comp-lzo
cipher XXX

Wyniki pochodzą z iperfa (komendy odpowiednio dla serwera i klienta):

iperf -s
iperf -c adres_IP -t 600; uptime

Najwyższy czas na bohatera niniejszego wpisu, czyli tabelkę z wynikami:

Na koniec kilka ciekawostek.

• Laptop z Core i3 na pokładzie spędzał dużo więcej czasu na obsłudze karty sieciowej (Realtek 8169 – funkcje kernela rtl8169_poll oraz rtl8169_interrupt), niż na szyfrowaniu danych.

• Zgodnie z informacjami, które znalazłem na stronie OpenVPNa, problemy z osiągnięciem wysokich wartość na linkach gigabitowych nie wynika z braku zasobów do szyfrowania danych, a ze sposobu, w jaki pakiety z danymi podróżują przez system.

• Spotkałem się też z informacją, że aby włączyć EVP w OpenVPNie, trzeba dodać do konfiguracji komendę engine aes-ni.