OpenVPN berkinerja rendah. Apakah saya memiliki masalah MTU? Dumps di dalam

Saya memiliki masalah dengan terowongan OpenVPN yang tidak mencapai kecepatan garis. Gateway adalah server virtual Debian Jessy yang dihosting di OVH. Klien adalah serverer freebsd 10.2 saya (Intel I3 Ivy Bridge) atau RaspberryPI2 saya. Saya menonaktifkan enkripsi dan otentikasi. Saya memiliki koneksi FTTH simetris 100mbit / s tetapi terowongan hanya mencapai kecepatan 20-40mbit / s. Koneksi langsung (tanpa terowongan) selalu menghasilkan 100mbit / s yang saya harapkan. Saya menguji kinerja dengan iperf3. Saya pertama kali mencoba dengan homeserver freebsd saya. Saya mencoba semua pengaturan yang disarankan tentang mssfix, fragmen dll. Tidak ada yang membantu.

Lalu saya pikir mungkin itu adalah mesin freebsd saya. Jadi saya memasang Jess raspbian segar di RPI2 saya dan melakukan beberapa pengujian mendalam:

Pertama-tama saya menghapus semua pengaturan MTU dari konfigurasi OpenVPN dan membiarkan jalur MTU menangani hal-hal (semoga). Karena saya tidak memiliki firewall yang aktif di kedua mesin itu harus berfungsi. Ini adalah konfigurasi vpn saya:

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

Pertama-tama pengujian tanpa terowongan untuk menunjukkan bahwa koneksi ke server memang hampir 100mbit / s:

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.

Paket-paket koneksi ini saya dibuang dengan tcpdump di server. Anda dapat mengunduhnya di sini (Anda harus mengekstrak untuk membukanya dengan wireshark): dumpraw.cap.xz

Jadi begini tampilannya "OK". Ukuran bingkai maksimum yang saya lihat adalah 1514.

Sekarang saya menjalankan tes di atas terowongan:

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.

Aduh. Tidak begitu baik lagi. Terutama kolom "Retr" ini tidak terlihat bagus. Saya berasumsi ini adalah pengiriman tcp dan harus ada sesuatu di dump. Kita akan melihat bahwa bukan itu masalahnya: /. CPU bukanlah penghambat di sini karena saya menonaktifkan enrcyption dan otentikasi. CPU pada 20% di server dan 50% pada PI selama pengujian.

Beginilah tampilan lalu lintas OpenVPN dari tes ini:

Bagi saya ini terlihat oke. Tapi saya tidak tahu harus mencari apa. Silakan lihat dump dengan wireshark: dump_physical.cap.xz

Lalu lintas di antarmuka terowongan juga terlihat bagus bagi saya. Tampaknya ia dengan benar menurunkan ukuran bingkai (menjadi 1444 seperti yang terlihat):

Inilah dumpnya : dump_tunnel.cap.xz

Bagi saya ini terlihat baik-baik saja tetapi saya benar-benar tidak tahu harus mencari apa. Saya benar-benar menguji semuanya dengan pengaturan OpenVPN. Mungkin seseorang bisa memberi tahu saya jika lalu lintas terlihat baik-baik saja.

Apa yang saya harapkan sebagai jawaban

Setidaknya penjelasan apa yang terjadi di sini dan mengapa itu tampaknya tidak tergantung pada perangkat lunak VPN yang saya gunakan. Segala sesuatu yang saya temukan di internet adalah tentang masalah MTU tetapi itu harus dengan mudah diperbaiki dengan mengurangi MTU terowongan atau parameter OpenVPN lainnya. Bagi saya ini sedikit berubah. Ketika Anda melihat dump Anda melihat bahwa itu mengurangi ukuran segmen tcp dan paket tidak terfragmentasi. Pasti ada sesuatu yang lain. Saya sangat ingin tahu apa .

Memperbarui

Saya menguji ini dengan strongswan dan bahkan dengan softether. Ini sebenarnya masalah yang sama (kecepatan sebanding, tidak ada hambatan cpu). Saya benar-benar bingung apa masalahnya di sini. Saya juga mencoba gateway lain (RaspberryPi2 pada koneksi rumah teman 100/100).

Perbarui 2

Saya perhatikan bahwa iperf3 melaporkan pengiriman tcp (ret) tetapi tidak ada pengiriman ulang di tempat sampah (Wireshark harus menyorotnya). Apa yang sedang terjadi?

Saya bahkan mencoba OpenVPN di Jaringan lokal saya (RaspberryPi2 ke FreebsdServer). Bahkan di sana saya memiliki banyak transmisi ulang (di LAN ?!):

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

Dalam mode terbalik, saya memiliki jendela kemacetan yang sangat aneh (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

Perbarui 3

Menggunakan iperf dengan udp menghasilkan ovh sementara memblokir port itu (mereka mengirimi saya email yang memberi tahu saya tentang serangan) dan hilangnya paket besar-besaran:

-----------------------------------------------------------
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
sumber

Jika Anda belum selesai, saya harap Anda dapat mencobanya: tun-mtu 9000 fragment 0 mssfix 0(opsi perlu ditambahkan dalam tiga baris berbeda)

— Diamant

Saya sudah mengujinya. Tapi saya uji lagi. Apa yang terjadi adalah bahwa ia dimulai dengan kecepatan yang sama tetapi kemudian koneksi terhenti. Omong-omong, itu selalu terjadi ketika saya menonaktifkan fragmentasi paket OpenVPN. Komunitas panduan ini.openvpn.net/openvpn/wiki/Gigabit_Networks membuat Anda berpikir OS harus menanganinya tetapi jelas tidak.

— Alexander Theißen

Oh wow. Saya melihat perilaku yang sama persis pada VPN saya, dan saya memiliki perangkat keras gemuk di kedua ujungnya dan koneksi internet yang lebih lambat. Saya akan menyelidiki lebih lanjut; jika saya menemukan sesuatu yang konkret saya akan memposting kembali ke sini.

— Harald

Jika saya mengalihkan pengujian saya ke UDP (iperf3 -u -b 25m) saya mendapatkan kecepatan penuh baik di dalam maupun di luar terowongan openvpn. Saya telah mengkonfirmasi bahwa tidak ada fragmentasi saat menggunakan TCP - openvpn dengan benar melaporkan MSS kecil, paket tcp saya di dalam terowongan semuanya 1354 byte, dan paket UDP tiba tanpa fragmentasi. Saya melihat fenomena yang sama seperti Anda - nilai CWND di dalam terowongan sekitar setengah dari apa yang ada di luar terowongan, dan throughputnya setengah juga, tapi saya bingung menjelaskan mengapa . Menarik.

— Harald

Oke, permintaan maaf saya karena menciptakan harapan palsu. Mencoba menghilangkan sejumlah besar variabel, saya mengatur OpenVPN dengan parameter konfigurasi yang sama, berjalan di LAN lokal saya. Di luar terowongan, 750Mbps. Di dalam terowongan, 117Mbps. Tetapi - openvpn mengkonsumsi 100% inti CPU tunggal pada kedua titik akhir. Jadi saya memindahkan endpoint rumah dari terowongan Internet saya ke server "nyata" dan melihat 25Mbps yang diharapkan melalui terowongan saya. OpenVPN pada kedua titik akhir mengkonsumsi sekitar 20% CPU. Singkat cerita - dalam kasus saya, masalahnya adalah titik akhir terowongan sisi rumah saya terikat CPU. Maaf!

— Harald

Sebagai permulaan, jalankan normal Anda di luar terowongan iperf harus UDP / 1194 sebagai aliran di mana Anda memiliki masalah dan bukan TCP / 5201. Coba dengan -b 100M terlebih dahulu tetapi perlu diingat ini akan menghasilkan datagram ukuran maks yang tidak mewakili lalu lintas VPN Anda (ukuran datagram harus agak acak). Tune dengan opsi -l untuk ukuran datagram dan periksa hasilnya. Jika hasilnya tidak baik (saya akan mengatakan> 15 atau 20% kehilangan) Anda mungkin mencurigai router Internet kelebihan beban yang menjatuhkan paket (mungkin ditandai upaya terbaik) Anda.

Juga, mungkin menarik untuk melihat kinerja apa yang Anda dapatkan jika Anda mengalihkan terowongan VPN Anda ke port EF Class UDP (saya katakan 5061 karena RTP, tetapi tidak benar-benar yakin bahwa semua router internet telah mengkonfigurasi QoS dengan benar) atau Port TCP.

Bagi saya, tidak ada yang salah dengan pengaturan Anda dan diagnostik Anda tidak menunjukkan sesuatu yang aneh. Juga, coba versi lain dari OpenVPN atau perangkat lunak VPN lainnya.

— 30gd4n
sumber

Lakukan itu. Lihatlah pembaruan3. Menunggu ovh untuk membuka blokir port untuk melakukan tes lebih lanjut.

— Alexander Theißen

Aww, maaf, tidak melihat pembaruan terakhir itu. Sambil menunggu OVH coba pasang VPN Anda melalui TCP; apa hasilnya? Juga tentang edit kedua Anda dan kirim kembali dari * BSD ke PI; Sudahkah Anda bermain dengan buffer server iperf? Ini standar 8kb, tidak tahu bagaimana stack dibuat pada ARM dan Linux tapi saya yakin meningkatkannya bisa membantu.

— 30gd4n

Maksud saya, saya menambahkannya setelah Anda menyuruh saya :). Hasil lebih dari tcp lebih buruk. Tcp 443 tidak membuat perbedaan. Yang lucu adalah ketika saya menggunakan github.com/sivel/speedtest-cli ini untuk menguji laporan ini turun 95m dan 75m ke atas. Saya lebih mempercayai iperf tapi itu benar-benar tergantung pada jenis lalu lintas jadi sepertinya. Playstation4 juga membutuhkan waktu lebih lama untuk mengunduh game atau tambalan di atas terowongan. Ketika di rumah saya akan melakukan terowongan langsung antara dua Rbps yang berada di lokasi yang berbeda tetapi menggunakan ISP yang sama. Saya melakukan itu sebelumnya dan hasilnya di mana hampir sama. Tetapi saya mencoba melakukan tes lebih lanjut.

— Alexander Theißen