NFS di atas TCP di dalam tunnel UDP OpenVPN: dua transport

Membawa percakapan NFS yang memakai TCP di dalam tunnel yang membawa UDP sepenuhnya konsisten, dan itu membingungkan orang karena menyebut dua transport sekaligus. TCP adalah percakapan layanan berkas antara klien dan server NFS. UDP adalah pembawa terenkripsi antara titik akhir VPN. Tidak satu pun menyiratkan apa pun tentang yang lain.

Catat keduanya secara terpisah sebelum Anda men-debug apa pun; sebagian besar insiden ini dimulai saat seseorang mengubah lapisan yang salah.

Dua lapisan, dua pengaturan

Opsi mount proto=tcp menjelaskan bagaimana klien NFS berbicara dengan server NFS. Pengaturan proto udp di profil VPN menjelaskan bagaimana titik akhir tunnel bertukar paket yang dienkapsulasi. Mengubah opsi mount tidak mengubah tunnel, dan mengubah transport tunnel tidak mengubah apa yang telah dinegosiasikan klien NFS. Pastikan opsi mount yang berlaku dengan nfsstat -m, bukan dengan baris fstab, dan pastikan transport VPN dari profil yang benar-benar dipakai.

Setelah itu catat keduanya di catatan insiden sebagai dua bidang terpisah. Perbaikan yang tampak hanya bisa dilacak jika catatan menyebutkan lapisan mana yang berubah.

Menelusuri bukan pembacaan massal

Daftar direktori membuktikan bahwa sebagian operasi selesai. Itu tidak membuktikan bahwa pembacaan berkelanjutan, penulisan, penguncian, atau backend penyimpanan akan selesai dalam kondisi yang sama. Macet di tengah berkas besar adalah pengamatan yang berbeda dari mount yang tidak pernah berhasil, dan keduanya menunjuk lapisan yang berbeda.

Jelaskan operasi yang gagal secara tepat: jalur, arah, perkiraan titik macet, dan peristiwa relevan terakhir di log klien, server, serta VPN. Lalu bandingkan di mana lalu lintas berlanjut dan di mana ia berhenti.

MTU adalah hipotesis, bukan diagnosis

Kehilangan yang bergantung pada ukuran paket adalah kemungkinan nyata saat tunnel membawa segmen besar, dan itu menghasilkan persis pola penelusuran berjalan tetapi pembacaan macet. Namun pola itu tidak membuktikan masalah MTU, karena bentuk yang sama muncul saat server lambat, saat firewall mengakhiri koneksi berumur panjang karena batas waktu, atau saat disk sibuk. Uji hipotesis itu dengan pemeriksaan terkendali alih-alih menurunkan MTU di semua tempat lalu mengumumkan kemenangan.

Batas waktu sendirian tidak mengatakan apa pun tentang apakah UDP harus diganti. Itu gejala dengan beberapa pemilik yang mungkin.

Ubah satu variabel setiap kali

Saat membandingkan transport, jaga beban kerja NFS dan semua pengaturan lain tetap stabil. Mengubah transport mount, protokol tunnel, dan MTU dalam jendela pemeliharaan yang sama menghasilkan hasil yang tidak bisa dikaitkan siapa pun. Jalankan operasi berkas yang sama sebelum dan sesudah, lalu catat hasilnya di setiap langkah.

Simpan nilai sebelumnya di tiket juga. Jika suatu perubahan memperburuk keadaan, jalan mundurnya harus berupa angka yang terdokumentasi, bukan ingatan seseorang tentang bagaimana sebelumnya.

Baca lapisan yang gagal

Jika tunnel hidup dan permintaan NFS menunggu, VPN tidak gagal; layanan berkaslah yang gagal. Jika tunnel putus, kegagalan permintaan NFS adalah akibat, bukan sebab. Mencocokkan baris log dari kedua lapisan adalah cara tercepat membedakan kedua kasus itu, dan itu lebih baik daripada menebak dari pengelola berkas.

Tulis kesimpulan sebagai dua kalimat, satu per lapisan. Itu cukup bagi orang berikutnya untuk mengulang pengujian tanpa menurunkan ulang transport mana yang mana.