Rincian baru ditambahkan di akhir pertanyaan ini; mungkin saya memusatkan perhatian pada penyebabnya.
Saya memiliki VPN berbasis UDP OpenVPN yang diatur dalam tap
mode (saya perlu tap
karena saya membutuhkan VPN untuk melewati paket multicast, yang sepertinya tidak mungkin dilakukan dengan tun
jaringan) dengan beberapa klien di Internet. Saya sering mengalami koneksi TCP yang membeku melalui VPN. Yaitu, saya akan membuat koneksi TCP (mis. Koneksi SSH, tetapi protokol lain memiliki masalah yang sama), dan pada beberapa titik selama sesi, tampaknya lalu lintas akan berhenti ditransmisikan melalui sesi TCP.
Ini tampaknya terkait dengan titik-titik di mana transfer data besar terjadi, seperti jika saya menjalankan ls
perintah dalam sesi SSH, atau jika saya cat
file log yang panjang. Beberapa pencarian Google menghasilkan sejumlah jawaban seperti ini sebelumnya di Server Fault , menunjukkan bahwa kemungkinan penyebabnya adalah masalah MTU: bahwa selama periode lalu lintas tinggi, VPN sedang mencoba mengirim paket yang jatuh di suatu tempat di dalam pipa di antara Titik akhir VPN. Jawaban yang ditautkan di atas menyarankan menggunakan pengaturan konfigurasi OpenVPN berikut untuk mengurangi masalah:
fragment 1400
mssfix
Ini harus membatasi MTU yang digunakan pada VPN hingga 1400 byte dan memperbaiki ukuran segmen maksimum TCP untuk mencegah pembuatan paket apa pun yang lebih besar dari itu. Ini agak mengurangi masalah, tapi saya masih sering melihat pembekuan. Saya telah mencoba sejumlah ukuran sebagai argumen untuk fragment
arahan: 1200, 1000, 576, semua dengan hasil yang serupa. Saya tidak dapat memikirkan topologi jaringan aneh antara kedua ujung yang dapat memicu masalah seperti itu: server VPN sedang berjalan pada a mesin pfSense yang terhubung langsung ke Internet, dan klien saya juga terhubung langsung ke Internet di lokasi lain.
Satu teka-teki aneh lainnya: jika saya menjalankan tracepath
utilitas, maka itu tampaknya membantu masalah. Contoh menjalankan terlihat seperti:
[~]$ tracepath -n 192.168.100.91
1: 192.168.100.90 0.039ms pmtu 1500
1: 192.168.100.91 40.823ms reached
1: 192.168.100.91 19.846ms reached
Resume: pmtu 1500 hops 1 back 64
Jalankan di atas adalah antara dua klien di VPN: Saya memulai jejak dari 192.168.100.90
ke tujuan 192.168.100.91
. Kedua klien dikonfigurasikan denganfragment 1200; mssfix;
upaya membatasi MTU yang digunakan pada tautan. Hasil di atas tampaknya menunjukkan bahwa tracepath
mampu mendeteksi jalur MTU sebesar 1500 byte antara kedua klien. Saya akan berasumsi bahwa itu akan menjadi lebih kecil karena pengaturan fragmentasi yang ditentukan dalam konfigurasi OpenVPN. Saya menemukan hasil yang agak aneh.
Namun yang lebih aneh lagi: jika saya memiliki koneksi TCP dalam status macet (mis. Sesi SSH dengan daftar direktori yang membeku di tengah), kemudian menjalankan tracepath
perintah yang ditunjukkan di atas menyebabkan koneksi untuk memulai lagi ! Saya tidak dapat menemukan penjelasan yang masuk akal mengapa ini bisa terjadi, tetapi saya merasa ini mungkin mengarah ke solusi untuk akhirnya memberantas masalah.
Adakah yang punya rekomendasi untuk mencoba hal lain?
Sunting: Saya telah kembali dan melihat ini sedikit lebih jauh, dan hanya menemukan informasi yang lebih membingungkan:
Saya mengatur koneksi OpenVPN ke fragmen pada 1400 byte, seperti yang ditunjukkan di atas. Kemudian, saya terhubung ke VPN dari seluruh Internet dan menggunakan Wireshark untuk melihat paket-paket UDP yang dikirim ke server VPN ketika kios itu terjadi. Tidak ada yang lebih besar dari jumlah 1400 byte yang ditentukan, sehingga fragmentasi tampaknya berfungsi dengan baik.
Untuk memverifikasi bahwa MTU 1400 byte saja sudah cukup, saya melakukan ping server VPN menggunakan perintah (Linux) berikut:
ping <host> -s 1450 -M do
Ini (saya percaya) mengirimkan paket 1450-byte dengan fragmentasi dinonaktifkan (setidaknya saya memverifikasi bahwa itu tidak berfungsi jika saya mengaturnya ke nilai yang jelas terlalu besar seperti 1600 byte). Ini tampaknya berfungsi dengan baik; Saya mendapatkan balasan kembali dari tuan rumah tanpa masalah.
Jadi, mungkin ini bukan masalah MTU sama sekali. Saya hanya bingung untuk apa lagi!
Sunting 2: Lubang kelinci terus semakin dalam: Sekarang saya telah mengisolasi masalahnya sedikit lagi. Tampaknya terkait dengan OS yang tepat yang digunakan klien VPN. Saya telah berhasil menggandakan masalah pada setidaknya tiga mesin Ubuntu (versi 12.04 hingga 13.04). Saya dapat menduplikasi koneksi SSH secara membeku dalam waktu sekitar satu menit atau lebih dengan hanyacat
menggunakan file log yang besar.
Namun , jika saya melakukan tes yang sama menggunakan mesin CentOS 6 sebagai klien, maka saya tidak melihat masalah! Saya telah diuji menggunakan versi klien OpenVPN yang sama persis seperti yang saya gunakan pada mesin Ubuntu. Saya dapat cat
mencatat file selama berjam-jam tanpa melihat koneksi membeku. Ini tampaknya memberikan beberapa wawasan tentang penyebab utama, tapi saya tidak yakin apa wawasan itu.
Saya telah memeriksa lalu lintas melalui VPN menggunakan Wireshark. Saya bukan pakar TCP, jadi saya tidak yakin apa yang harus dilakukan tentang detail berdarah, tetapi intinya adalah bahwa pada titik tertentu, paket UDP akan terhenti karena terbatasnya bandwidth tautan Internet, menyebabkan transmisi ulang TCP di dalam terowongan VPN. Pada klien CentOS, transmisi ulang ini terjadi dengan benar dan segala sesuatunya berjalan dengan bahagia. Namun, pada beberapa titik dengan klien Ubuntu, ujung jarak jauh mulai mentransmisikan kembali segmen TCP yang sama (dengan penundaan pengiriman meningkat di antara setiap pengiriman ulang). Klien mengirim apa yang tampak seperti ACK TCP yang valid untuk setiap pengiriman ulang, tetapi ujung jarak jauh masih terus mengirimkan segmen TCP yang sama secara berkala. Ini memperluas infinitum iklan dan koneksi terhenti. Pertanyaan saya di sini adalah:
- Apakah ada yang punya rekomendasi untuk bagaimana memecahkan masalah dan / atau menentukan akar penyebab masalah TCP? Seolah-olah ujung jarak jauh tidak menerima pesan ACK yang dikirim oleh klien VPN.
Satu perbedaan umum antara simpul CentOS dan berbagai rilis Ubuntu adalah bahwa Ubuntu memiliki versi kernel Linux yang jauh lebih baru (dari 3,2 di Ubuntu 12,04 menjadi 3,8 di 13,04). Pointer ke beberapa bug kernel baru mungkin? Saya berasumsi bahwa jika demikian, maka saya tidak akan menjadi satu-satunya yang mengalami masalah; Saya tidak berpikir ini sepertinya setup yang sangat eksotis.
tun
jaringan harus dimungkinkan dengan menjalankan multicast routing daemon (seperti pimd ) dan memiliki server OpenVPN menggunakan--topology
opsi yang diatur ke "subnet" - lihat manual