تمام ICMP کو بلاک کرنا کام کرنے والا VPN راستہ کیوں توڑ دیتا ہے

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

اس راستے پر ICMP اصل میں کیا لے کر جاتا ہے

IPv4 راستے کی MTU دریافت اس پر منحصر ہے کہ راؤٹر بتائے کہ don't-fragment بِٹ والا پیکٹ آگے نہیں بھیجا جا سکا۔ وہ رپورٹ ICMP Fragmentation Needed پیغام ہے، اور اس کے بغیر بھیجنے والے کے پاس اپنے حصے کا سائز کم کرنے کی کوئی وجہ نہیں۔ IPv6 زیادہ سخت ہے: راؤٹر ٹرانزٹ میں تقسیم نہیں کرتے، اس لیے ICMPv6 Packet Too Big پیغام ہی واحد اشارہ ہے جو بھیجنے والے کو چھوٹا کرتا ہے۔

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

کچھ ٹرانسپورٹ اپنی دریافت probe پیکٹ سے نافذ کرتے ہیں، جیسا کہ RFC 4821 بیان کرتا ہے، اور وہ اس فیڈبیک پر کم انحصار کرتے ہیں۔ یہ جانچنے کی دلیل ہے کہ آپ کون سی ٹرانسپورٹ چلاتے ہیں، یہ ماننے کی نہیں کہ ہر ٹنل محفوظ ہے۔

ناکامی سائز پر منحصر ہے

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

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

قواعد میں ترمیم سے پہلے ناپیں

don't-fragment بِٹ اور اپنے منتخب کردہ پے لوڈ سائز سے جانچیں, ناکام کلائنٹ سے محفوظ پتے کی طرف:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

1472 بائٹ کا پے لوڈ اور 28 بائٹ ہیڈر مل کر 1500 بائٹ کا پیکٹ بناتے ہیں۔ اگر بڑا probe تقسیم کی خرابی سے ناکام ہو اور چھوٹا گزر جائے، تو آپ نے حد پا لی؛ ٹنل کے اضافی بوجھ کے لیے ایڈجسٹ کریں اور کام کرنے والا سائز مستحکم ہونے تک دہرائیں۔

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

قاعدہ تنگ کریں، پھر کام دوبارہ جانچیں

اصلاح کو مخصوص کنٹرول پیغامات کی اجازت دینی چاہیے، پورے پروٹوکول کی نہیں۔ iptables ہوسٹ پر شکل قسم کے مطابق اجازت ہے؛ نحو کو اس کے مطابق ڈھالیں جو آپ کے پلیٹ فارم پر فائر وال کا انتظام کرتا ہے:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

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

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