Throughput TCP OpenVPN molto basso (porta 100Mbit, basso utilizzo della CPU)

Sto riscontrando velocità di trasferimento OpenVPN estremamente lente tra due server. Per questa domanda, chiamerò i server Server A e Server B.

Sia il server A che il server B eseguono CentOS 6.6. Entrambi si trovano in datacenter con una linea da 100 Mbit e i trasferimenti di dati tra i due server al di fuori di OpenVPN vengono eseguiti vicino a ~ 88 Mbps.

Tuttavia, quando provo a trasferire qualsiasi file tramite la connessione OpenVPN che ho stabilito tra il server A e il server B, ottengo una velocità effettiva di circa 6,5 ​​Mbps.

Risultati dei test da iperf:

[  4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49184
[  4]  0.0-10.0 sec  7.38 MBytes  6.19 Mbits/sec
[  4]  0.0-10.5 sec  7.75 MBytes  6.21 Mbits/sec
[  5] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49185
[  5]  0.0-10.0 sec  7.40 MBytes  6.21 Mbits/sec
[  5]  0.0-10.4 sec  7.75 MBytes  6.26 Mbits/sec

A parte questi test iperf OpenVPN, entrambi i server sono praticamente completamente inattivi con carico zero.

Al server A è assegnato l'IP 10.0.0.1 ed è il server OpenVPN. Al server B è assegnato l'IP 10.0.0.2 ed è il client OpenVPN.

La configurazione OpenVPN per il server A è la seguente:

port 1194
proto tcp-server
dev tun0
ifconfig 10.0.0.1 10.0.0.2
secret static.key
comp-lzo
verb 3

La configurazione OpenVPN per il server B è la seguente:

port 1194
proto tcp-client
dev tun0
remote 204.11.60.69
ifconfig 10.0.0.2 10.0.0.1
secret static.key
comp-lzo
verb 3

Quello che ho notato:

1. Il mio primo pensiero è stato che stavo strozzando la CPU sul server. OpenVPN è a thread singolo ed entrambi questi server eseguono processori Intel Xeon L5520 che non sono i più veloci. Tuttavia, ho eseguito un topcomando durante uno dei test iperf e ho premuto 1per visualizzare l'utilizzo della CPU da parte del core e ho scoperto che il carico della CPU era molto basso su ciascun core:

top - 14:32:51 up 13:56,  2 users,  load average: 0.22, 0.08, 0.06
Tasks: 257 total,   1 running, 256 sleeping,   0 stopped,   0 zombie
Cpu0  :  2.4%us,  1.4%sy,  0.0%ni, 94.8%id,  0.3%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Cpu3  :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu8  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu9  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu11 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu14 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu15 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    946768k total,   633640k used,   313128k free,    68168k buffers
Swap:  4192188k total,        0k used,  4192188k free,   361572k cached

2. I tempi di ping aumentano considerevolmente sul tunnel OpenVPN mentre iperf è in esecuzione. Quando iperf non è in esecuzione, i tempi di ping sul tunnel sono costantemente 60 ms (normale). Ma quando iperf è in esecuzione e spinge traffico intenso, i tempi di ping diventano irregolari. Di seguito puoi vedere come i tempi di ping sono stabili fino al 4 ° ping quando ho iniziato il test iperf:

PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=60.2 ms
** iperf test begins **
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=114 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=85.6 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=176 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=204 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=231 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=197 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=233 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=152 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=216 ms

3. Come accennato in precedenza, ho eseguito iperf al di fuori del tunnel OpenVPN e il throughput era normale - ~ 88 Mbps in modo coerente.

Cosa ho provato:

1. Pensavo che la compressione potesse sporcare le cose, quindi ho disattivato la compressione rimuovendo comp-lzoda entrambe le configurazioni e riavviando OpenVPN. Nessun miglioramento.

2. Anche se in precedenza avevo riscontrato che l'utilizzo della CPU era basso, pensavo che la cifra predefinita potesse essere un po 'troppo intensa per il sistema. Quindi ho aggiunto cipher RC2-40-CBCa entrambe le configurazioni (un codice molto leggero) e ho riavviato OpenVPN. Nessun miglioramento.

3. Ho letto su vari forum su come ottimizzare il frammento, mssfix e mtu-tun potrebbero aiutare con le prestazioni. Ho giocato con alcune varianti come descritto in questo articolo , ma ancora una volta, nessun miglioramento.

Qualche idea su cosa potrebbe causare prestazioni OpenVPN così scarse?

Dopo molte modifiche a Google e ai file di configurazione, ho trovato la soluzione. Ora sto ottenendo velocità sostenute di 60 Mbps e ho fatto esplodere fino a 80 Mbps. È un po 'più lento rispetto alle velocità di trasferimento che ricevo al di fuori della VPN, ma penso che sia buono come lo sarà.

Il primo passo è stato quello di impostare sndbuf 0e rcvbuf 0nella configurazione OpenVPN sia per il server che per il client.

Ho apportato questa modifica dopo aver visto un suggerimento per farlo su un post sul forum pubblico (che è una traduzione inglese di un post originale russo ) che citerò qui:

È luglio 2004. La consueta velocità di internet da casa nei paesi sviluppati è di 256-1024 Kbit / s, nei paesi meno sviluppati è di 56 Kbit / s. Linux 2.6.7 è stato rilasciato non molto tempo fa e 2.6.8 in cui il ridimensionamento dimensioni TCP di Windows sarebbe abilitato per impostazione predefinita viene rilasciato solo in un mese. OpenVPN è in sviluppo attivo già da 3 anni, la versione 2.0 è quasi rilasciata. Uno degli sviluppatori decide di aggiungere un po 'di codice per il buffer socket, penso di unificare le dimensioni del buffer tra i sistemi operativi. In Windows, qualcosa va storto con l'MTU degli adattatori se sono impostate dimensioni di buffer personalizzate, quindi alla fine si è trasformato nel seguente codice:

#ifndef WIN32
o->rcvbuf = 65536;
o->sndbuf = 65536;
#endif

Se hai usato OpenVPN, dovresti sapere che può funzionare su TCP e UDP. Se si imposta un valore del buffer del socket TCP personalizzato su un valore inferiore a 64 KB, l'algoritmo di ridimensionamento dimensioni finestra TCP non può regolare le dimensioni finestra a più di 64 KB. Cosa significa? Ciò significa che se ti connetti ad un altro sito VPN tramite un collegamento long fat, ovvero dagli USA alla Russia con un ping di circa 100 ms, non puoi ottenere una velocità superiore a 5,12 Mbit / s con le impostazioni predefinite del buffer OpenVPN. È necessario almeno 640 KB di buffer per ottenere 50 Mbit / s su quel collegamento. UDP funzionerebbe più velocemente perché non ha dimensioni della finestra ma non funzionerà molto velocemente.

Come si può già immaginare, l'ultima versione di OpenVPN utilizza ancora dimensioni del buffer socket da 64 KB. Come dovremmo risolvere questo problema? Il modo migliore è impedire ad OpenVPN di impostare dimensioni del buffer personalizzate. È necessario aggiungere il seguente codice in entrambi i file di configurazione del server e del client:

sndbuf 0
rcvbuf 0

L'autore continua descrivendo come inviare le regolazioni della dimensione del buffer al client se non si ha il controllo della configurazione del client.

Dopo aver apportato tali modifiche, la velocità di trasmissione è aumentata fino a 20 Mbps. Ho quindi visto che l'utilizzo della CPU era un po 'alto su un singolo core, quindi ho rimosso comp-lzo(compressione) dalla configurazione sia sul client che sul server. Eureka! Le velocità di trasferimento sono aumentate fino a 60 Mbps sostenuti e 80 Mbps sono scoppiati.

Spero che questo aiuti qualcun altro a risolvere i propri problemi con la lentezza di OpenVPN!

Dopo alcuni tentativi, ho raggiunto una buona soluzione. Nel mio caso, la risposta di @ Elliot non ha aiutato. Cercando su Google, ho scoperto questo frammento da aggiungere alla configurazione del server che ha reso il lavoro

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

Ho un piccolo server OpenVPN in esecuzione su un Raspberry PI3 e ora ottengo downlink 71 Mbps e uplink 16 Mbps . Il download è limitato dalla potenza della CPU. In questo momento, la mia configurazione è la seguente:

client-to-client
duplicate-cn
keepalive 10 120
cipher AES-128-CBC
#cipher AES-256-CBC <<<---- lowers the speed to around 50Mbps, still not bad
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
tun-mtu 9000

OpenVPN 2.4.0 arm-unknown-linux-gnueabihf con OpenSSL 1.0.2l

È così strano che esista ancora un tale problema sulla configurazione predefinita di un buffer.

[EDIT] Il mio file client.ovpn è strutturato in questo modo:

client
dev tun
proto tcp
remote SERVER.IP.ADDRESS.HERE
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
tun-mtu 9000
key-direction 1
cipher AES-128-CBC
comp-lzo
verb 1
mute 20
<ca>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
[...]
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
[...]
-----END OpenVPN Static key V1-----
</tls-auth>

Secondo le configurazioni, stai usando TCP come trasporto per il tunnel. Considerare l'utilizzo di UDP anziché TCP poiché le connessioni TCP impilate tendono a creare problemi in situazioni di perdita di pacchetti.

Come riferimento vedi Perché TCP su TCP è una cattiva idea

Abbiamo due server intercontinentali che si collegano tra loro, con una velocità compresa tra loro di circa 220 Mbit / s.

All'interno del tunnel (UDP) OpenVPN, tuttavia, le velocità sarebbero in media a 21 Mbit / s - circa 10 volte più lente.

(Esiste una latenza significativa tra i server: circa 130 ms e i trasferimenti sono stati misurati utilizzando Iperf3 in modalità TCP.)

Ho provato tutti i suggerimenti sulle risposte qui al momento della stesura di questo scritto, e nulla ha aiutato.

L'unica cosa che alla fine ha aiutato è stata questa piccola cosa:

--txqueuelen 4000

Secondo il manuale di riferimento OpenVPN:

–txqueuelen n 
(Linux only) Set the TX queue length on the TUN/TAP interface. Currently defaults to 100.

Dopo aver impostato questo parametro sul server e sul client, sono stato in grado di raggiungere le stesse velocità di "collegamento diretto" (~ 250 Mbit / s) anche sotto il tunnel OpenVPN.

Stavo già usando rcvbuf 0e sndbuf 0, ma almeno da solo , non mi hanno aiutato affatto.

Ho trovato questi consigli in entrambi: questa pagina nei forum OpenVPN e anche in questa pagina nel wiki UDPspeeder .

In un'altra nota: sono stato in grado di raggiungere velocità più elevate utilizzando i trasferimenti UDP in iperf, ma ciò comporterebbe anche una perdita di pacchetti ragionevolmente elevata.

Se per caso hai bisogno di usare la VPN per eseguire il tunneling di due punti con collegamenti con perdita, ti consiglio di prendere in considerazione l'uso di una sorta di tunnel Forward-Error-Correction (FEC) sotto la VPN stessa. I due che sono riuscito a trovare e lavorare sono:

• Il summenzionato UDPspeeder , che tunnel le connessioni UDP;
• kcptun , che tunnel le connessioni TCP;

Entrambi possono aiutare molto con la perdita di pacchetti (spendendo più larghezza di banda in primo luogo), e alla fine anche portando a una maggiore velocità di trasmissione dei dati, anche con l'overhead aggiunto, il che è davvero pulito se me lo chiedi.

(Questo perché la perdita di pacchetti può davvero rovinare una rete , specialmente TCP . Vedi pagina 6.)

Avrei preferito usare OpenVPN su UDP, per tutti i soliti motivi, ma ho trovato difficile gestire UDPspeeder quando hai una latenza superiore a 100 ms e velocità> 10 Mbit / s.

kcptun, tuttavia, ha funzionato alla grande con pochissime modifiche e in realtà ha aumentato il rendimento dei nostri server. =)

Su una nota estesa, qui puoi trovare alcune spiegazioni più dettagliate su come modificare alcune parti delle prestazioni di OpenVPN.

Per me avevo un server VPS con configurazione del server openvpn in Giappone e la mia connessione client utilizzava un DDWRT in modalità client OpenVPN a New York. Stavo ricevendo solo 1-2 Mbps su una connessione a 100 mbit. Il migliore in cui sono stato in grado di ottimizzarlo è stato di 5 Mbps, il che era sufficiente per ciò di cui avevo bisogno, il che è ottimizzato quanto posso far credere.

Impostazioni del mio server OpenVPN:

tun-mtu 9000
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
comp-lzo
txqueuelen 4000
######
port 10111
proto udp
dev tun
user nobody
group nobody
persist-key
persist-tun
keepalive 10 120
topology subnet
server x.x.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 1.1.1.1"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
#tls-crypt tls-crypt.key 0
crl-verify crl.pem
ca ca.crt
cert server_IzA1QdFzHLRFfEoQ.crt
key server_IzA1QdFzHLRFfEoQ.key
auth SHA256
#cipher AES-128-GCM
#cipher AES-128-CBC
#ncp-ciphers AES-128-GCM
#ncp-ciphers AES-128-CBC
#tls-server
#tls-version-min 1.2
#tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
#tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
status /var/log/openvpn/status.log
verb 3

Le mie impostazioni del client DDWRT OpenVPN sono state visualizzate anche nel mio screenshot:

tun-mtu 9000
comp-lzo
##########
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_IzA1QdFzHLRFfEoQ name
auth SHA256
auth-nocache
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3