Bagaimana cara meningkatkan keandalan OpenVPN melalui tautan latensi tinggi?

11

Kami menjalankan OpenVPN VPN melalui tautan satelit BGAN di mana waktu ping sekitar 3 detik. Kami menggunakannya dalam konfigurasi tun , dan kami berjalan di Linux (CentOS). Ini terutama email yang akan dikirim melalui tautan, tetapi begitu email berisi lampiran besar, VPN tampaknya terhenti.

The "Aku bisa ping melalui terowongan, tapi pekerjaan nyata menyebabkan ia mengunci. Apakah ini masalah MTU?" pertanyaan dalam FAQ OpenVPN tampaknya menggambarkan masalah saya dengan tepat, tetapi menggunakan mssfixdan fragmentmasih tampaknya tidak berbuat banyak untuk memperbaiki situasi.

Tes utama saya adalah menyalin file 2MB melalui VPN dengan scp . Ini akan menyalin sekitar 192 kbytes, dan kemudian melaporkan negara - macet - . Jika saya menunggu beberapa detik, itu akan mulai menyalin lagi, dan kemudian berhenti lagi setelah beberapa kbytes.

Kemacetan ini terjadi terlepas dari apakah saya telah mengatur opsi fragmentatau tidak mssfixdalam konfigurasi OpenVPN saya (walaupun pengaturan fragment 1000tampaknya mengurangi penghentian, tetapi tidak menghilangkannya). OpenVPN mtu-testmelaporkan 1542 sebagai ukuran MTU.

Saya telah mencari di internet untuk saran lebih lanjut tentang bagaimana dan kapan untuk menggunakan mssfixdan fragment, tetapi saya hanya menemukan halaman yang mengatakan hal yang sama dengan FAQ, dan tidak memberikan rincian tentang bagaimana dan kapan menggunakan parameter mana.

Maka pertanyaan saya adalah:

  • Kapan saya menggunakan mssfixdan fragment?
  • Apakah saya menggunakan mssfixdan fragmentdalam kombinasi?
  • Jika mssfixdan fragmentapakah solusinya, untuk apa tun-mtu, link-mtudan mtu-discparameternya?

Selanjutnya, saya telah menggunakan alat iperf untuk mengukur bandwidth. Tanpa VPN, itu terus-menerus mengukur dalam urutan 210Kbits / detik.

Saat menggunakan iperf melalui VPN ( $ iperf -c remoteserver -t60 -i5), itu akan mulai dari 10Kbits / detik, kemudian naik dengan stabil sampai melaporkan 1.2Mbits / detik, dan kemudian akan macet, di mana ia melaporkan 0kbits / detik untuk sejumlah iterasi (I pikir 1.2Mbit / detik mungkin karena beberapa penyangga OpenVPN atau sebagainya)

Apakah iperf cara terbaik untuk mengukur bandwidth?

Bantuan apa pun dengan situasi ini akan sangat dihargai.

openvpn iWerner
sumber
Apakah openvpn menggunakan TCP atau UDP saat ini?
pjc50
Saat ini menggunakan UDP
iWerner
Terima kasih atas semua jawabannya, tetapi saya harus berhenti sementara karena unit BGAN kehabisan airtime. Saya berharap untuk cointinue hari ini. Saya harus menyebutkan bahwa kita akan lebih suka tinggal dengan UDP, dengan menggunakan TCP akan menggandakan data yang dikirim melalui jaringan (dan karenanya biaya, yang klien kami sudah sangat sensitif)
iWerner

Jawaban:

5

1542 sebagai MTU? Belum pernah mendengar hal itu untuk tautan WAN. Biasanya, MTU adalah payload maks, ukuran paket ip minus header untuk IP (20 byte) dan ICMP (8 byte). Itu berarti MTU = 1500 untuk LAN Ethernet tradisional. Selain itu, sebagian besar VPN memperkenalkan overhead untuk enkapsulasi paket mereka. MTU VPN pada umumnya adalah 1400.

Dalam jaringan modern, sulit untuk menyimpulkan MTU apa yang akan terjadi kapan saja, karena jalur masuk dan keluar mungkin berbeda, dan mereka juga dapat berubah karena rute-ulang jalur otomatis. Untuk jaringan seperti ini, mungkin lebih efektif untuk menetapkan MTU rendah pada host Anda yang berada di kedua sisi tautan VPN, seperti 576.

MSS (ukuran segmen maksimum) adalah MTU minus tajuk IP + TCP (40 byte). Ini biasanya dinegosiasikan oleh tumpukan jaringan, dan biasanya tidak memiliki masalah negosiasi yang sama dengan MTU, kecuali MTU salah. (Negosiasi MTU biasanya terganggu oleh ICMP yang diblokir atau router lubang hitam).

Hal pertama yang akan saya lakukan adalah melakukan capture paket jaringan pada akhir pengiriman Anda, dan mengurutkan tampilan berdasarkan ukuran frame (Anda mungkin perlu menambahkan kolom ini di Wireshark). Anda harus memverifikasi bahwa Anda tidak mengirim bingkai yang terlalu besar, seperti yang Anda harapkan. Bukan hal yang aneh bagi kartu jaringan modern untuk mengirim frame yang terlalu besar jika opsi seperti Large Send Offload atau Jumbo Frames diaktifkan. Saya telah melihat 30.000+ frame byte ketika opsi ini diaktifkan.

Greg Askew
sumber
+1 untuk penangkapan paket sebelum mengubah apa pun. bahkan jika Anda tidak menemukan bingkai besar, Anda mungkin melihat paket 'normal' terfragmentasi di suatu tempat.
Javier
1
Secara default OpenVPN menetapkan MTU perangkat tun menjadi 1500 (yang sama dengan MTU pada perangkat ethernet pada mesin kami). Saya masih tidak yakin apakah fragmentasi paket VPN adalah hal yang baik atau buruk. Jawaban di utas ini tampaknya menyiratkan bahwa itu buruk, sedangkan referensi lain yang saya temukan di web menyiratkan bahwa itu baik.
iWerner
2
@ Wagerner: sudahkah Anda mencoba menentukan ukuran mtu dengan ping? Jika ICMP tidak dinonaktifkan di suatu tempat, Anda dapat menggunakan yang berikut ini di windows: ping -f -l 1372 <destination ip>. Terus kurangi jumlahnya sampai berhasil. Di linux, ping -s 1372 -M lakukan <tujuan ip>. FYI, FAQ OpenVPN merekomendasikan untuk menggunakan mssfix 1200, tetapi itu tidak mengatasi akar masalah. Menggunakan solusi VPN untuk memecah selalu memiliki potensi untuk hit kinerja. Jika Anda memiliki pengaturan VPN yang besar, Anda tidak akan dapat menggunakan fragmentasi di ujung pusat konsentrator, hanya ujung kantor jarak jauh.
Greg Askew.
2

Hanya ingin tahu, apakah Anda mencoba menurunkan MTU antarmuka jaringan? Mungkin tautan satelit merusak fragmentasi dengan buruk. Sebagai catatan kontra-intuitif, Anda mungkin ingin mencoba openvpn melalui TCP untuk perubahan. Saya tahu itu harus mengurangi kinerja, tetapi jika Anda tidak memiliki kontrol atas fragmentasi di sepanjang garis itu mungkin membantu Anda.

lorenzog
sumber
Saya akan menyarankan yang sebaliknya :) - kasus latensi tinggi ini adalah di mana masalah TCP-in-TCP muncul dan UDP akan menghindarinya.
pjc50
Saya berasumsi dia menggunakan port UDP default untuk openvpn, dan dengan demikian menyarankan sebaliknya .. ya, biasanya saya setuju dengan Anda. Tapi hei, kita semua tahu bahwa sysadmin adalah trial-and-error, dan biasanya 'coba-lakukan-sebaliknya-lihat-jika-itu-berhasil' :)
lorenzog
Terima kasih. Kami menggunakan UDP saat ini, dan mencoba TCP tidak pernah terjadi pada saya. (Jika saya punya lebih banyak perwakilan saya akan
terbalik
@ iWerner: terima kasih :) juga, coba kurangi MTU secara progresif di iface, dan lihat kapan MTU berhenti (jika ya).
lorenzog
2

Saat Anda menggunakan TCP, tambah ukuran jendela TCP; ini akan membantu dengan "jumlah paket di udara".

Sudah lama sejak saya harus bermain dengan hal ini, tetapi di sini ada satu tautan yang ditemukan google untuk saya.

Setelah saya membaca kembali pertanyaan Anda, saya melihat Anda menjalankan BGAN - Saya akan senang melihat ini (atau hanya google untuk: "BGAN spoofing").

Adapun pengukuran bandwidth, saya telah menemukan iperf cukup baik selama Anda menggunakan ukuran paket yang masuk akal.

Eddy
sumber
Ini menarik - Disebutkan bahwa akselerator TCP tersedia untuk Redhat, sementara orang-orang inmarsat yang kami ajak bicara mengatakan bahwa itu hanya tersedia untuk Windows dan OS X (dan inilah yang dikatakan oleh situs web Inmarsat / BGAN)
iWerner
Mereka mungkin tidak memilikinya sekarang; Saya melihat tanggal dokumen adalah 07. Jika Anda mendorong cukup keras dan berbicara dengan cukup banyak orang; Anda mungkin menemukan seseorang dengan salinannya yang lama. Umumnya ketika telepon Anda masuk, Anda mendapatkan dukungan tingkat satu. Saya akan mencoba beberapa kontak saya tetapi tidak ada jaminan.
Eddy
Saya mendapatkan pelarian dari penyedia satelit kami; sulit menemukan seseorang yang tahu apa yang mereka bicarakan. Saya akan terus mencoba, sementara itu di sini adalah sesuatu untuk dicoba: sourceforge.net/projects/pepsal Dari uraian proyek itu melakukan apa yang dilakukan oleh perangkat lunak Inmarsat: PEPsal adalah TCP terintegrasi, multi-layer, transparan Kinerja Meningkatkan Proksi yang membagi koneksi menjadi dua bagian, memanfaatkan perangkat tambahan Linux TCP saat mengirim data, dan sebagian besar meningkatkan kinerja dalam tautan dengan karakteristik yang berbeda
Eddy
2

Saya pikir Anda mungkin menggonggong di pohon yang salah. Setiap kali saya memiliki masalah MTU yang salah, lalu lintas berhenti jauh sebelum 192KB. Saya pikir ini lebih terkait dengan beberapa di "paket penerbangan" jendela, baik jendela TCP, atau mungkin beberapa buffer di satelit uplink itu sendiri.

Pasti melakukan beberapa menangkap paket lama (baik 'di dalam' dan 'luar' dari VPN) dan melihat apakah Anda mendapatkan semua ACK's

Javier
sumber