روٹر بطور 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 بجے آپ کو کون سی ناکامی ملے گی۔ بازیابی کا راستہ بھی تصدیق کریں: صاف طور پر ان ماؤنٹ کریں، سرنگ نیچے اتاریں، دوبارہ اوپر لائیں اور آلہ دوبارہ شروع کیے بغیر دوبارہ ماؤنٹ کریں۔ اگر اس ترتیب کو ہر بار معاونت کیس درکار ہو، تو کلائنٹ کردار کے لیے روٹر غلط جگہ ہے۔