রাউটার SMB ক্লায়েন্ট বনাম প্যাকেট ফরওয়ার্ডার: কোনটি উপযুক্ত

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

ফরওয়ার্ড করা ও সমাপ্ত করা আলাদা কাজ

ফরওয়ার্ডের ভূমিকায় রাউটারের একটিই দায়িত্ব: পথের যে নীতি দরকার তা প্রয়োগ করে ক্লায়েন্ট ও সার্ভারের মধ্যে প্যাকেট পৌঁছে দেওয়া। সে শেয়ারে প্রমাণীকরণ করে না, ফাইল ডেটা ক্যাশ করে না এবং সার্ভার SMB2 না SMB3 বলে তা নিয়ে ভাবে না, কারণ সে স্রোতের এত গভীরে কখনও পড়ে না। শেয়ার নাগালের বাইরে গেলে ব্যবহারকারী একটি ত্রুটি দেখেন আর রাউটার রাউটিং চালিয়ে যায়।

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

তুলনাটি কেবল সক্ষমতার কথা নয়। যে প্ল্যাটফর্ম একটি শেয়ার মাউন্ট করতে পারে সে স্বয়ংক্রিয়ভাবে এমন প্ল্যাটফর্ম নয় যার তা করা উচিত, আর যে প্ল্যাটফর্ম মাউন্ট করতে পারে না সেটিই হয়তো ট্রাফিক রাউট করার সঠিক জায়গা।

কার্নেল CIFS মাউন্টের আসলে কী দরকার

Linux-ভিত্তিক অ্যাপ্লায়েন্সে কার্নেল CIFS ক্লায়েন্ট ও ইউজারস্পেস ক্লায়েন্ট আলাদা সক্ষমতা, আর ছোট ইমেজে প্রায়ই কোনোটিই থাকে না। চলমান ইমেজে কার্নেল সমর্থন থাকতে হবে, মাউন্ট হেল্পার থাকতে হবে, আর সার্ভারের সঙ্গে যে SMB ডায়ালেক্ট ঠিক হয় তা দুই পক্ষেরই গ্রহণযোগ্য হতে হবে। Linux CIFS ক্লায়েন্ট নির্দেশিকা কার্নেলের বিন্যাস ও তার মাউন্ট অপশন নিয়ে বিস্তারিত দেয়, আর ভেন্ডর বিল্ডে তা আছে ধরে নেওয়ার আগে এটিই সঠিক তথ্যসূত্র।

কোনো সক্ষমতার চারপাশে নকশা করার আগে তা আছে কি না দেখুন, আর কমান্ডের নাম আছে কি না নয়, সংস্করণ দেখুন। প্যাকেজ তালিকায় মডিউলের নাম আর কাজ করা ক্লায়েন্ট এক নয়।

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

লোড হওয়া একটি কার্নেল মডিউল আর সংস্করণ জানানো একটি ইউজারল্যান্ড টুল এখনও নিশ্চয়তা দেয় না যে একটি মাউন্ট VPN কী পুনর্নবীকরণের পর টিকে থাকবে, তাই প্রোবকে প্রমাণ নয়, শুরুর শর্ত হিসেবে ধরুন। ইমেজ যদি কেবল SMB1 সমর্থন দেয়, তবে তা সার্ভারে চালু করার কারণ নয়, থামার কারণ।

ক্রেডেনশিয়াল ও উৎস পরিচয় ল্যাপটপের থেকে আলাদা

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

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

প্ল্যাটফর্মের সুরক্ষিত ব্যবস্থার মাধ্যমে ক্রেডেনশিয়াল সংরক্ষণ করুন এবং সীমিত অনুমতির ফাইল থেকে তা পড়ুন। মাউন্ট চালানো অ্যাকাউন্ট ছাড়া অন্য কোনো অ্যাকাউন্টের কাছে সেই ফাইল অপাঠ্য হওয়া উচিত।

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

শেয়ার হারিয়ে গেলে ব্যর্থতার মালিক কে

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

বুটের ক্রম ও মাউন্ট অপশন সেই বাস্তবতার চারপাশে নকশা করুন। সংক্ষিপ্ত সময়সীমা ও নথিভুক্ত পুনরুদ্ধার ধাপসহ শুধু-পাঠযোগ্য মাউন্ট, সব কিছু নির্ভর করে এমন লেখযোগ্য মাউন্টের চেয়ে রক্ষা করা সহজ। কিছু মাউন্ট করার চেষ্টার আগেই টানেল উঠছে কি না নিশ্চিত করুন, নইলে বিদ্যুৎ যাওয়ার পর প্রথম বুট আটকে থাকবে।

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

সিদ্ধান্তটি প্রকৃত কাজের সঙ্গে যাচাই করুন

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

মাউন্ট করা দৃশ্য ও খালি জায়গা রাউটারের নিজের থেকে যাচাই করুন, কারণ কর্মভার সেখানেই সেগুলো দেখবে। পুনঃসংযোগের পরে আবার যাচাই করুন, কেবল পরিষ্কার বুটের পরে নয়।

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

যে মাউন্ট ফাইল তালিকা করে কিন্তু ভরা বা শুধু-পাঠযোগ্য ফাইলসিস্টেম জানায়, সে ইতিমধ্যেই বলে দিয়েছে রাত 2টায় আপনার কোন ব্যর্থতা অপেক্ষা করছে। পুনরুদ্ধারের পথও নিশ্চিত করুন: পরিষ্কারভাবে আনমাউন্ট করুন, টানেল নামান, আবার তুলুন এবং অ্যাপ্লায়েন্স রিবুট না করেই আবার মাউন্ট করুন। এই ধারাবাহিকতায় প্রতিবারই সাপোর্ট কেস দরকার হলে, ক্লায়েন্ট ভূমিকার জন্য রাউটার ভুল জায়গা।