OpenVPN mssfix: بڑی منتقلیوں میں ایک کلائنٹ کیوں رک جاتا ہے

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

یہ آپشن کیا دوبارہ لکھتا ہے

mssfix ٹنل سے گزرنے والے TCP ہینڈ شیکس میں اعلان کردہ زیادہ سے زیادہ سیگمنٹ سائز میں ترمیم کرتا ہے، تاکہ بھیجنے والا فریق انکیپسولیٹڈ بجٹ میں فٹ ہونے والے سیگمنٹ منتخب کرے۔ یہ ہینڈ شیک پر کام کرتا ہے، یعنی تبدیلی سے پہلے کھلا کنکشن طے شدہ قدر برقرار رکھتا ہے۔

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

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

دائرہ کار ٹنل کے اندر TCP ہے

صرف TCP ٹریفک دوبارہ لکھی جاتی ہے۔ QUIC سیشن، گیم یا بڑے UDP ڈیٹاگرام بھیجنے والی ایپلیکیشن اپنے پیکٹ سائز برقرار رکھے گی، اور اگر وہی منتقلیاں رک رہی ہوں، تو حل بلکہ ٹنل یا راستے کے MTU میں ہے۔ TCP آپشن کی طرف بڑھنے سے پہلے پڑھیں کہ ناکام منتقلی کون سا پروٹوکول استعمال کرتی ہے، کیونکہ غلط پرت کا اپنا حل ہوتا ہے۔

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

عدد اور کلیدی لفظ منتقل نہیں ہو سکتے

OpenVPN 2.6 کا کمیونٹی ورژن قدر کے بعد اختیاری کلیدی لفظ قبول کرتا ہے۔ mtu کے ساتھ، عدد IP اور UDP ہیڈرز سمیت بیرونی پیکٹ کا سائز بیان کرتا ہے؛ اس کے بغیر، دلیل کسی اور حسابی روایت کی پیروی کرتی ہے۔ اس لیے ورژنوں کے درمیان نقل شدہ سطر وہی پیکٹ بجٹ بیان نہیں کرتی۔ کسی دوسرے ریلیز کے ٹیوٹوریل کی بجائے وہ مینول صفحہ دیکھیں جو آپ کے واقعی چلائے جانے والے بلڈ کے ساتھ آتا ہے۔

نحو اس طرح دکھتی ہے:

mssfix 1400 mtu

1400 کو اپنے راستے کے لیے سفارش نہیں بلکہ پلیس ہولڈر سمجھیں۔ قدر ناپے گئے راستے اور واقعی استعمال ہونے والی انکیپسولیشن سے اخذ کریں، اور یاد رکھیں کہ پرانے ورژنوں یا دیگر نفاذوں کے کلائنٹ کلیدی لفظ کو مسترد یا مختلف طور پر تفسیر کر سکتے ہیں۔

پہلے اسی ایک کلائنٹ پر تصدیق کریں

کچھ بھی بدلنے سے پہلے ناکام مشین سے راستہ ناپیں۔ جو پے لوڈ راستہ بغیر تقسیم کے لے جا سکتا ہے وہی آپ کا مطلوبہ عدد ہے:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

پہلا پروب 28 بائٹ ہیڈرز شامل کرنے پر 1500 بائٹ کے پیکٹ میں فٹ ہوتا ہے۔ اگر یہ تقسیم کی خرابی سے ناکام ہو اور چھوٹا کامیاب ہو، تو قابل استعمال سائز ان کے درمیان کہیں ہے، اور ٹنل کا اوور ہیڈ اوپر سے کم کیا جاتا ہے۔

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