Dotaz: Výkon OpenVPN 2.5

[Honza]

Dobrý den.
Trošku bojuju s propustností OpenVPN. Na obou stranách je aktuálně 300Mbps full-duplexní připojení k internetu. Maximálně se ale dostávám na download/upload na max. 110 až 130 Mbps ve VPN tunelu.
Neporadil by mi prosím někdo, na co se zaměřit abych se dostal na co nejvyšší propustnost ?

# verze OpenVPN

ii  openvpn                              2.5.2-buster0                amd64        virtual private network daemon

# server
CPU: Intel Pentium E5300

mode server
tls-server

local 192.168.81.11
port 1195
proto udp

dev tap0
script-security 2
up "/etc/openvpn/server/up.sh vzbr1 tap0 1500"
down "/etc/openvpn/server/down.sh vzbr1 tap0"

persist-key
persist-tun

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh.pem

tls-auth /etc/openvpn/server/ta.key 0

ncp-disable
cipher AES-128-GCM
compress
passtos

sndbuf 393216
rcvbuf 393216

push "sndbuf 393216"
push "rcvbuf 393216"
push "dhcp-option DNS 192.168.1.10"
push "dhcp-option DOMAIN ad.local"

max-clients 10
keepalive 10 120

log /var/log/openvpn/openvpn.log
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn-append.log

user nobody
group nogroup

verb 3

# client
CPU: AMD EPYC 7502 32-Core

client
dev tap
remote vpn.domain.com 1195

script-security 2
up "/etc/openvpn/client/up.sh br0 tap0 1500"
down "/etc/openvpn/client/down.sh br0 tap0"

ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client.crt
key /etc/openvpn/client/client.key
tls-auth /etc/openvpn/client/ta.key 1

ncp-disable
cipher AES-128-GCM
compress
passtos

persist-key
persist-tun

nobind
resolv-retry infinite

log /var/log/openvpn/openvpn.log
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn-append.log

verb 3

Odpovědi

[bigBRAMBOR]

Ahoj, hele ovpn nikdy neoplývalo rychlostí, abys netunil zbytecne

jo a vyhod compress, neni doporucovany ani z pohledu bezpecnosti a na rychlost ma vliv taky vlastne zadny.

[billgates]

Compress bez parametru vypina kompresiu (If the algorithm parameter is stub, stub-v2 or empty, compression will be turned off). Ale v 2.5 je uz deprecated, takze treba dat:

allow-compression no

Kazdopadne, este sa to da poladit. Ked pridem z prace vecer, tak este napisem.

[Honza]

Byl moc vděčný. Děkuju

[billgates]

Idem sa do toho pomaly pustit a spravit si to na virtualoch. Len mi este napis, akym sposobom to mas potom supnute do lokalnej siete. Cez brctl alebo cez ip link type bridge, pripadne inym sposobom? Ked cez bridge, ake dalsie parametre su nastavene (MTU interfacu)? Ake je realne MTU medzi tymi dvoma miestami na nete bez fragmentacie? Cez iperf3 udp to ide naozaj tych 300Mbit/s oboma smermi? Co vypise cat /proc/cpuinfo | grep -i aes | wc -l? Nastavoval si nejake specialne parametre v sysctl pre handling udp alebo siete vseobecne? Je zapnute irqbalance? Mozes nastavovat firewall na tych strojoch?

Na 150 Mbps lince protáhnu přímo těch 150 a přes Wireguard 143 Mbps. Měřeno iperf3. Přes OpenVPN (teda 2.4) jsem protáhl na té samé lince 40 Mbps.

[Honza]

Přímo mezi lokalitou A a lokalitou B protáhnu 300Mbps. To je OK. Přes OpenVPN cca 110 až 130 Mbps. WireGuard použít nemohu, protože WireGuard je L3. Já potřebuju L2. Zkoušel jsem WireGuard prohnat přes GRE, ale to nefunguje. Viz. nedávné vlákno zde. Proto jsem se vrátil k "osvědčenému" řešení OpenVPN. To sice funguje tak, jak má, ale režie a propustnost je žalostná. Údajně je to už ale řešitelné a verze 2.5+ už by měli umět daleko víc věcí a s daleko menší režií. To se mi ale zatím nepovedlo zprovoznit. Ideálně, kdyby se mi povedlo se maximálně přiblížit propustnosti 300Mbps. Fanatik nejsem, takže extra šifrování nepotřebuju. Navíc, navázání VPN tunelu bude ošetřeno oboustranně na úrovni firewallu. Navíc, OpenVPN jako takové je zabezpečení na úrovni certifikátů. Pro mě dostačující. Cíl tedy je zvednout propustnost mezi bodem A a bodem B na maximální možnou.

[Ovpn]

Zbytečně investujes svůj čas do něčeho co je neřešitelné. Pokud potřebuješ L2 tunel použij ipsec pokud l3 wireguard nebo l3 ipsec. Co se týká propustnosti nikdy jsem nedosáhl s OVPN takových výsledků jako s výše uvedenými. OVPN jako řešení pro klienty a VPN koncentrátor je super, ale jako site2site je mizerné. Za mně pro ipsec strongswan

[Honza]

Byl by prosim odkaz na nejake howto ? Se Strongwan/ipsec jsem nikdy nepracoval. Nemam zadnou zkusenost. Rad bych si to nejdriv v labu vyzkousel. Dekuju

[Ovpn]

Mají webovky s různými příklady např. https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2Examples

[Ovpn]

Řešení s PSK https://www.strongswan.org/testing/testresults5dr/ikev2/net2net-psk/

[Radek]

Tipl bych, že úzké hrdlo bude dost možná i ten procesor.

Mrkni se schvalně na vytížení jádra (openvpn vytěžovalo 1 jádro na 1 připojení, asi se to nezměnilo).

Jinak dobré zkušenosti mám s l2tp ipsec. Android, windows, macos, samozřejmě linux a další mají integrované klienty.

[PetebLazar]

Zmíněný procesor nemá AES-NI, což může jeho výkon asi limitovat.

https://ark.intel.com/content/www/us/en/ark/products/35300/intel-pentium-processor-e5300-2m-cache-2-60-ghz-800-mhz-fsb.html

např. Thr 1950X (vytížení 1 core)

bez AES-NI
OPENSSL_ia32cap="~0x200000200000000" openssl speed -evp aes-128-gcm
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-gcm     103661.29k   126222.81k   296790.56k   325125.12k   335708.16k   336226.99k

s AES-NI
openssl speed -evp aes-128-gcm
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-gcm     582057.63k  1217929.18k  2609638.31k  3913618.77k  4585630.38k  4680728.58k

[Anonym]

Buffery by som zvysil na 512KB:

sndbuf 524288
rcvbuf 524288

push "sndbuf 524288"
push "rcvbuf 524288"

Tiez by som zvysil txqueuelength na aspon 2000. Testy ukazali zvysenie rychlosti az do hodnoty 8000. Standardna hodnota by mala byt 1000, avsak ta zalezi od verzie kernelu (starsie kernely mali 100, novsie maju 1000).

txqueuelen 2000

Dalsi zaujimavy prepinac je fast-io ktory by mal optimalizovat event-loop preskocenim poll/epoll/select volani pred zapisovanim.

Je tls-server spravne nakonfigurovany? Elipticke krivky by mali byt rychlejsie.

# TLS 1.3 encryption
tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

# TLS 1.2 encryption
tls-cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256

dh none #ECDHE
ecdh-curve secp384r1

Ak je to mozne, skus uplne vypnut TLS a docasne pouzit len staticky kluc. Podla toho budes vediet ci je bottleneck OpenSSL/mbedTLS alebo nieco ine.

MTU nadefinovane na oboch stranach rovnako by tiez mohlo pomoct, openvpn ma argument --mtu-test ktory vie otestovat MTU. Vacsinou je to niekde medzi 1300-1500. Tuto hodnotu potom nastav cez link_mtu:

link_mtu 1500

Ak je to mozne, skompiluj OpenVPN priamo pre ten CPU na servery. Mozno z toho dokazes vycucnut par percent navyse cez vektorove instruckcie (SSE3). Ten procak je prilis stary na to aby mal AES instrukcie, AVX alebo dokonca aj HyperThreading. Takze ten spomaleny prenos moze byt sposobeny aj zastaralym CPU.

Pěkné.

Opravdu se to dá poladěním výrazně zrychlit. V mém případě jsem srovnal rychlosti Wireguardu a OpenVPN.

[Andrej]

Protokol pro VPN se jmenuje IPSec. Software pro výměnu klíčů se jmenuje (například) StrongSwan.

Boj se zouvalou jednovlákonvou dětskou hračkou OpenVPN, která má omylem v názvu VPN, je od začátku nesmysl.

[Radek]

zas bych to tak černě neviděl. Dnešní procesory mají výkon takový, že dají na jednom vláknu gigabit a více. Pro 99,9% věcí to je tedy dostačující.

[j]

Neni, drtiva vetsina implementaci ma radove horsi podporu HW nez ipsec. Takze i pokud by hypoteticky HW vykon mel, tak openvpn ho zazdi. Rozdily jsou na tema 10Mbit pres Openvpn vs Gbit pres ipsec. Jednoduse proto, ze openvpn v tomhle pripade sezere 100% CPU a vic neda, a naprosto ignoruje HW podporu sifrovani.

Ovsem i s ipsecem je to hra na tema jaka ze to je ta jedina spravna kombinace nastaveni, se kterou to HW akceleraci pouzivat bude. Trebas specielne mikrotik, ti maj soudruzi na webu dokonce tabulku ... ktera je ovsem ponekud ne uplne pravdiva.

---

Dete s tim guuglem dopice!

[Andrej]

Dnešní procesory mají výkon takový, že dají na jednom vláknu gigabit a více.

Ano? Opravdu? Takže mých obvyklých 40 Gb/s na CAT 8.1 dá taky jenom jeden procesor?

Ale hovno, vole.

Open„VPN“ nebrat. Není to VPN. Howgh.

[Radek]

Já mluvil o rychlosti 1gbps krom toho, co ti tam teče, že potřebuješ sifrovat 40gbps po mědi? ;)