VPN گیٹ وے پر MSS کلیمپنگ: یہ کیا ٹھیک کرتی ہے اور کیا نہیں
کلیمپنگ TCP ہینڈ شیک میں MSS دوبارہ لکھتی ہے تاکہ سیگمنٹس ٹنل میں سما جائیں۔ یہ کبھی UDP یا خراب path-MTU جانچ ٹھیک نہیں کرتی۔ تین جانچیں، ترتیب سے۔
چھوٹی درخواستیں کام کرتی ہیں، بڑی ڈاؤن لوڈز رک جاتی ہیں، اور کوئی MSS کلیمپنگ تجویز کرتا ہے۔ یہ تجویز صحیح ترتیب سے آزمانے کے قابل حد تک اکثر درست ہے، اور آنکھیں بند کر کے لاگو کرنے پر آدھا دن ضائع کرنے کے قابل حد تک اکثر غلط ہے۔ نیچے دی گئی تین جانچیں اصل TCP سائز کے مسئلے کو UDP مسئلے، خراب path-MTU دریافت، اور ایسی کلیمپ سے الگ کرتی ہیں جو اس ہینڈ شیک کو کبھی نہیں دیکھتی جسے دوبارہ لکھنا ہے۔
ناکامی کی شکل سے شروع کریں
سائز کی ناکامی کا ایک دستخط ہے: کنکشن قائم ہوتا ہے، تصدیق اور چھوٹے جوابات کامیاب ہوتے ہیں، پھر پورے سائز کے سیگمنٹ کی ضرورت پر منتقلی غیر معینہ مدت کے لیے رک جاتی ہے۔ وہ صفحات جو متن لوڈ کرتے ہیں مگر تصویر کبھی مکمل نہیں کرتے، چھوٹے پیمانے پر وہی ناکامی ہیں۔ اگر کچھ بھی کنیکٹ نہ ہو تو مسئلہ راستے میں پہلے ہے اور کلیمپنگ مدد نہیں کرے گی۔ کلیمپ اس ہینڈ شیک کو بھر نہیں سکتی جو کبھی آیا ہی نہیں۔
یہ دستخط اس لیے ہے کہ سیگمنٹ کا سائز ہینڈ شیک ہی میں طے ہوتا ہے۔ ہر فریق TCP آپشن کے طور پر زیادہ سے زیادہ سیگمنٹ سائز کا اعلان کرتا ہے، اور بھیجنے والے دوسرے فریق کے اعلان کا احترام کرتے ہیں۔ اگر راستہ اتنا بڑا سیگمنٹ نہ اٹھا سکے تو ناکامی بعد میں ظاہر ہوتی ہے، جب بھیجنے والا آخرکار ایک آزمانے کی کوشش کرتا ہے۔
یہ علامت پڑھتے وقت نقل و حمل کو نظر میں رکھیں۔ کلیمپنگ TCP آپشن کی دوبارہ تحریر ہے، اس لیے اسی ٹنل کے نیچے رکنے والی آواز یا ویڈیو کال MSS مسئلہ نہیں ہے اور اس سے بہتر نہیں ہوگی۔ کسی TCP آپشن کو چھونے سے پہلے نقل و حمل لکھ لیں۔
راستے کی قیمت لگائیں، پھر ٹنل سے موازنہ کریں
دو اعداد اہم ہیں اور اکثر آپس میں مل جاتے ہیں۔ path-MTU وہ سب سے بڑا پیکٹ ہے جو راستہ بغیر تقسیم کے اٹھاتا ہے، اور IPv4 کے لیے اعلان شدہ MSS وہ قدر ہے جس سے IP اور TCP ہیڈرز کے 40 بائٹ منفی ہوں، یا IPv6 کے لیے 60 منفی۔ ٹنل کی encapsulations اندرونی پیکٹ شروع ہونے سے پہلے ہی بجٹ کا کچھ حصہ کھا جاتی ہے۔
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20do-not-fragment بٹ والا ping بتاتا ہے کہ اس پے لوڈ سائز کا پیکٹ بچتا ہے یا نہیں؛ سائز بدلتے رہیں جب تک ناکام نہ ہو اور آپ نے تجرباتی طور پر راستے کی حد پا لی۔ tracepath کا آؤٹ پٹ راستے میں دریافت شدہ MTU بتاتا ہے، جو چلنے پر تیز اور درمیانی ہاپ کے پروب فلٹر کرنے پر کم قابلِ اعتماد ہوتا ہے۔
اب ٹنل کا اوور ہیڈ منفی کریں۔ بیرونی IP ہیڈر، UDP ہیڈر اور ٹنل کے لیے مخصوص ہیڈر سب انہی 1500 بائٹ سے آتے ہیں، اس لیے عام ایتھرنیٹ بنیاد پر قابلِ استعمال اندرونی MTU جسمانی لنک کے اشارے سے کم ہے۔ اگر حساب شدہ اندرونی MTU آپ کے ساتھیوں کے اعلان سے کم ہے تو آپ نے اندازہ نہیں بلکہ حقیقی کلیمپ امیدوار پایا ہے۔ اگر حساب شدہ قدر پہلے ہی ساتھیوں کے اعلان سے زیادہ ہو تو یہیں رک جائیں اور کہیں اور دیکھیں۔
کلیمپ وہاں رکھیں جہاں سے ہینڈ شیک گزرتا ہے
کلیمپ گیٹ وے عبور کرتے وقت SYN اور SYN-ACK پیکٹوں میں MSS آپشن دوبارہ لکھ کر کام کرتی ہے۔ اگر قاعدہ ایسے انٹرفیس پر ہو جس سے کوئی بھی سمت کبھی نہ گزرے تو گفت و شنید بغیر تبدیلی مکمل ہو جاتی ہے اور علامت رہ جاتی ہے، اس لیے قدر سے زیادہ جگہ نتیجہ طے کرتی ہے۔
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
سمت دوسرا نصف ہے۔ ایک سمت کی کلیمپنگ آدھے بہاؤ ٹھیک کرتی ہے اور باقی کو وقفے وقفے سے نظر آنے والے انداز میں ناکام چھوڑ دیتی ہے، اس لیے اسے آگے بھیجی جانے والی ٹریفک کی دونوں سمتوں پر لاگو کریں۔ ٹنل انٹرفیس کے لیے Linux کی کلاسیکی شکل SYN پیکٹوں سے مطابقت رکھنے والا mangle قاعدہ ہے:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuغور کریں --clamp-mss-to-pmtu دراصل کیا کرتا ہے: یہ قدر راستے کے MTU سے اخذ کرتا ہے، جو ہمیشہ ٹنل کا حقیقی پے لوڈ بجٹ نہیں ہوتا۔ راستے پر مبنی ٹنل میں جہاں اندرونی راستہ اور بیرونی راستہ مختلف ہوں، پچھلی جانچ میں حساب شدہ واضح قدر خودکار قدر سے زیادہ قابلِ پیش گوئی ہے۔
نئے کنکشن سے تصدیق کریں اور فیڈ بیک زندہ رکھیں
قائم شدہ کنکشن اپنا طے شدہ MSS برقرار رکھتا ہے، اس لیے اسی سیشن میں جانچ کچھ ثابت نہیں کرتی۔ تبدیلی کے بعد نیا کنکشن کھولیں اور طے شدہ قدر براہِ راست پڑھیں، بجائے اس کے کہ اتفاقاً مکمل ہونے والی منتقلی سے اندازہ لگائیں۔
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSپہلا حکم ساکٹ کا MSS اس کی بھیڑ کی حالت کے ساتھ بتاتا ہے، جو کلیمپ کے اثر کرنے کی تیز ترین تصدیق ہے۔ دوسرا تصدیق کرتا ہے کہ جو قاعدہ آپ نے شامل کیا سمجھا وہی موجود قاعدہ ہے، اسی جدول میں جہاں وہ رکھا گیا۔
پھر اس طریقہ کار کی حفاظت کریں جو آپ نے ٹھیک نہیں کیا۔ path-MTU کی دریافت اس پر منحصر ہے کہ ICMP fragmentation-needed پیغامات بھیجنے والے تک پہنچیں، اس لیے انہیں پھینکنے والا فائر وال درست کلیمپ کے باوجود بڑی منتقلیاں توڑتا رہے گا۔ ٹنل راستے کے لیے ان پیغامات کی اجازت دیں، یا مان لیں کہ کلیمپنگ آپ کی منتخب کردہ پالیسی کی تلافی کر رہی ہے۔
آخر میں، کلیمپ کو ٹیوننگ نوب سمجھنے کے لالچ کا مقابلہ کریں۔ یہ سیگمنٹ کا سائز محدود کرتی ہے، جو ان راستوں پر تھرو پٹ خرچ کرتی ہے جنہیں اس کی کبھی ضرورت نہ تھی۔ تین جانچوں کے بعد لاگو ہو تو یہ نشانہ شدہ مرمت ہے؛ پہلے لاگو ہو تو یہ وہ تبدیلی ہے جو اصل خرابی چھپاتی ہے اور ہر بعد کی جانچ میں دوسرا متغیر شامل کرتی ہے۔ وہ سودا جان بوجھ کر کرنے کے قابل ہے، طے شدہ طور پر نہیں۔
جو path-MTU آپ نے ناپا، جو ٹنل اوور ہیڈ منفی کیا، جو قاعدہ شامل کیا اور بعد میں جو MSS دیکھا، لکھ لیں۔ چار اعداد اگلی واردات کو تحقیق کے بجائے تلاش بنا دیتے ہیں۔