OpenVPN TCP sebesség optimalizálás

Debian GNU/Linux

Sziasztok!

Segítséget kérnék mert már nem tudok mit állítani.

Adott 1db 1Gb/s-es sávszélen lévő linux debian 7 openvpn 2.3.9-el (legújabb), TUN-al és egy szintén azon a switch-en lévő teszt gép.

A problémám az, hogy ugye udp-t nem akarok használni ezért jött a tcp viszont itt jelentős a sebesség csökkenés, ez rendben is van valamilyen szinten, viszont rengeteg helyen olvastam, hogy a tcp nagyon kényes és nem egy beállítás van amit be kell lőni hozzá, ebben kérnék segítséget, hogy mi a tapasztalatotok ilyen téren, mert én már kb mindent megpróbáltam viszont 40-50Mb/s-nél többet nem sikerült kicsalnom a rendszerből. Ha itthon tesztelem 10Mb/s-es internettel akkor tcp-vel 250Kb/s-nél nem is megy többet.
Az alábbi opciókkal és értékük változtatásával próbálkoztam eddig:

tcp-nodelay
sndbuf 0
rcvbuf 0
;push "sndbuf 393216"
;push "rcvbuf 393216"
nice -10
tun-mtu 6000
fragment 0
mssfix 0

  • 3569 megtekintés

( nvik | 2016. 01. 03., v – 01:20 )

megkérdezhetem, hogy udp-t miért nem akarsz haszálni?
nálunk 40-től 100Mbit-ig vannak béreltvonalakon openvpn-ek, lényegében tök default (csak a titkosítás van aes256-ra állítva), és mindenhol hozza a max. sebességet.

amúgy ez egy témábavágó cikk:
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux

továbba úgy hallom, a softether az ilyen szempontból jobb vpn solúció, gyorsabb sokkal _állítólag_, mint az openvpn.
én nem tudom, sohasem használtam.

Természetesen.
Az ügyfelektől tcp-n a 443-as porton vagy a 80-ason lehet kijönni.
Plusz mert ez a vpn szerver ki van téve a "világnak" és védelem szempontjából jobb a tcp, de nem ez az elsődleges szempont.
De próbáltam már UDP-vel is, sajnos ott sem volt túl sok sikerélmény, 50-80Mb/s-et tudott hozni ami még mindig karcsú, de általában ~65 körül volt.

Természetesen néztem már ezt a linket is, az értékeket be is állítottam mint fentebb láthatod. Sajnos nem segített.

A softether-t nem ismerem, de utána járok annak is, köszönöm!

Értem.
A titkosítás sok cpu -t megeszik, a fentebbi linken is láthatod, hogy AES-NI képe sCPU-val sokkal sokkal gyorsabb az openvpn.
Az 50-80Mbit -et visoznt karcsúnak találom, ott valami gebaszt érzek...
De látatlanban nehéz erre okosat mondani.
Ügyfelektől biztosan csak tcp-n lehet kijönni?

"a vpn szerver ki van téve a "világnak" és védelem szempontjából jobb a tcp"
Szerintem meg tök mindegy, de a te dolgod. :)

softether:
https://www.softether.org

azt mondják, hogy a saját protokollját (tehát a saját kliensét) használva sokkal gyorsabb az openvpn-nél.
itt egy nem-objektív összehasonlítás: https://www.softether.org/@api/deki/files/12/=1.3.jpg

hm. most hogy nézegetem a feature listát, lehet, hogy én is kipróbálom hamarosan. :)
- SoftEther VPN's Solution: Using HTTPS Protocol to Establish VPN Tunnels
- VPN over ICMP, and VPN over DNS (Awesome!)

Azt nem tudom, többnyire freebsd(pfsense) alatt használunk openvpn -t. Egyébként az openssl elvileg támogatja, igen.
Ez aalpjnán le tudod "mérni":

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…

Van egy régebbi clearos rendszerünk, az is funkcionál openvpn szerverként is, és se nem lassú, se nem zabálja agyon a procit, valószínűleg AES-NI -zik.

Viszont az openvpn-ben nem felejtsétek beállítani, hogy AES-t használjon, abból sem mindegy, hogy melyiket, mert az AES-NI (legalábbis freebsd alatt) csak korlátozott módokhoz tartalmaz hw utasításokat: AES128-CBC,AES256-CBC,AES256-XTS,AES256-XTS, stb.stb., utánna kell nézni.

Az openvpn alapból nem aes-t használ egybként, hanem blowfisht, amitre ugye az AES-NI nincs hatással. :)

azért nem vagyok benne bizots, hogy a BF nagyságrendekkel gyorsab.
hogy mennyire titkos? egy 1993-as algoritmusról beszélünk, és a készítője is mondta már évekkel ezelőtt valahol, hogy meg van lepődve, hogy valaki még használja, mert elég elavult, nem túl biztonságos már.

https://en.wikipedia.org/wiki/Blowfish_(cipher)

"Blowfish is known to be susceptible to attacks on reflectively weak keys.[9] [10] This means Blowfish users must carefully select keys as there is a class of keys known to be weak, or switch to more modern alternatives like the Advanced Encryption Standard, Salsa20, or Blowfish's more modern successors Twofish and Threefish. Bruce Schneier, Blowfish's creator, is quoted in 2007 as saying "At this point, though, I'm amazed it's still being used. If people ask, I recommend Twofish instead."[11] The FAQ for GnuPG (which features Blowfish as one of its algorithms) recommends that Blowfish should not be used to encrypt files that are larger than 4 Gb because of its small 64-bit block size.[12]"

(a 64bit blocksize vpn kapcsolatnál is gond lehet, ha valaki sniffel, könnyen összejön 4+ GB adat.)

Most azt hiszed, hogy ez valami hobbiból megcsinált őrület, csak hogy demonstrálja valaki, hogy ilyet is lehet?
Hát nem. Van az az eset, amikor nagyon is jól jön, hogy ki tudsz látni olyan hálózatból, ahol minden le van tűzfalazva, csak a ping megy át. Vagy ahol semmi nincs kiengedve, de van DNS forwarding (a DNS cache üzemeltetők óriási örömére). Tény, hogy nem feltétlenül egyenes dolog, de nem árt tudni, hogy ilyen lehetőség is van.
---
Régóta vágyok én, az androidok mezonkincsére már!

( secretx v | 2016. 01. 03., v – 10:14 )

Kene egy iperf teszt, kozben pedig nezegetni a topot hogy mizujs..
Milyen halokartya?

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

hzsolt94, neked is válaszolok itt egyben.
Tehát. A gépben maga virtuális gép QEMU alapon, 8 mag cpu-val és 4gb rammal. A memóriahasználat az semmi még a 100Mb-ot sem éri el. A CPU-val "gond" van de csak olyan téren, hogy az openvpn nem képes 1 magnál többet használni ezért "felesleges" a többi cpu, de ennek a magnak a terhelése sem megy 40% felé.
A hálókártya virtualizált típusa: VirtIO.

Fogalmam sincs qemu alatt hogyan viselkedik az openvpn, ezek szerint nem jól. Egyébként 1 Gbps helyett 355 Mbps az nem igazán van rendben.

A kérdésedre sajnos nem igazán lehet válaszolni, mindenféle tuning nélkül lehet csinálni 500-800 Mbps-t openvpn-el, úgyhogy itt biztosan más, kialakításbeli gond is van.

Simán lehet hogy a virtualizációd ennyire hazavágja a teljesítményt, függetlenül attól hogy mit mutat a processzor kihasználtságod. Meg "simán" kijelentésem a beállításokra (és UDP-re) vonatkozik, nem a gép teljesítményére.

Olvasnivaló, hátha segít:

https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux
http://datatag.web.cern.ch/datatag/howto/tcp.html

+1
Ha qemu-ban virtio-t használsz, annak papíron simán kéne tudnia 1Gbit/s-et ilyen processzor mellett. UDP-n valószínűleg fogja is tudni.
Hogy TCP-n mégsem tud ennyit az arra utal, hogy bevisz egy kis latency-t vagy jittert a rendszerbe, ami miatt a TCP flow control már nem megy fel a max áteresztőképességig. Na erre az openvpn érzékeny. Ugyanezt egyébként VMware-en én is tapasztaltam.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ok. Ha egy mód van rá, én először megpróbálnám az openvpn UDP üzemmódját optimalizálni, ahogy lejjebb írtam első körben az MTU kisebbre állításával. Az UDP esetén legalábbis lényegesen könnyebben átlátható, hogy mi történik, és ha a végén lesz jól működő UDP-s konfigod, akkor onnan lehet továbblépni a TCP irányba.
---
Régóta vágyok én, az androidok mezonkincsére már!

Lehet, hogy már annyire el van állítgatva az a tesztrendszer, hogy újra kéne húzni, és úgy mérni. :)
Aztán lépésről lépésre állítani ezt-azt. :)

Kérdezőnek: a softether -t próbáld ki, a saját protokolljával, ma megkérdeztem az ismerősömet, aki használja. Igaz, hogy E5 Xeon servereken, de gigabitet ki tudja tolni a softether-rel. Skálázódik több procimagon a softether, ezért nem tűnik fel, hogy nagy lenne a cpu használat. Ja, vmware ESXi 5 alatt, ubuntu és windows7 virtuális gépekkel van használva, külső kliensek meg windows és mac os x.

"DL: 822.81 Mbit/s UP: 355.63 Mbit/s"

Ez speedtest, vagy iperf a vpn szerver és a vpn kliens között? (természetesen vpn nélkül, kipublikálva az iperf portot) Mert utóbbi volna az érdekes.

Pont digi-nél találkoztam olyannal, hogy speedtest szerint megvolt a szerveren (digi) 800/210 mbit, kliensen (upc) a 120/10 mbit, mégsem ment át szerver->kliens irányban iperf-fel 40 mbit-nél több.

Valószinű a két szolgáltató közötti kapcsolatban volt a hiba. Ill. van is, ez később magától felment 80-100 mbit-re, de még ez is kevés, csak már nem foglalkozok vele, mert elég, ugyanezt hozza SSTP-n is.

( XMI | 2016. 01. 03., v – 14:05 )

Szerintem az MTU-val kéne még kicsit kísérletezni. Az ilyen "10-20kB/s-re lelassul a net" problémák leggyakrabban túl nagy MTU miatti IP fragmentálás miatt vannak. (Ez a magyarázat leginkább UDP-re igaz, TCP-nél az újraszegmentálás miatt sokkal bonyolultabb a helyzet).
Ha még nem tetted meg, első körben biztos-ami-biztos levenném 1400 byte-ra a tun interfészen és megnézném úgy.

Sajnos nekem is vannak rossz emlékeim erről, az openvpn sebességoptimalizálása kb feketemágia. UDP-n általában elviselhető, de TCP-n mindig bajok vannak vele. Pontosabban a TCP in TCP a problémás, mert a külső (az openvpn tunnel session-je) pufferel a szegmentálás és transmit window növekedése miatt. A belső (tunnelen belül futó) tcp session ebből az ACK-ok egyenetlen visszaérkezése miatt a latency durva ingadozását látja, emiatt visszaveszi a window size-ot -> lelassul. Jópár éve volt, hogy utoljára komolyabban foglalkoztam vele, de akkor nem igazán sikerült megoldást találni rá, és nem vagyok biztos benne, hogy egyáltalán van-e rá jó megoldás.
---
Régóta vágyok én, az androidok mezonkincsére már!

( szmiatf v | 2016. 01. 03., v – 20:56 )

Milyen a net kapcsolat?
Annak mtu-ja?

Régen openvpn-eztem, de
nem úgy van, hogy a link-mtu-nál kisebb tun-mtu kellene? Honnan van ez a 6000-es érték?
Sőt, úgy emlékszem, ha a link-mtu jól van megadva (és csak az), akkor az openvpn magának számol megfelelő tun-mtu-t. Meg akkor már mssfix 1

( spearox | 2016. 01. 05., k – 15:00 )

Köszönöm mindenkinek a segítségét, a megoldás is megszületett:
A probléma az volt, hogy KVM alatt a VirtIO nem ment megfelelő sávszélességgel ha VPN-t akartam használni, ezért telepítettem egy Centos 7-et E1000-el és máris jobban produkált, de OpenVPN-el csak 80Mb/s-et sikerült kisajtolni TCP-n át, így nem is próbálkoztam tovább, mert már szorított az idő, a végső megoldást a softether jelentette, remek program és jók a sebesség tesztek is vele.
Belföldön amit éles helyzetbe tudtunk mérni az 120Mb/s (ennyit tud a szolgáltató).
Külföldön 100Mb/s (ennyit tud a szolgáltató).
Tehát, amit lehetett azt tudja a rendszer.

Köszönök minden segítséget!