OpenVPN düşük performans. MTU sorunum var mı? İçerideki çöplükler

Hat hızına ulaşmayan bir OpenVPN tüneli ile sorunlarım var. Ağ geçidi, OVH'de barındırılan bir Debian Jessy sanal sunucusudur. İstemci ya freebsd 10.2 ev sunucum (Intel I3 Ivy Bridge) ya da RaspberryPI2'm. Şifrelemeyi ve kimlik doğrulamayı devre dışı bıraktım. 100mbit / s simetrik bir FTTH bağlantım var ancak tünel sadece 20-40mbit / s hıza ulaşıyor. Doğrudan bağlantı (tünel olmadan) her zaman beklediğim 100mbit / sn değerini verir. Performansı iperf3 ile test ettim. İlk önce freebsd ev sunucumla denedim. Mssfix, fragment vb. İle ilgili önerilen tüm ayarları denedim. Hiçbir şey yardımcı olmadı.

Sonra belki benim freebsd makinem olduğunu düşündüm. Bu yüzden RPI2'ye yeni bir raspbian Jessy taktım ve daha derinlemesine testler yaptım:

Her şeyden önce tüm MTU ayarlarını OpenVPN yapılandırmalarından kaldırdım ve yol MTU'nun şeyleri işlemesine izin verdim (umarım). Her iki makinede de aktif bir güvenlik duvarım olmadığından çalışması gerekir. Bunlar benim vpn yapılandırmaları:

server 10.8.0.0 255.255.255.0
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0

user nobody
group nogroup
persist-key
persist-tun
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1"
status openvpn-status.log
verb 3

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.theissen.io.crt
key /etc/openvpn/easy-rsa/keys/vpn.theissen.io.key
dh /etc/openvpn/easy-rsa/keys/dh4096.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher none
auth none
comp-lzo no



client
proto udp
dev tun12
remote xxx.io 1194
resolv-retry infinite
sndbuf 0
rcvbuf 0

nobind
user nobody
group nogroup
persist-key
persist-tun
verb 3

pkcs12 /etc/openvpn/vpn.theissen.io/alex.p12
tls-auth /etc/openvpn/vpn.theissen.io/ta.key 1
ns-cert-type server
cipher none
auth none
comp-lzo no

Her şeyden önce, sunucuya bağlantının gerçekten 100mbit / s olduğunu göstermek için tünel olmadan yapılan test:

iperf3 -c vpn.theissen.io
Connecting to host vpn.theissen.io, port 5201
[  4] local 192.168.1.253 port 34512 connected to 149.202.58.183 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  10.8 MBytes  90.5 Mbits/sec    0    335 KBytes       
[  4]   1.00-2.00   sec  11.4 MBytes  95.7 Mbits/sec    0    335 KBytes       
[  4]   2.00-3.00   sec  11.1 MBytes  93.0 Mbits/sec    0    352 KBytes       
[  4]   3.00-4.00   sec  11.2 MBytes  94.0 Mbits/sec    0    369 KBytes       
[  4]   4.00-5.00   sec  11.5 MBytes  95.9 Mbits/sec    0    390 KBytes       
[  4]   5.00-6.00   sec  11.0 MBytes  92.5 Mbits/sec    0    390 KBytes       
[  4]   6.00-7.00   sec  11.4 MBytes  95.2 Mbits/sec    0    390 KBytes       
[  4]   7.00-8.00   sec  11.2 MBytes  94.3 Mbits/sec    0    390 KBytes       
[  4]   8.00-9.00   sec  11.1 MBytes  93.3 Mbits/sec    0    390 KBytes       
[  4]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec    0    390 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  93.9 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  93.5 Mbits/sec                  receiver

iperf Done.

Bu bağlantının paketleri sunucuda tcpdump ile boşaltıldım. Bunları buradan indirebilirsiniz (wireshark ile açmak için çıkarmanız gerekir): dumpraw.cap.xz

Yani bir "OK" dökümü böyle görünüyor. Tespit ettiğim maksimum çerçeve boyutu 1514.

Şimdi testi tünelden geçtim:

iperf3 -c 10.8.0.1
Connecting to host 10.8.0.1, port 5201
[  4] local 10.8.0.14 port 36388 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  5.96 MBytes  50.0 Mbits/sec  127    133 KBytes       
[  4]   1.00-2.00   sec  5.19 MBytes  43.5 Mbits/sec    6    120 KBytes       
[  4]   2.00-3.00   sec  5.80 MBytes  48.7 Mbits/sec    0    151 KBytes       
[  4]   3.00-4.00   sec  4.27 MBytes  35.9 Mbits/sec   23   96.5 KBytes       
[  4]   4.00-5.00   sec  4.89 MBytes  41.0 Mbits/sec    0    129 KBytes       
[  4]   5.00-6.00   sec  6.11 MBytes  51.2 Mbits/sec   26    111 KBytes       
[  4]   6.00-7.00   sec  5.50 MBytes  46.1 Mbits/sec    0    143 KBytes       
[  4]   7.00-8.00   sec  5.25 MBytes  44.1 Mbits/sec   15    126 KBytes       
[  4]   8.00-9.00   sec  5.80 MBytes  48.7 Mbits/sec    0    158 KBytes       
[  4]   9.00-10.00  sec  3.97 MBytes  33.3 Mbits/sec   22    105 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  52.7 MBytes  44.2 Mbits/sec  219             sender
[  4]   0.00-10.00  sec  52.3 MBytes  43.8 Mbits/sec                  receiver

iperf Done.

Whoops. Artık çok hoş değil. Özellikle bu "Retr" sütunu pek iyi görünmüyor. Bunun tcp yeniden iletimi olduğunu ve dökümünde bir şey olması gerektiğini varsaydım. Durumun böyle olmadığını göreceğiz:. CPU, buradaki darboğaz değil çünkü enrcyption ve kimlik doğrulamayı devre dışı bıraktım. CPU, test sırasında sunucuda% 20 ve PI'da% 50'dir.

Testin OpenVPN trafiği şöyle görünür:

Bana göre bu iyi görünüyor. Ama ne arayacağımı bilmiyorum. Lütfen wireshark ile çöp kutusuna bir göz atın: dump_physical.cap.xz

Tünel arayüzündeki trafik de bana iyi geliyor. Görünüşe göre çerçeve boyutunu doğru bir şekilde indirdi (göründüğü gibi 1444'e):

İşte döküm: dump_tunnel.cap.xz

Bana göre bu iyi görünüyor ama tam olarak ne arayacağımı bilmiyorum. OpenVPN ayarlarıyla her şeyi gerçekten test ettim. Belki birisi bana trafiğin iyi göründüğünü söyleyebilir.

Cevap olarak ne bekliyorum

En azından burada neler olduğunu ve neden kullandığım VPN yazılımından bağımsız olduğunu gösteren bir açıklama. İnternette bulduğum her şey MTU sorunları hakkındaydı, ancak MTU tüneli veya OpenVPN'in diğer parametrelerini azaltarak kolayca düzeltilmelidir. Benim için bu çok az değişiyor. Döküme baktığınızda, tcp segment boyutunu azalttığını ve paketlerin parçalanmadığını görürsünüz. Başka bir şey olmalı. Gerçekten ne olduğunu bilmek hoşuma gidiyor .

Güncelleme

Bunu strongswan ve hatta yumuşatıcı ile test ettim. Aslında aynı sorun (karşılaştırılabilir hız, cpu darboğaz yok). Buradaki sorunun ne olduğunu gerçekten şaşırdım. Ayrıca başka bir ağ geçidi denedim (RaspberryPi2 arkadaşlarına 100/100 ev bağlantısı).

Güncelleme 2

Iperf3 tcp retransmits (retr) raporları fark ettim ama dökümünde hiç retransm (Wireshark onları vurgulamalı) yoktur. Ne oluyor?

Hatta yerel ağımda OpenVPN denedim (RasebberryPi2 to FreebsdServer). Orada bile (LAN ?!) çok sayıda yeniden iletim var:

Connecting to host 192.168.222.11, port 5201
[  4] local 192.168.222.10 port 46196 connected to 192.168.222.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  9.19 MBytes  77.0 Mbits/sec    8    141 KBytes       
[  4]   1.00-2.00   sec  8.71 MBytes  73.1 Mbits/sec    3    130 KBytes       
[  4]   2.00-3.00   sec  8.59 MBytes  72.0 Mbits/sec    3    120 KBytes       
[  4]   3.00-4.00   sec  8.65 MBytes  72.5 Mbits/sec    4    108 KBytes       
[  4]   4.00-5.00   sec  8.65 MBytes  72.5 Mbits/sec    4   95.6 KBytes       
[  4]   5.00-6.00   sec  8.52 MBytes  71.5 Mbits/sec    2   80.5 KBytes       
[  4]   6.00-7.00   sec  8.83 MBytes  74.1 Mbits/sec    0    141 KBytes       
[  4]   7.00-8.00   sec  8.59 MBytes  72.0 Mbits/sec    7    106 KBytes       
[  4]   8.00-9.00   sec  8.71 MBytes  73.1 Mbits/sec    3   94.2 KBytes       
[  4]   9.00-10.00  sec  8.59 MBytes  72.0 Mbits/sec    3   79.2 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec   37             sender
[  4]   0.00-10.00  sec  86.8 MBytes  72.8 Mbits/sec                  receiver

Ters modda gerçekten garip bir tıkanıklık penceresi var (wtf?):

Accepted connection from 192.168.222.10, port 46197
[  5] local 192.168.222.11 port 5201 connected to 192.168.222.10 port 46198
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec  8.90 MBytes  74.7 Mbits/sec    3   1.48 GBytes       
[  5]   1.00-2.00   sec  8.45 MBytes  70.9 Mbits/sec    2   1.59 GBytes       
[  5]   2.00-3.00   sec  8.66 MBytes  72.7 Mbits/sec  518    214 MBytes       
[  5]   3.00-4.00   sec  7.96 MBytes  66.8 Mbits/sec   37    703 MBytes       
[  5]   4.00-5.00   sec  8.09 MBytes  67.9 Mbits/sec    0    719 MBytes       
[  5]   5.00-6.00   sec  8.04 MBytes  67.5 Mbits/sec    0    734 MBytes       
[  5]   6.00-7.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   7.00-8.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   8.00-9.00   sec  7.99 MBytes  67.1 Mbits/sec    2    693 MBytes       
[  5]   9.00-10.00  sec  8.06 MBytes  67.6 Mbits/sec    1    693 MBytes       
[  5]  10.00-10.09  sec   684 KBytes  64.5 Mbits/sec    0    695 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.09  sec  83.0 MBytes  69.0 Mbits/sec  565             sender
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec                  receiver

Güncelleme 3

Iperf'i udp ile kullanmak, o bağlantı noktasını geçici olarak engeller (bana bir saldırı hakkında beni bilgilendiren bir e-posta gönderir) ve büyük paket kaybı ile sonuçlanır:

-----------------------------------------------------------
Server listening on 1194
-----------------------------------------------------------
Accepted connection from 185.22.143.160, port 15906
[  5] local 149.202.58.183 port 1194 connected to 185.22.143.160 port 4355
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.89 MBytes  24.2 Mbits/sec  0.727 ms  1017/1387 (73%)  
iperf3: OUT OF ORDER - incoming packet = 1409 and received packet = 1470 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1410 and received packet = 1471 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1411 and received packet = 1472 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1445 and received packet = 1473 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1463 and received packet = 1473 AND SP = 5
[  5]   1.00-2.00   sec  3.29 MBytes  27.6 Mbits/sec  0.716 ms  1110/1526 (73%)  
[  5]   2.00-3.00   sec  3.30 MBytes  27.7 Mbits/sec  0.732 ms  1103/1526 (72%)  
[  5]   3.00-4.00   sec  3.27 MBytes  27.4 Mbits/sec  0.717 ms  1108/1526 (73%)  
[  5]   4.00-5.00   sec  1.56 MBytes  13.1 Mbits/sec  0.837 ms  546/746 (73%)  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]  10.00-10.06  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec   118 MBytes  98.5 Mbits/sec  0.837 ms  4884/6711 (73%)  
[SUM]  0.0-10.1 sec  4884 datagrams received out-of-order

— Alexander Theißen
kaynak

Henüz yapmadıysanız, benim olmanız bir deneyebilirsiniz: tun-mtu 9000 fragment 0 mssfix 0(seçeneklerin üç farklı satıra eklenmesi gerekir)

— Diamant

Bunu zaten test ettim. Ama tekrar test ettim. Olan şey aynı hızda başlaması ama sonra bağlantıların durması. Bu arada OpenVPN paket parçalanmasını devre dışı bıraktığımda her zaman olur. Bu kılavuz community.openvpn.net/openvpn/wiki/Gigabit_Networks , işletim sisteminin bunu halletmesi gerektiğini düşünüyor, ancak açık değil.

— Alexander Theißen

Vay canına. VPN'lerimde aynı davranışı görüyorum ve her iki uçta da donanım donanımım ve daha yavaş bir internet bağlantısı var. Daha fazla araştıracağım; somut bir şey bulursam buraya geri göndereceğim.

— Harald

Testimi UDP'ye (iperf3 -u -b 25m) değiştirirsem openvpn tünelinin içinde ve dışında tam hız elde ederim. TCP kullanırken bir parçalanma olmadığını doğruladım - openvpn doğru bir şekilde küçük bir MSS bildiriyor, tünel içindeki tcp paketlerim 1354 bayt ve UDP paketleri parçalanmamış olarak geliyor. Seninle aynı fenomeni görüyorum - tünel içindeki CWND değerleri tünelin dışındakilerin yaklaşık yarısı ve iş hacmi de yarı yarıya, ama nedenini açıklamakta bir kayıptayım . Büyüleyici.

— Harald

Tamam, yanlış umut yarattığım için özür dilerim. Bir sürü değişkeni ortadan kaldırmaya çalışarak, yerel LAN'ımda çalışan aynı yapılandırma parametrelerine sahip bir OpenVPN kurdum. Tünelin dışında 750Mbps. Tünelin içinde 117Mbps. Ancak - openvpn, her iki uç noktada da tek bir CPU çekirdeğinin% 100'ünü tüketiyordu. Sonra internet tünelimin ana uç noktasını "gerçek" bir sunucuya taşıdım ve tünelimden beklenen 25 Mbps'yi gördüm. Her iki uç noktasında OpenVPN yaklaşık% 20 CPU tüketiyordu. Uzun lafın kısası - benim durumumda sorun, ev tarafı tünel uç noktamın CPU'ya bağlı olması. Afedersiniz!

— Harald

Yeni başlayanlar için 'normal' dış tünel iperf çalıştırmanız TCP / 5201 değil, problemin olduğu akış olarak UDP / 1194 olmalıdır. İlk önce -b 100M ile deneyin, ancak bunun VPN trafiğinizi temsil etmeyen maksimum boyutta datagramlar üreteceğini unutmayın (datagram boyutu sorta rastgele olmalıdır). Datagram boyutu için -l seçeneği ile ayarlayın ve sonuçları kontrol edin. Sonuçlar iyi değilse (> 15 veya% 20 kayıp) diyebilirim, aşırı yüklenmiş bir İnternet yönlendiricisinden şüphelenebilirsiniz (muhtemelen en iyi çaba) işaretli paketler.

Ayrıca, VPN tünelinizi bir EF Sınıf UDP bağlantı noktasına (RTP nedeniyle 5061 diyebilirim, ancak tüm internet yönlendiricilerinin QoS'yi doğru bir şekilde yapılandırdığından emin değilseniz) veya TCP bağlantı noktası.

Bana göre, kurulumunuzda yanlış bir şey yok ve teşhisiniz garip bir şey göstermiyor. Ayrıca, OpenVPN'in veya başka bir VPN yazılımının başka bir sürümünü deneyin.

— 30gd4n
kaynak

Yaptım. Güncelleme 3'e bakın. Daha fazla test yapmak için ovh bağlantı noktasının engelini kaldırmayı bekliyor.

— Alexander Theißen

Aww, üzgünüm, son güncellemeyi görmedim. OVH'yi beklerken VPN'nizi TCP üzerinden monte etmeyi deneyin; sonuçlar ne? Ayrıca ikinci düzenlemeniz ve * BSD'den PI'ya yeniden aktarım hakkında; iperf'in sunucu arabellekleriyle oynadın mı? Bu 8kb varsayılan, yığının ARM ve Linux'ta nasıl yapıldığını bilmiyorum ama artan guees yardımcı olabilir.

— 30gd4n

Bana söyledikten sonra ekledim demek istedim :). Tcp üzerindeki sonuçlar daha kötüdür. Tcp 443 bir fark yaratmaz. Komik olan şey bu github.com/sivel/speedtest-cli test için 95 m aşağı ve 75 m rapor rapor olmasıdır. Ben daha iperf güven ama gerçekten trafik türüne bağlıdır, bu yüzden görünüyor. Playstation4'ün tünel üzerinden oyun veya yama indirmesi de daha uzun sürer. Eve geldiğimde, farklı yerlerde bulunan ancak aynı isp'yi kullanan iki Rbps arasında doğrudan bir tünel yapacağım. Bunu daha önce yaptım ve sonuçları neredeyse aynı. Ama daha fazla test yapmaya çalışıyorum.

— Alexander Theißen