Çok düşük TCP OpenVPN verimi (100Mbit port, düşük CPU kullanımı)


27

İki sunucu arasında oldukça yavaş OpenVPN aktarım hızları yaşıyorum. Bu soru için sunucu A ve Sunucu B'yi arayacağım.

Hem Sunucu A hem de Sunucu B, CentOS 6.6'yı çalıştırıyor. Her ikisi de 100Mbit hatlı veri merkezlerinde bulunur ve OpenVPN dışındaki iki sunucu arasında veri transferleri ~ 88Mbps'ye kadar çalışır.

Ancak, Server A ve B Sunucusu arasında kurduğum OpenVPN bağlantısı üzerinden herhangi bir dosyayı aktarmaya çalıştığımda, 6.5Mbps civarında çıktı alıyorum.

İperf'ten gelen test sonuçları:

[  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

Bu OpenVPN iperf testlerinin yanı sıra, her iki sunucu da sıfır yük ile neredeyse tamamen boşta.

A sunucusuna IP 10.0.0.1 atanmış ve OpenVPN sunucusudur. B Sunucusu IP 10.0.0.2'ye atanmış ve OpenVPN istemcisi.

A Sunucusu için OpenVPN yapılandırması aşağıdaki gibidir:

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

B Sunucusu için OpenVPN yapılandırması aşağıdaki gibidir:

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

Ne farkettim:

1. İlk düşüncem, sunucudaki CPU'yu tıkayan olduğumdu. OpenVPN tek dişlidir ve bu sunucuların her ikisi de en hızlı olmayan Intel Xeon L5520 işlemcileri kullanır. Ancak, topiperf testlerinden biri sırasında bir komut çalıştırdım ve 1çekirdekten CPU kullanımını görüntülemek için bastım ve CPU çekirdeğinin her çekirdekte çok düşük olduğunu tespit ettim:

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. Iperf çalışırken, Ping süreleri OpenVPN tüneli üzerinde önemli ölçüde artmaktadır. İperf çalışmadığında, tünelin üzerindeki ping zamanları sürekli olarak 60ms'dir (normal). Fakat iperf koşarken ve yoğun trafiği zorlarken, ping zamanları düzensizleşiyor. Aşağıda, iperf testine başladığımda ping sürelerinin 4. ping'e kadar nasıl stabil olduğunu görebilirsiniz:

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. Yukarıda bahsedildiği gibi, OpenVPN tünelinin dışına düştüm ve verim normaldi - sürekli olarak - 88Mbps.

Ne denedim:

1. Sıkıştırmanın işleri kirletebileceğini düşündüm, bu yüzden comp-lzohem yapılandırmalardan hem de OpenVPN'i yeniden başlatarak sıkıştırmayı kapattım . İlerleme yok.

2. Daha önce CPU kullanımının düşük olduğunu tespit etmeme rağmen, varsayılan şifrenin sistemin yetişemeyeceği kadar yoğun olabileceğini düşündüm. Bu yüzden cipher RC2-40-CBCher iki konfigürasyona (çok hafif bir şifre) ekledim ve OpenVPN'i yeniden başlattım. İlerleme yok.

3. Parçanın, mssfix'in ve mtu-tun'ın ince ayarının performansa nasıl yardımcı olabileceği hakkında çeşitli forumları okudum. Bu makalede anlatıldığı gibi birkaç varyasyonla oynamıştım , ancak yine de gelişme yok.

Böyle düşük OpenVPN performansına neyin sebep olabileceği hakkında bir fikriniz var mı?


Herhangi bir link var mı, buradan yorumlar yardımcı oldu mu? forums.openvpn.net/topic10593.html
Matt

İçinde bulunduğum önerilerin çoğu, daha önce denediğim şeyler: 1. CPU darboğazını kontrol et, 2. VPN'siz transfer hızlarını doğrula, 3. toggle sıkıştırma, 4. daha hızlı bir şifre seç, vb. Bunlardan hiçbirinde şans yok henüz: - / Tuhaf. Yavaş hız ve yüksek / uçucu ping sürelerinin yanı sıra, darboğazın nerede olabileceğine dair başka bir gösterge göremiyorum.
Elliot B.

Her iki makine de aynı veri merkezinde mi? Aynı veri merkezindeki 60 ms oldukça yüksek. Yardımcı cipher noneolacağından şüphelenmeme rağmen denemek isteyebilirim .
Zoredache

@Zoredache Üzgünüz - Ben sunucuların konumları hakkında net değildim - sunucu A Dallas'ta ve sunucu B Seattle'da.
Elliot B.

MTU’yu kontrol ettiniz mi? Esp: tun-mtu, parça ve mssfix parametreleri? Belgeler
Lenniey

Yanıtlar:


26

Bir sürü Googling ve yapılandırma dosyası tweaks ettikten sonra çözümü buldum. Şimdi sürekli 60Mbps hıza ulaşıyorum ve 80Mbps'ye çıktım. VPN dışında aldığım transfer oranlarından biraz daha yavaş, ancak bunun alacağı kadar iyi olduğunu düşünüyorum.

İlk adım setine oldu sndbuf 0ve rcvbuf 0sunucu ile istemci hem de OpenVPN yapılandırmasında.

Bir alıntı yaptıktan sonra , burada alıntı yapacağım bir genel forum gönderisinde (ki bu bir Rusça orijinal gönderinin İngilizce çevirisidir) bir öneri gördükten sonra bu değişikliği yaptım :

Temmuz 2004'tür. Gelişmiş ülkelerde normal ev internet hızı 256-1024 Kbit / s, daha az gelişmiş ülkelerde 56 Kbit / s. Linux 2.6.7 uzun zaman önce piyasaya sürülmedi ve TCP Windows Size Scaling'in varsayılan olarak etkin olacağı 2.6.8 sadece bir ay içinde piyasaya sürüldü. OpenVPN zaten 3 yıldır aktif bir gelişim içinde, 2.0 sürümü neredeyse yayınlandı. Geliştiricilerden biri soket tamponu için bazı kod eklemeye karar veriyor, sanırım işletim sistemleri arasında tampon boyutlarını birleştirmeyi düşünüyorum. Windows'ta, özel arabellek boyutları ayarlanmışsa, adaptörlerin MTU'sunda bir sorun var, bu yüzden sonunda aşağıdaki koda dönüştü:

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

OpenVPN kullanıyorsanız, TCP ve UDP üzerinden çalışabileceğini bilmelisiniz. Özel TCP soket arabellek değerini 64 KB'ye kadar ayarlarsanız, TCP Pencere Boyutu Ölçeklendirme algoritması Pencere Boyutunu 64 KB'den fazla ayarlayamaz. Bu ne anlama geliyor? Bu, başka bir VPN sitesine uzun yağ bağlantısı üzerinden, yani ABD’nin Rusya’ya yaklaşık 100 ms ping göndererek bağlanması durumunda, varsayılan OpenVPN tampon ayarları ile 5.12 Mbit / sn'den daha fazla hız alamayacağınız anlamına gelir. Bu bağlantıdan 50 Mbit / s alabilmek için en az 640 KB tampon belleğe ihtiyacınız var. UDP daha hızlı çalışacaktır çünkü pencere boyutuna sahip değildir fakat aynı zamanda çok da hızlı çalışmayacaktır.

Tahmin edebileceğiniz gibi, en son OpenVPN sürümü hala 64 KB soket tampon boyutu kullanıyor. Bu sorunu nasıl düzeltmeliyiz? En iyi yol, özel tampon boyutları ayarlamak için OpenVPN'e izin vermemek. Hem sunucu hem de istemci yapılandırma dosyalarına aşağıdaki kodu eklemelisiniz:

sndbuf 0
rcvbuf 0

İstemci konfigürasyonunu kendiniz kontrol edemiyorsanız, yazar, tampon boyutu ayarlarının istemciye nasıl itileceğini açıklamaya devam eder.

Bu değişiklikleri yaptıktan sonra, işlem hızım 20 Mbps'ye yükseldi. Daha sonra CPU kullanımının tek bir çekirdekte biraz yüksek olduğunu gördüm, bu yüzden comp-lzohem istemci hem de sunucudaki konfigürasyondan kaldırdım (sıkıştırma). Eureka! Transfer hızları 60Mbps'ye kadar yükseldi ve 80Mbps'ye yükseldi.

Umarım bu, başkalarının OpenVPN yavaşlığı ile ilgili kendi sorunlarını çözmesine yardımcı olur!


4

Bazı denemelerden sonra iyi bir çözüme ulaştım. Benim durumumda, @ Elliot'ın cevabı yardımcı olmadı. Daha fazlası için, sunucunun yapılandırmasını işi yapan eklemek için bu pasajı öğrendim

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

Bir Ahududu PI3 üzerinde çalışan küçük bir OpenVPN sunucum var ve şimdi 71 Mbps downlink ve 16Mbps uplink alıyorum . İşlemcinin gücünden bu yana indirme işlemi sınırlıdır. Şu anda yapılandırmam şu şekilde:

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

OpenSSL 1.0.2l ile OpenVPN 2.4.0 arm-bilinmeyen-linux-gnueabihf

Tamponun varsayılan konfigürasyonuyla ilgili böyle bir problemin mevcut olması çok garip geliyor.

[EDIT] Müşteri.ovpn dosyam şöyle yapılandırılmıştır:

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>

Tampon boyutlarını ayarlamak bana yardımcı oldu.
Rolf

Client .ovpn dosyasına ne yazdınız?
Patoshi,

@ Patoshi パ ト シ Sndbuf ve recbuf'u yorumladım, uygun şifreyi ve sıkıştırmayı koydum ve varsayılan parametreleri bıraktım.
Çekirdek

@ Çekirdek müşterinizde neler olduğunu bana gösterebilir misiniz? Hong Kong'dan NYC'ye bir OpenVPN bağlantısı yapıyorum ve rasgele yavaş ve bazen bağlantı kesiliyor. Neden olduğundan emin değilim.
Patoshi,

@Patoshi パ ト シ Cevabımı düzelttim, tekrar kontrol et. Bununla birlikte, sunucunuzla dengesiz bir bağlantı sorununu çözmenize yardımcı olabileceğinden, bunun yerine UDP'yi kullanmayı denemenizi öneririm. Aslında, bu sadece bir varsayım, bu durumda bu çözümü karşılaştırmaya hiç çalışmadım.
Çekirdek

1

Yapılandırma işlemine göre, tünel için TCP olarak aktarımı kullanıyorsunuz. Paket kaybı durumlarında problemler yaratmak için yığılmış TCP bağlantıları çadırından beri TCP yerine UDP kullanmayı düşünün.

Referans olarak bkz. TCP Üzerinden TCP Neden Kötü Bir Fikir?


Maalesef UDP bizim için bir seçenek değil. Aktardığımız veri paketlerinin beklendiği gibi ulaşmasını sağlamalıyız. Bununla birlikte, daha önce UDP ile deneyler yaptık ve düşük transfer oranları hala bir problemdi.
Elliot B.

6
We need to ensure that the data packets we transmit arrive as expected.ve bu tünel protokolü tarafından ele alınmıyor mu? Neden tünelin bunu zorlayan şey olması gerektiğini düşünüyorsun?
Zoredache

Muhtemelen durum budur, ancak OpenVPN'i uzun mesafeli bir asenkron DRBD uygulaması (yani, dosya sistemi çoğaltması) için kullanıyoruz. Veri bütünlüğü gerçekten önemlidir, bu nedenle DRBD muhtemelen aktarım bütünlüğünü doğrulamak için iç mekanizmalara sahip olsa da, TCP'de tutmayı tercih ederim. Her iki durumda da, UDP’de bulunduğumuzda hala düşük verim elde ettik.
Elliot B.

3
@ElliotB. DRBD'nin kendisi çoğaltma için TCP kullandığından, OpenVPN UDP paketinin kaybolması durumunda yeniden iletilir. Aslında bu durumda TCP kullanarak, biri atılacak olandan biri yerine iki yeniden nakil yapacaksınız. Ve DRBD trafiği olmayan oldukça uzun bir pencere yaratıyor olabilirsiniz (bu nedenle kopmaları bile kırılabilir). Rotaya biraz paketlendikten sonra, bunun ne kadar kötü olduğunu düşüneceksiniz.
Fox,

@Fox Açıklama sağladığınız için teşekkür ederiz! Gerçekten de DRBD, TCP kullanmaktadır (drbd.linbit.com/users-guide/s-prepare-network.html). Lairsdragon, daha önce UDP'ye geçme önerisi ile ilgili değildi, çünkü UDP aynı zamanda çok düşük transfer hızları da yaşıyordu;
Elliot B. 2:

1

Birbirine bağlanan iki kıtalararası sunucumuz var, aralarındaki hızlar 220 Mbit / s civarında.

Bununla birlikte (UDP) OpenVPN tüneli içinde, hızlar ortalama olarak 21 Mbit / s - kabaca 10 kat daha yavaş.

(Sunucular arasında önemli bir gecikme var: yaklaşık 130 msn ve transferler TCP modunda Iperf3 kullanılarak ölçüldü.)

Bu yazının sonunda cevaplarla ilgili tüm önerileri denedim ve hiçbir şeyin yardımı olmadı.

Sonunda yardımcı olan tek şey bu küçük oldu:

--txqueuelen 4000

OpenVPN referans kılavuzuna göre:

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

Bu parametreyi sunucuda ve istemcide ayarladıktan sonra, OpenVPN tünelinde de aynı 'doğrudan bağlantı' hızlarına (~ 250Mbit / s) ulaşabildim.

Zaten rcvbuf 0ve kullanıyordum sndbuf 0, ama en azından yalnız , hiç yardımcı olmadı.

Bu önerileri her ikisinde de buldum: bu sayfa OpenVPN forumlarında ve ayrıca bu sayfada UDPspeeder wiki'de .

Başka bir not: Iperf'te UDP transferlerini kullanarak daha yüksek hızlara erişebildim, ancak bunu yapmak da oldukça yüksek bir paket kaybına neden olacaktı.

Şans eseri, iki yeri tünellemek için kaybedilen bağlantılarla VPN kullanmanız gerekiyorsa, VPN'in kendisinde bir tür Doğru Hata Düzeltme (FEC) tüneli kullanmayı düşünmenizi tavsiye ederim. Bulmayı ve birlikte çalışmayı başardığım ikisi:

Her ikisi de, paket paketlemede çok yardımcı olabilir (ilk etapta daha fazla bant genişliği harcayarak) ve nihayetinde, bana sorarsanız gerçekten temiz olan ek yükte bile, daha yüksek veri akışına yol açabilir.

( Paket kaybının gerçekten bir TCP, özellikle de TCP'yi bozabileceği için . Bkz. Sayfa 6.)

Her zamanki nedenlerden dolayı UDP'de OpenVPN'i kullanmayı tercih ederdim, ancak her ikisi de 100ms'den daha az gecikme ve> 10 Mbit / s hıza sahipken UDPspeeder ile uğraşmakta zorlandım.

kcptun ancak gerçekte çok az verdiği ile harika çalıştı ve gerçekten birbirleriyle üretilen iş sunucularımıza arttı. =)

Genişletilmiş bir notta, burada OpenVPN performansının bazı bölümlerinde ince ayar yapılması hakkında daha ayrıntılı açıklamalar bulabilirsiniz.


0

Benim için Japonya'da openvpn server kurulumu olan bir VPS sunucum vardı ve müşteri bağlantım NYC'deki OpenVPN istemci modunda bir DDWRT kullanıyordu. 100 MB'lik bir bağlantıda sadece 1-2 MB / sn alıyordum. En iyi duruma getirebildiğim en iyi şey, 5mbps idi; bu da, ihtiyaç duyduğum şey için yeterliydi;

OpenVPN sunucu ayarlarım:

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

DDWRT OpenVPN istemci ayarlarım ekran görüntüsünde de görüldü:

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

görüntü tanımını buraya girin

görüntü tanımını buraya girin

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.