PPPoE پر OpenVPN: link-mtu، tun-mtu یا mssfix کم کریں؟

پنگ جواب دیتا ہے، DNS حل کرتا ہے، اور ہر وہ صفحہ جو مکمل سائز کے حصے کا متقاضی ہو رک جاتا ہے۔ ایسے لنک پر جو اپنی encapsulation شامل کرتا ہے، راستہ خاموشی سے چند درجن بائٹ بجٹ کھو دیتا ہے، اور صاف Ethernet کے لیے لکھا پروفائل ایسے پیکٹ مانگتا رہتا ہے جو لائن اٹھا نہیں سکتی۔ کنکشن سست نہیں ہے؛ یہ ٹھیک وہی پیکٹ پھینک رہا ہے جو اہم ہیں۔

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

تین نوب، تین مختلف تہیں

link-mtu بیرونی بجٹ ہے: خفیہ شدہ پے لوڈ کے ساتھ OpenVPN ہیڈر، UDP ہیڈر اور بیرونی IP ہیڈر۔ یہ بیان کرتا ہے کہ مشین سے کیا نکلتا ہے، اسی لیے یہ وہ عدد ہے جسے طبعی راستہ محدود کرتا ہے۔

tun-mtu اندرونی بجٹ ہے: وہ انٹرفیس جو آپ کی ٹریفک دیکھتی ہے۔ یہ راستے کی برداشت سے ٹھیک سرنگ کے overhead کے برابر بڑا ہے، اور OpenVPN عام طور پر اسے خود اخذ کرتا ہے بجائے اس کے کہ آپ کو مقرر کرنے پر مجبور کرے۔

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

اگر آپ link-mtu واضح طور پر مقرر کریں تو OpenVPN اندرونی MTU اخذ کرنے کے لیے اپنا overhead گھٹاتا ہے۔ وہ overhead کوئی مقررہ مستقل نہیں ہے؛ یہ سائفر اور تصدیق پر منحصر ہے، اسی لیے فورم سے کاپی کی گئی قدر کسی دوسرے پروفائل پر غلط ہو سکتی ہے۔ link-mtu اور tun-mtu دونوں مقرر کرنے سے کلائنٹ کو دو متضاد ہدایات ملتی ہیں۔

کوئی بھی عدد چننے سے پہلے راستہ ناپیں

سرنگ کے اندر سے نہیں، طبعی انٹرفیس سے ناپیں، اور یاد رکھیں کہ پنگ پے لوڈ بتاتا ہے، پیکٹ کا حجم نہیں۔ پے لوڈ کا 1500 بائٹ فریم سے موازنہ کرنے سے پہلے IPv4 اور ICMP ہیڈر کے لیے 28 بائٹ شامل کریں، اور جب ساتھی کوئی دوسرا عدد بتائے تو وہ تصحیح ذہن میں رکھیں۔

Linux کلائنٹ پر ping -M do -s 1472 فریگمنٹیشن کو منع کرتا ہے اور پیکٹ بہت بڑا ہونے پر ناکام ہو جاتا ہے۔ پے لوڈ گھٹاتے جائیں جب تک یہ گزر نہ جائے، پھر راستے کی MTU پانے کے لیے 28 شامل کریں۔ PPPoE 8 بائٹ لیتا ہے، اس لیے DSL پر 1492 معمول ہے۔ DS-Lite اور کچھ موبائل راستے 40 یا زیادہ لیتے ہیں، اور جواب عام طور پر برائے نام لنک رفتار کے اشارے سے کم ہوتا ہے۔

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

پہلے TCP کو محدود کریں، پھر سرنگ کو سکیڑیں

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

جب متاثرہ ٹریفک TCP نہ ہو تو اندرونی MTU گھٹائیں۔ UDP سروس، سرنگ کے اندر سرنگ، یا مکمل سائز کے ڈیٹاگرام بھیجنے والی ایپلیکیشن MSS حد کے بعد بھی ناکام ہوتی رہے گی کیونکہ کوئی اس کے پیکٹ کا حجم دوبارہ نہیں لکھتا۔ اس صورت میں tun-mtu گھٹائیں، یا link-mtu مقرر کریں اور کلائنٹ کو اندرونی قدر اخذ کرنے دیں، مگر دونوں کبھی نہیں۔

فریگمنٹیشن کے پرانے آپشن کی طرف نہ جائیں۔ یہ سرنگ کے اندر پیکٹ تقسیم کرتا تھا، overhead بڑھاتا تھا، اور اچھی وجوہات کی بنا پر متروک ہو چکا ہے؛ جدید OpenVPN راستے کی درست وضاحت کی توقع کرتا ہے۔

چھوٹی جانچیں کیوں کام کرتی رہتی ہیں

DNS استفسارات، ICMP گونجیں اور TCP ہینڈ شیک سب ناکام ہونے والے سائز سے بہت نیچے ہیں۔ اس لیے سرنگ ہر تیز جانچ میں صحت مند دکھائی دیتی ہے، جبکہ TLS ہینڈ شیک اور HTTP جوابات خاموشی سے ناکام ہوتے ہیں۔ یہی امتزاج، کام کرتا traceroute اور پہلے بڑے جواب پر رکا ہوا براؤزر، وہ نشانی ہے جو تلاش کرنی ہے۔ نئے پروفائل کی طرف جانے سے پہلے مکمل سائز کی جانچ کی طرف جائیں۔

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

جب IPv6 سرنگ پر چل رہا ہو تو اندرونی MTU کو کبھی 1280 سے نیچے نہ لے جائیں، کیونکہ یہ وہ کم از کم ہے جو ہر IPv6 لنک کو اٹھانا پڑتا ہے۔ چھوٹی MTU راستے کے بارے میں ایک حقیقت ہے، احساس سے ٹیون کرنے والی کارکردگی کی ترتیب نہیں۔