OpenVPN UDP tunnel ichida TCP ustida NFS: ikki transport

TCP ishlatadigan NFS suhbatini UDP tashuvchi tunnel ichida olib o’tish mutlaqo izchil va bu odamlarni chalkashtiradi, chunki bir vaqtning o’zida ikki transportni nomlaydi. TCP — bu mijoz va NFS server o’rtasidagi fayl xizmati suhbati. UDP — VPN chekka nuqtalari o’rtasidagi shifrlangan tashuvchi. Ikkalasi ham ikkinchisi haqida hech narsa bildirmaydi.

Biror narsani tuzatishdan oldin ikkalasini alohida yozib qo’ying; bu hodisalarning aksariyati kimdir noto’g’ri qatlamni o’zgartirishidan boshlanadi.

Ikki qatlam, ikki sozlama

Mount parametri proto=tcp NFS mijozi NFS server bilan qanday gaplashishini tavsiflaydi. VPN profilidagi proto udp sozlamasi tunnel chekka nuqtalari inkapsulyatsiyalangan paketlarni qanday almashishini tavsiflaydi. Mount parametrini o’zgartirish tunnelni o’zgartirmaydi, tunnel transportini o’zgartirish esa NFS mijoz kelishgan narsani o’zgartirmaydi. Amaldagi mount parametrlarini fstab satri emas, nfsstat -m orqali tekshiring va VPN transportini haqiqatda ishlatilayotgan profildan tasdiqlang.

So’ng ularni hodisa qaydlarida ikki alohida maydon sifatida yozing. Ko’rinadigan yaxshilanishni faqat qayd qaysi qatlam o’zgarganini aytsa kuzatish mumkin.

Ko’rib chiqish ommaviy o’qish emas

Katalog ro’yxati ba’zi amallar tugaganini isbotlaydi. U uzoq davom etadigan o’qish, yozish, bloklash yoki saqlash orqa qismi xuddi shu sharoitda tugashini isbotlamaydi. Katta faylning o’rtasida to’xtash hech qachon muvaffaqiyatli bo’lmaydigan mountdan boshqa kuzatuv, va ular turli qatlamlarga ishora qiladi.

Muvaffaqiyatsiz amalni aniq ta’riflang: yo’l, yo’nalish, to’xtashning taxminiy nuqtasi va mijoz, server hamda VPN jurnallaridagi oxirgi tegishli hodisa. So’ng trafik qayerda davom etishi va qayerda to’xtashini taqqoslang.

MTU — bu faraz, tashxis emas

Paket o’lchamiga bog’liq yo’qotish tunnel katta segmentlarni tashiganda haqiqiy imkoniyat va u aynan ko’rib chiqish ishlaydi, o’qish esa to’xtaydi degan naqshni hosil qiladi. Biroq bu naqsh MTU muammosini isbotlamaydi, chunki server sekin bo’lganda, tarmoq devori uzoq ulanishni vaqt chegarasi bilan uzganda yoki disk band bo’lganda ham xuddi shu shakl paydo bo’ladi. Farazni hamma joyda MTU-ni pasaytirib g’alaba e’lon qilish o’rniga boshqariladigan sinov bilan tekshiring.

Vaqt chegarasi o’zi UDP almashtirilishi kerakmi yoki yo’qmi degani haqida hech narsa demaydi. Bu bir necha mumkin egasi bor alomat.

Bir vaqtda bitta o’zgaruvchini o’zgartiring

Transportlarni taqqoslaganda NFS ish yukini va boshqa barcha sozlamalarni barqaror saqlang. Bitta xizmat oynasida mount transportini, tunnel protokolini va MTU-ni o’zgartirish hech kim bog’lay olmaydigan natija beradi. Xuddi shu fayl amalini oldin va keyin bajaring va har bir qadamda natijani yozib boring.

Oldingi qiymatlarni ham chiptada saqlang. Agar o’zgarish vaziyatni yomonlashtirsa, qaytish hujjatlashtirilgan raqam bo’lishi kerak, birovning avval qanday bo’lgani haqidagi xotirasi emas.

Muvaffaqiyatsiz bo’lgan qatlamni o’qing

Agar tunnel ishlab turgan bo’lsa va NFS so’rovi kutayotgan bo’lsa, VPN muvaffaqiyatsiz bo’lmagan; fayl xizmati muvaffaqiyatsiz bo’lgan. Agar tunnel qulagan bo’lsa, NFS so’rovining muvaffaqiyatsizligi natija, sabab emas. Ikki qatlamning jurnal satrlarini moslashtirish bu ikki holatni ajratishning eng tez yo’li va fayl menejeridan taxmin qilishdan yaxshiroq.

Xulosani ikki gapda yozing, har bir qatlam uchun bittadan. Bu keyingi odamga qaysi transport qaysi ekanini qaytadan chiqarmasdan sinovni takrorlashi uchun yetarli.