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 درخواست کی ناکامی نتیجہ ہے، سبب نہیں۔ دونوں پرتوں کی لاگ لائنیں ملانا ان دو حالتوں کو الگ کرنے کا تیز ترین طریقہ ہے، اور یہ فائل مینیجر سے اندازہ لگانے سے بہتر ہے۔

نتیجہ دو جملوں میں لکھیں، ہر پرت کے لیے ایک۔ اگلے شخص کے لیے یہ کافی ہے کہ وہ دوبارہ یہ طے کیے بغیر کہ کون سی ترسیل کون سی ہے، جانچ دہرا سکے۔