VPN کے ذریعے NFS دوبارہ برآمد پیکٹ فارورڈنگ نہیں ہے

ایک Linux باکس VPN میں شامل ہوتا ہے، دور دراز کی NFS برآمد کو ماؤنٹ کرتا ہے اور پھر وہ ماؤنٹ کلائنٹس کے دوسرے گروہ کو پیش کرتا ہے۔ یہ ترتیب اضافی مراحلوں والی روٹنگ جیسی لگتی ہے، اور یہ پہلا غلط قیاس ہے۔ درمیانی مشین اوپر والے سرور کی کلائنٹ اور نیچے والے کلائنٹس کے لیے سرور ہے، اور دونوں فائل سروس تعلقات میں شریک ہوتی ہے۔ پیکٹ فارورڈنگ کا فائل ہینڈل، لاکنگ یا فائل سسٹم کی شناخت کے بارے میں کوئی موقف نہیں؛ دوبارہ برآمد کا ہے۔

اس سوال سے شروع کریں کہ کیا نیچے والے کلائنٹ اصل سرور تک براہ راست پہنچ سکتے تھے۔ اگر پہنچ سکتے ہیں تو درمیانی مشین اختیاری ہے۔

تین ماڈل، مستقل مزاجی کی تین کہانیاں

براہ راست ماؤنٹ سب سے سادہ ہے: ہر کلائنٹ سرنگ کے ذریعے اصل سرور ماؤنٹ کرتا ہے، اور اس سرور کی برآمد پالیسی رسائی کو کنٹرول کرتی ہے۔ دوبارہ برآمد یہ ہے کہ درمیانی مشین ایک الگ سروس حد پیش کرتی ہے، جو اس وقت مفید ہے جب کلائنٹس کی طرف کا نیٹ ورک براہ راست سرور تک نہ پہنچ سکے۔ نقل تیسرا ماڈل ہے، اور یہ سوال کو مستقل مزاجی سے ہم آہنگی اور تنازعے کے حل کی طرف منتقل کرتی ہے۔

نقل شدہ کاپی کو زندہ دوبارہ برآمد کی طرح بیان نہ کریں۔ ناکامی کے انداز مختلف ہیں، اور وہ صارف جو توقع کرتا ہے کہ ہر کارروائی اصل فائل سسٹم تک پہنچے گی، لنک ٹوٹنے پر حیران ہوگا۔

شناخت ماؤنٹ حکم سے زیادہ زندہ رہتی ہے

دوبارہ برآمد کے لیے واضح فائل سسٹم ID درکار ہے، اور اس شناخت کو دوبارہ آغاز اور ترتیب کی تعمیر نو برداشت کرنی چاہیے۔ کرنل کی دستاویزات اس ضرورت کے بارے میں واضح ہیں، اور یہ متنبہ بھی کرتی ہیں کہ crossmnt ذیلی فائل سسٹمز کو ان کے اپنے ID کے ساتھ برآمد کرنے کی ضرورت ختم نہیں کرتا۔ صارف کو مسلسل دکھنے والا ڈائریکٹری درخت کئی فائل سسٹم حدود عبور کر سکتا ہے۔ موجودہ nfs-utils معاون ترتیبات کے لیے ID خودکار طور پر مختص کر سکتا ہے، اور جب ایسا کرتا ہے تو اس کا ڈیٹا بیس گیٹ وے کی حالت کا حصہ بن جاتا ہے۔ ان ID کو یکبار استعمال کی فائلوں کے بجائے سروس شناخت سمجھیں۔

فائل ہینڈل دوسری شناخت کی حد ہیں: دوبارہ برآمد اصل ہینڈل کو لپیٹتی ہے، جو اسے بڑا کرتی ہے اور کلائنٹ کی حد سے تجاوز کر سکتی ہے۔ کامیاب ماؤنٹ یہ ثابت نہیں کرتا کہ ہر برآمد ترتیب مطابق ہے۔

ہر NFS خصوصیت درمیانی مشین سے نہیں گزرتی

کرنل کی دوبارہ برآمد کی رہنما کتاب کہتی ہے کہ دوبارہ برآمد کرنے والا سرور لاکنگ یا تفویض کی درخواستوں کی حمایت نہیں کرتا۔ ان کارروائیوں پر منحصر ایپلیکیشنوں کو دوسرا راستہ یا ان کے مقابلے میں تصدیق شدہ ڈیزائن درکار ہے۔ کامیاب ماؤنٹ اور کام کرنے والی ڈائریکٹری فہرست یہ ظاہر نہیں کرتیں کہ ایپلیکیشن کی اصل کارروائیاں کام کرتی ہیں۔

صارف کی شناخت اور برآمد پالیسی بھی ہر چھلانگ پر اہم ہیں۔ VPN میں لاگ ان ثابت کرتا ہے کہ نیٹ ورک کا ایک شریک تصدیق ہو چکا ہے؛ یہ NFS صارف کو مجاز نہیں کرتا، اور گیٹ وے کے پار کلائنٹ کی اسناد منتقل نہیں کرتا۔

گیٹ وے کی دو اوپری انحصار ہیں

گیٹ وے اوپر والی ماؤنٹ کے لیے VPN پر اور فائل سسٹم کے لیے اوپر والے سرور پر منحصر ہے۔ اب بھی چلنے والا مقامی برآمد عمل دستیاب نہ ہونے والے اسٹوریج کو صحت مند نہیں بنا سکتا۔ آغاز کی ترتیب، دوبارہ جڑنے کا رویہ اور سرور کی دوبارہ شروعات کا منصوبہ بنائیں، بشمول اس کے کہ کلائنٹس کے پاس پہلے سے موجود فائل ہینڈل کا کیا ہوگا۔ جس کلائنٹ نے گیٹ وے کے ذریعے ماؤنٹ کیا اور اپنا ہینڈل کھو دیا اسے دوبارہ ماؤنٹ کرنے کی ضرورت ہے، اور یہ شفاف بحالی نہیں بلکہ آپریشنل واقعہ ہے۔

اگر ضرورت کو کبھی صرف نجی IP تک رسائی درکار تھی، تو اصل سرور پر براہ راست روٹنگ زیادہ سادہ معماری ہے۔ دوبارہ برآمد کسی ایسی وجہ سے ہونی چاہیے جو لکھے جانے پر بھی قائم رہے۔

ماؤنٹ نہیں، کام کا بوجھ جانچیں

کنٹرول شدہ ماحول میں حقیقی فائل کام کے بوجھ کی مشق کریں: وہ کارروائیاں جو ایپلیکیشن کرتی ہے، وہ فائل سائز جو استعمال کرتی ہے اور وہ ہم وقتی جس کی توقع کرتی ہے۔ صرف نقل و حمل کی خرابیوں کے بجائے خصوصیات کے خلا پر نظر رکھیں۔ پھر لکھیں کہ آپ نے کون سا ماڈل چنا اور کیوں، ورنہ اگلا شخص گیٹ وے کو راؤٹر سمجھے گا۔

دوبارہ برآمد اس وقت جائز ہے جب یہ جان بوجھ کر کسی وجہ سے ہو، جیسے الگ کلائنٹ نیٹ ورک یا کنٹرول شدہ ورژن کی حد۔ یہ ایک برا حادثہ ہے، اور فرق یہ ہے کہ کسی نے اس کا فیصلہ کیا یا نہیں۔