IPv6 پیکٹ بہت بڑا: بڑے VPN ٹرانسفر کیوں رکتے ہیں

پنگ کام کرتا ہے، براؤزر ایک چھوٹا صفحہ لوڈ کرتا ہے اور فائل کی منتقلی رک جاتی ہے، یہ سب ایک ہی ٹنل سے IPv6 پر۔ یہ نمونہ عام طور پر بتاتا ہے کہ بھیجنے والے نے راستے کا اصل سائز کبھی نہیں سیکھا، یہ نہیں کہ ٹنل سست ہے۔ IPv6 توقع کرتا ہے کہ روٹر Packet Too Big پیغام سے مسئلہ بتائیں، اور انکیپسولیشن پیکٹ کے بیرونی نیٹ ورک تک پہنچنے سے پہلے ہی اضافی بوجھ ڈالتا ہے۔ اگر وہ پیغام فلٹر ہو جائے تو بھیجنے والا ایسا سائز دہراتا رہتا ہے جو گزر نہیں سکتا۔

چھوٹی درخواستیں، بڑے رکاؤ

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

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

Packet Too Big فیڈبیک ہے، ٹریفک نہیں

ICMPv6 Packet Too Big پیغام وہ سائز لے جاتا ہے جو اگلا ہاپ قبول کر سکتا ہے، اور بھیجنے والا اسے اپنا اندازہ کم کرنے کے لیے استعمال کرتا ہے۔ اسے فلٹر کرنا سڑک کا نشان ہٹا کر پھر ڈرائیوروں کو قصوروار ٹھہرانے کے مترادف ہے۔ تمام ICMPv6 پھینک دینے والا اصول سخت لگتا ہے، مگر ہر اس لنک پر راستہ تلاش کو توڑ دیتا ہے جسے اس کی ضرورت ہے۔ پیغام راستے کے بارے میں کنٹرول معلومات ہیں، ایپلیکیشن پے لوڈ نہیں۔

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

دونوں ایڈریس خاندان الگ الگ جانچیں

IPv6 کو الگ سے جانچیں، کیونکہ کامیاب IPv4 منتقلی IPv6 راستے کے بارے میں کچھ ثابت نہیں کرتی۔ پھر بڑی منتقلی کے رکنے کے دوران کنٹرول پیغامات کیپچر کریں۔ دونوں ریکارڈ مل کر یا تو دکھاتے ہیں کہ فیڈبیک باہر جا رہا ہے، یا ثابت کرتے ہیں کہ وہ کبھی پہنچا ہی نہیں۔

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

پروب do-not-fragment بٹ سیٹ کر کے پیکٹ بھیجتا ہے اور وہ سائز بتاتا ہے جس پر ناکام ہوتا ہے، یہی وہ عدد ہے جو ٹنل کو سمیٹنا ہے۔ روٹ استفسار وہ انٹرفیس بتاتا ہے جو منزل لے کر جائے گا، تاکہ آپ جان سکیں کہ کس لنک کا MTU لاگو ہے۔ کیپچر ICMPv6 قسم 2، یعنی Packet Too Big پیغام، فلٹر کرتا ہے اور دکھاتا ہے کہ آیا وہ اس ہوسٹ تک پہنچتا ہے۔ اگر پیغام کیپچر میں نظر آئے اور منتقلی پھر بھی رکے، تو بھیجنے والا اسے نظرانداز کر رہا ہے، جو تحقیق کو نیٹ ورک کے بجائے اسٹیک کی طرف لے جاتا ہے۔

ٹنل کا سائز صرف ثبوت کے بعد بدلیں

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

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