Windows L2TP صرف چند سائٹیں لوڈ کرتا ہے: pfSense پر DF بٹ صاف کریں

لیپ ٹاپ جڑتا ہے، انٹرانیٹ لوڈ ہوتا ہے، اور چند عوامی سائٹیں رک جاتی ہیں۔ تصدیق اور روٹنگ واضح طور پر کام کر رہی ہیں، جس سے وضاحت کے طور پر پیکٹ کا حجم رہ جاتا ہے۔ L2TP/IPsec سرنگ میں دستیاب MTU اس سے چھوٹا ہے جو اڈاپٹر اب بھی اعلان کرتا ہے، اور کلائنٹ «تقسیم نہ کریں» بٹ لگا کر پورے حجم کے پیکٹ بھیجتا رہتا ہے۔ pfSense گیٹ وے کو وہ بٹ صاف کرنے کا حکم دیا جا سکتا ہے، اور صحیح طور پر درست کرنے سے پہلے تشخیص کی تصدیق کا یہ تیز ترین طریقہ ہے۔

ان صفحات سے شروع کریں جو ناکام ہوتے ہیں

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

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

دونوں اعداد لکھ لیں۔ درستی اس پر منحصر ہے کہ کون سا غلط ہے، اور یہی جوڑی ہے جس کی تصدیق ریکارڈنگ بعد میں کرتی ہے۔

باہر جاتے وقت DF بٹ کیا کرتا ہے

اعداد کے فرق کی وجہ انکیپسولیشن ہے۔ IPsec ESP شامل کرتا ہے، L2TP ایک اور ہیڈر شامل کرتا ہے، اس لیے سرنگ جسمانی لنک سے کم پے لوڈ اٹھاتی ہے۔ Windows اب بھی اڈاپٹر پر 1500 بائٹ رپورٹ کرتا ہے اور بھیجی جانے والی چیز پر «تقسیم نہ کریں» لگاتا ہے۔ جب ایسا پیکٹ نہ سمائے، گیٹ وے کی درست جوابی کارروائی وہ ICMP پیغام ہے جو بھیجنے والے سے چھوٹا ہونے کی درخواست کرتا ہے۔ اسی لیے چھوٹے ping گزرنے والی سرنگ بھی فائل ڈاؤن لوڈ ناکام کر سکتی ہے۔

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

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

pfSense کا اختیار، اور جو یہ نہیں کرتا

اختیار سسٹم، ایڈوانسڈ، فائر وال اور NAT صفحے پر «پیکٹ گرانے کے بجائے غلط DF بٹس صاف کریں» کے لیبل کے ساتھ ہے۔ جھنڈا اٹھانے والے بہت بڑے پیکٹ کو پھینکنے کے بجائے فلٹر جھنڈا ہٹا دیتا ہے اور پیکٹ کو نیچے تقسیم ہونے دیتا ہے۔ پیکٹ تب غلط شمار ہوتا ہے جب وہ باہر جانے والا انٹرفیس ایک ٹکڑے میں عبور نہ کر سکے۔

اختیار کلائنٹ کو چھوئے بغیر کنیکٹیویٹی بحال کرتا ہے، اسی لیے مقبول ہے۔ یہ ایک عارضی حل بھی ہے: تقسیم CPU خرچ کرتی ہے اور ہر گمشدہ ٹکڑے کو مہنگا بناتی ہے۔

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

TCP کو غیر منقسم رکھنے والا زیادہ محدود درست عمل

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

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

کلائنٹ netsh interface ipv4 show subinterfaces کے ذریعے اپنا اڈاپٹر MTU رپورٹ کر سکتا ہے۔ اس عدد کا موازنہ اس سے کریں جسے سرور طے شدہ سمجھتا ہے، کیونکہ دونوں ہمیشہ یکساں نہیں ہوتے۔ یہی قدر ہے جو آپریٹنگ سسٹم واقعی استعمال کرے گا، بات چیت نے جو بھی رپورٹ کیا ہو۔

ریکارڈنگ سے تصدیق کریں، پھر حالت ری سیٹ کریں

فیصلے سے پہلے دونوں طرف ریکارڈ کریں: ایک نشان جہاں سرنگ جاتی ہے، اور دوسرا جہاں WAN انٹرفیس جاتا ہے۔ پورے حجم میں نکلنے والے اور ICMP واپس نہ آنے والے پیکٹ حد کو درست تہہ کے طور پر دکھاتے ہیں۔ آنے اور پھر واپسی میں مرنے والے جوابات اس کے بجائے سرنگ کے MTU کی طرف اشارہ کرتے ہیں۔

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