NFS melalui TCP di dalam terowong UDP OpenVPN: dua pengangkutan

Membawa perbualan NFS yang menggunakan TCP di dalam terowong yang membawa UDP adalah sepenuhnya konsisten, dan ia mengelirukan orang kerana ia menamakan dua pengangkutan sekali gus. TCP ialah perbualan perkhidmatan fail antara klien dan pelayan NFS. UDP ialah pembawa tersulit antara hujung VPN. Kedua-duanya tidak membayangkan apa-apa tentang satu sama lain.

Catat kedua-duanya secara berasingan sebelum anda menyahpepijat apa-apa; kebanyakan insiden ini bermula apabila seseorang menukar lapisan yang salah.

Dua lapisan, dua tetapan

Pilihan lekap proto=tcp menerangkan bagaimana klien NFS bercakap dengan pelayan NFS. Tetapan proto udp dalam profil VPN menerangkan bagaimana hujung terowong bertukar-tukar paket yang dikapsulkan. Menukar pilihan lekap tidak menukar terowong, dan menukar pengangkutan terowong tidak menukar apa yang telah dirundingkan oleh klien NFS. Sahkan pilihan lekap berkesan dengan nfsstat -m dan bukan dengan baris fstab, dan sahkan pengangkutan VPN daripada profil yang benar-benar digunakan.

Kemudian catat kedua-duanya dalam nota insiden sebagai dua medan berasingan. Penambahbaikan yang ketara hanya boleh dijejaki jika nota menyatakan lapisan mana yang berubah.

Melayari bukan bacaan pukal

Senarai direktori membuktikan bahawa sesetengah operasi telah selesai. Ia tidak membuktikan bahawa bacaan berterusan, penulisan, kunci atau bahagian belakang storan akan selesai dalam keadaan yang sama. Genangan di tengah-tengah fail besar ialah pemerhatian berbeza daripada lekap yang tidak pernah berjaya, dan kedua-duanya menunjuk kepada lapisan yang berbeza.

Huraikan operasi yang gagal dengan tepat: laluan, arah, titik anggaran genangan, dan peristiwa berkaitan terakhir dalam log klien, pelayan dan VPN. Kemudian bandingkan di mana trafik berterusan dan di mana ia berhenti.

MTU ialah hipotesis, bukan diagnosis

Kehilangan yang bergantung pada saiz paket ialah kemungkinan sebenar apabila terowong membawa segmen besar, dan ia menghasilkan tepat corak melayari berfungsi tetapi bacaan tersekat. Walau bagaimanapun corak itu tidak membuktikan masalah MTU, kerana bentuk yang sama muncul apabila pelayan lambat, apabila tembok api menamatkan sambungan panjang kerana tamat masa, atau apabila cakera sibuk. Uji hipotesis itu dengan pemeriksaan terkawal dan bukan dengan menurunkan MTU di merata tempat lalu mengisytiharkan kemenangan.

Tamat masa sahaja tidak mengatakan apa-apa tentang sama ada UDP perlu ditukar. Ia adalah simptom dengan beberapa pemilik yang mungkin.

Tukar satu pemboleh ubah pada satu masa

Apabila membandingkan pengangkutan, kekalkan beban kerja NFS dan setiap tetapan lain secara stabil. Menukar pengangkutan lekap, protokol terowong dan MTU dalam tetingkap penyelenggaraan yang sama menghasilkan keputusan yang tiada siapa dapat mengaitkan. Jalankan operasi fail yang sama sebelum dan selepas, dan catat hasilnya pada setiap langkah.

Simpan juga nilai sebelumnya dalam tiket. Jika sesuatu perubahan memburukkan keadaan, pemulihan sepatutnya ialah nombor yang didokumenkan dan bukan ingatan seseorang tentang bagaimana keadaannya dahulu.

Baca lapisan yang gagal

Jika terowong hidup dan permintaan NFS menunggu, VPN tidak gagal; perkhidmatan fail yang gagal. Jika terowong terputus, kegagalan permintaan NFS ialah akibat dan bukan punca. Memadankan baris log daripada kedua-dua lapisan ialah cara terpantas untuk membezakan kedua-dua kes itu, dan ia lebih baik daripada meneka dari pengurus fail.

Tulis kesimpulan sebagai dua ayat, satu bagi setiap lapisan. Itu sudah cukup untuk orang seterusnya menghasilkan semula ujian itu tanpa menerbitkan semula pengangkutan mana yang mana.