OpenConnect کے صفحات کیوں اٹک جاتے ہیں جب تک آپ ٹنل کا MTU کم نہ کریں

لاگ اِن کامیاب ہوتا ہے، پورٹل کا مرکزی صفحہ بنتا ہے، اور پھر کوئی ڈیش بورڈ ویجٹ یا رپورٹ waiting for host پر رہتی ہے جب تک براؤزر ہار نہ مانے۔ عوامی سائٹس پورے وقت معمول کے مطابق لوڈ ہوتی رہتی ہیں، اور کوئی اسناد تبدیل نہیں ہوئیں۔ بڑے جواب اٹکتے رہیں جبکہ چھوٹے آئیں، یہ رسائی قاعدے کی نہیں بلکہ پیکٹ سائز کی حد کی نشانی ہے۔ پروفائل میں کوئی اور چیز بدلنے سے پہلے اس پڑھائی کی تصدیق کریں۔

سائز کے مسئلے کو پالیسی کے مسئلے سے الگ کریں

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

طریقہ کار انکیپسولیشن ہے۔ ہر اندرونی پیکٹ کو ٹنل ہیڈر ملتے ہیں، اس لیے جو پے لوڈ طبعی لنک میں فٹ ہوتا تھا وہ ایسا بیرونی پیکٹ بن جاتا ہے جو اب فٹ نہیں ہوتا، اور do-not-fragment بِٹ والی ہر چیز براؤزر کے سمجھ سکنے والے جواب کے بغیر پھینک دی جاتی ہے۔

do-not-fragment جانچوں سے حد ناپیں

اندازہ لگانے کے بجائے حد ناپیں۔ ایسی جانچیں بھیجیں جو تقسیم سے انکار کریں اور جواب آنے تک پے لوڈ قدم بہ قدم گھٹائیں، اس طرح کے حکم سے شروع کریں: ping -M do -s 1472 host۔ DF مقرر ہونے پر تقسیم کی ضرورت کی شکایت کرنے والا جواب مطلب قدر اب بھی بہت زیادہ ہے۔ 1462 پر، پھر 1452 پر دہرائیں، اور جواب دینے والے پہلے سائز پر رکیں۔ عدد کو اُس ہوسٹ کے ساتھ لکھ لیں جسے آپ نے جانچا، کیونکہ جواب اُسی راستے کا ہے، عام طور پر پروٹوکول کا نہیں۔

اُس پتے کی جانچ کریں جہاں ٹنل واقعی ٹریفک بھیجتی ہے۔ گیٹ وے کے عوامی نام کے خلاف بیرونی جانچ اور اندرونی سرور کے خلاف اندرونی جانچ مختلف ہاپ ناپتی ہیں، اور کسی ایک پر ICMP فلٹرنگ صحت مند راستے کو ٹوٹا ہوا دکھا سکتی ہے۔

قدر کو ٹنل ڈیوائس پر لاگو کریں

نتیجہ Wi-Fi ایڈاپٹر پر نہیں بلکہ اُس انٹرفیس پر لاگو کریں جو کلائنٹ نے بنایا۔ Linux کلائنٹ پر یہ ip link set dev tun0 mtu 1300 اور پھر قدر کے قبول ہونے کی تصدیق کے لیے ip link show tun0 ہے۔ کلائنٹ جو بھی ڈیوائس نام بتائے وہی استعمال کریں، کیونکہ یہ عمل درآمد اور ٹنل کی تعمیر کے طریقے کے مطابق بدلتا ہے۔

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

پہلے کلائنٹ کی اپنی MTU درخواستیں استعمال کریں

جب آغاز آپ کنٹرول کرتے ہیں، کلائنٹ بعد میں پیچ ہونے کے بجائے سائز مانگ سکتا ہے۔ --mtu سرور سے ٹنل MTU مانگتا ہے، اور --base-mtu نیچے کے راستے کا MTU اعلان کرتا ہے تاکہ گیٹ وے ٹنل کا عدد نکال سکے۔ دونوں درخواستیں ہیں، اور کلائنٹ کا مینوئل یہ وعدہ نہیں کرتا کہ گیٹ وے ان میں سے کسی ایک کو مانے گا۔

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

جس منتقلی نے ناکامی دی اُس سے تصدیق کریں، پھر اُسے مستقل بنائیں

مقامی ip link تبدیلی اُس وقت تک قائم رہتی ہے جب تک کلائنٹ ٹنل دوبارہ نہ بنائے، جو اگلے دوبارہ کنیکٹ یا دوبارہ آغاز پر ہوتا ہے۔ قدر کو وہاں رکھیں جہاں کنکشن شروع ہوتا ہے: ایک ریپر جو کلائنٹ چلا کر پھر ڈیوائس کو ایڈجسٹ کرے، ExecStartPost مرحلے والی systemd یونٹ، یا گیٹ وے کے قبول کرنے پر کلائنٹ آپشن۔ اُسے پروفائل کے ساتھ ورژن کنٹرول میں رکھیں تاکہ اگلا شخص دیکھ سکے کہ عدد وہاں کیوں ہے۔

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

اگر وہی منتقلی اُسی مقام پر اٹکے، تو MTU نظریہ غیر ثابت شدہ ہے۔ ٹنل پر ٹریفک پکڑیں اور عدد دوبارہ بدلنے سے پہلے دیکھیں کہ کون سا پہلو بھیجنا بند کرتا ہے، اور پچھلی قدر لکھی رکھیں تاکہ رول بیک ایک ہی حکم رہے۔