OpenVPN UDP টানেলের ভিতরে TCP-তে NFS: দুই পরিবহন

UDP বহন করে এমন টানেলের ভিতরে TCP ব্যবহার করা NFS কথোপকথন বহন করা সম্পূর্ণ সামঞ্জস্যপূর্ণ, এবং এটি মানুষকে বিভ্রান্ত করে কারণ এটি একসাথে দুই পরিবহনের নাম নেয়। TCP হলো ক্লায়েন্ট ও NFS সার্ভারের মধ্যে ফাইল সেবার কথোপকথন। UDP হলো VPN এন্ডপয়েন্টগুলোর মধ্যে এনক্রিপ্টেড ক্যারিয়ার। কোনোটিই অন্যটি সম্পর্কে কিছু বোঝায় না।

ডিবাগ শুরু করার আগে দুটোই আলাদাভাবে লিখে রাখুন; এসব ঘটনার বেশিরভাগ শুরু হয় কেউ ভুল স্তর বদলালে।

দুই স্তর, দুই সেটিং

মাউন্ট অপশন proto=tcp বর্ণনা করে NFS ক্লায়েন্ট কীভাবে NFS সার্ভারের সাথে কথা বলে। VPN প্রোফাইলের proto udp সেটিং বর্ণনা করে টানেল এন্ডপয়েন্টগুলো কীভাবে এনক্যাপসুলেটেড প্যাকেট বিনিময় করে। মাউন্ট অপশন বদলালে টানেল বদলায় না, আর টানেলের পরিবহন বদলালে NFS ক্লায়েন্ট যা নেগোশিয়েট করেছে তা বদলায় না। fstab লাইনের বদলে nfsstat -m দিয়ে কার্যকর মাউন্ট অপশন নিশ্চিত করুন, এবং যে প্রোফাইলটি সত্যিই ব্যবহৃত হচ্ছে সেখান থেকেই VPN পরিবহন নিশ্চিত করুন।

তারপর ঘটনার নোটে সেগুলো দুটি আলাদা ফিল্ড হিসেবে লিখুন। আপাত উন্নতি তখনই অনুসরণযোগ্য যখন নোটে বলা থাকে কোন স্তর বদলেছে।

ব্রাউজিং মানে বাল্ক রিড নয়

একটি ডিরেক্টরি তালিকা প্রমাণ করে কিছু অপারেশন সম্পন্ন হয়েছে। এটি প্রমাণ করে না যে একটি দীর্ঘায়িত রিড, একটি রাইট, একটি লক বা স্টোরেজ ব্যাকএন্ড একই অবস্থায় সম্পন্ন হবে। বড় ফাইলের মাঝপথে থেমে যাওয়া আর কখনোই সফল না হওয়া মাউন্ট ভিন্ন পর্যবেক্ষণ, এবং তারা ভিন্ন স্তরের দিকে ইঙ্গিত করে।

ব্যর্থ অপারেশনটি সুনির্দিষ্টভাবে বর্ণনা করুন: পাথ, দিক, থেমে যাওয়ার আনুমানিক স্থান, এবং ক্লায়েন্ট, সার্ভার ও VPN লগে শেষ প্রাসঙ্গিক ঘটনা। তারপর তুলনা করুন কোথায় ট্রাফিক চলছে আর কোথায় থামছে।

MTU একটি অনুমান, রোগনির্ণয় নয়

প্যাকেট আকারের ওপর নির্ভর করে প্যাকেট হারানো সত্যিই সম্ভব যখন টানেল বড় সেগমেন্ট বহন করে, এবং এটি ঠিক «ব্রাউজিং কাজ করে, রিড আটকে যায়» ধরনের প্যাটার্ন তৈরি করে। তবে সেই প্যাটার্ন MTU সমস্যা প্রমাণ করে না, কারণ একই চেহারা দেখা যায় যখন সার্ভার ধীর, ফায়ারওয়াল দীর্ঘস্থায়ী সংযোগের সময়সীমা শেষ করে, বা ডিস্ক ব্যস্ত থাকে। সর্বত্র MTU কমিয়ে জয় ঘোষণা করার বদলে একটি নিয়ন্ত্রিত প্রোব দিয়ে অনুমানটি পরীক্ষা করুন।

শুধু একটি টাইমআউট UDP বদলানো উচিত কি না সে সম্পর্কে কিছুই বলে না। এটি এমন একটি উপসর্গ যার একাধিক সম্ভাব্য মালিক আছে।

একবারে একটি চলক বদলান

পরিবহন তুলনা করার সময় NFS ওয়ার্কলোড ও বাকি সব সেটিং স্থির রাখুন। একই রক্ষণাবেক্ষণ উইন্ডোতে মাউন্ট পরিবহন, টানেল প্রোটোকল ও MTU বদলালে এমন ফল আসে যা কেউ নির্দিষ্ট করা করতে পারে না। একই ফাইল অপারেশন আগে ও পরে চালান, এবং প্রতিটি ধাপে ফল লিখে রাখুন।

আগের মানগুলোও টিকিটে রেখে দিন। কোনো পরিবর্তন পরিস্থিতি খারাপ করলে ফলব্যাক হতে হবে একটি নথিভুক্ত সংখ্যা, কারও আগে কেমন ছিল সেই স্মৃতি নয়।

যে স্তরটি ব্যর্থ হয়েছে সেটি পড়ুন

যদি টানেল চালু থাকে আর NFS অনুরোধ অপেক্ষা করে, তাহলে VPN ব্যর্থ হয়নি; ফাইল সেবা ব্যর্থ হয়েছে। যদি টানেল নেমে যায়, তাহলে NFS অনুরোধের ব্যর্থতা পরিণতি, কারণ নয়। দুই স্তরের লগ লাইন মিলিয়ে দেখা এই দুই অবস্থা আলাদা করার দ্রুততম উপায়, এবং তা ফাইল ম্যানেজার থেকে অনুমান করার চেয়ে ভালো।

সিদ্ধান্তটি দুই বাক্যে লিখুন, প্রতি স্তরে একটি। পরের ব্যক্তির জন্য কোন পরিবহন কোনটি তা আবার বের না করেই পরীক্ষাটি পুনরাবৃত্তি করার জন্য এটাই যথেষ্ট।