پروٹوکول 47 بمقابلہ TCP پورٹ 47: دو ہیڈر، دو قاعدے
پروٹوکول نمبر اور پورٹ مختلف ہیڈروں میں رہتے ہیں، اس لیے ایک قاعدہ دوسرے کی جگہ نہیں لے سکتا۔ PPTP دونوں کو الگ کرتا ہے، اور پورٹ کا خانہ GRE بیان نہیں کر سکتا۔
ہوٹل کے نیٹ ورک اور کانفرنس کے فائر وال اکثر ایک حسبِ ضرورت اجازت کا خانہ دکھاتے ہیں، اور کوئی PPTP کے چلنے کی امید میں اس میں 47 لکھ دیتا ہے۔ قاعدہ بن جاتا ہے، ٹنل پھر بھی ناکام ہوتا ہے، اور اگلی کوشش کوئی دوسرا نمبر استعمال کرتی ہے۔ غلطی خود پیکٹ میں ہے: IPv4 میں ایک پروٹوکول فیلڈ ہے جو بتاتی ہے کہ IP ہیڈر کے بعد کیا آتا ہے، جبکہ TCP اور UDP میں پورٹ فیلڈ ہیں جو صرف اسی وقت ہوتے ہیں جب آپ ان ہیڈروں میں سے کسی ایک کے اندر ہوں۔ یہ ایک ہی اجازت کے دو رسم الخط نہیں ہیں۔
IPv4 ہیڈر اگلے پروٹوکول کا نام بتاتا ہے
پروٹوکول فیلڈ IPv4 ہیڈر میں ایک بائٹ ہے، اور یہ پے لوڈ بیان کرنے والا نمبر رکھتی ہے: TCP کے لیے 6، UDP کے لیے 17، GRE کے لیے 47، ESP کے لیے 50۔ پیکٹ فلٹر کرنے والی ہر چیز گہرائی میں دیکھنے سے پہلے وہ قدر پڑھتی ہے، کیونکہ گہرا ہیڈر صرف نوع معلوم ہونے کے بعد معنی رکھتا ہے۔ گفتگو میں بعد میں کوئی پورٹ بدلیں، یہ فیلڈ ہلی نہیں۔
لہٰذا پروٹوکول 47 کے خلاف لکھا گیا قاعدہ IP تہہ بیان کرتا ہے۔ فیصلے میں کوئی پورٹ حصہ نہیں لیتا۔
پورٹ صرف TCP اور UDP کے اندر ہوتے ہیں، کہیں اور نہیں
پورٹ TCP اور UDP ہیڈروں کے اندر سولہ بٹ شناخت کنندہ ہیں، اور ان کا کام ایک ہی پتہ بانٹنے والی گفتگوؤں کو الگ کرنا ہے۔ GRE ہیڈر پروٹوکول نوع کی قدر، اکثر EtherType، کے ساتھ ملٹی پلیکسنگ کے لیے اختیاری چابیاں رکھتا ہے۔ اسی لیے پورٹ 47 کا فقرہ ایسی کسی چیز کا نام نہیں دیتا جس سے GRE پیکٹ مل سکے۔
فائر وال انٹرفیس اس میں سے کتنا دکھاتے ہیں اس میں مختلف ہیں۔ کچھ پروٹوکول نمبر قبول کرتے ہیں، کچھ نام والی فہرست دیتے ہیں، اور کچھ ہی صرف پورٹ کے ساتھ TCP یا UDP قبول کرتے ہیں۔
PPTP ایک وقت میں دونوں تہہ استعمال کرتا ہے
PPTP سب سے واضح مثال ہے کیونکہ یہ اپنا کام جان بوجھ کر دونوں تہوں میں تقسیم کرتا ہے۔ کنٹرول کنکشن پورٹ 1723 پر TCP سیشن ہے، اور ڈیٹا راستہ GRE، پروٹوکول 47 ہے، کہیں بھی کوئی پورٹ شامل نہیں۔ جو فائر وال 1723 کی اجازت دیتا ہے اور کچھ نہیں، وہ بات چیت شروع ہونے دیتا ہے اور پھر پے لوڈ پھینک دیتا ہے۔ ٹنل جڑنے میں ناکام ہونے کے بجائے تصدیق کے بعد لٹکا ہوا دکھائی دیتا ہے، اور اسی لیے علامت اکثر پاس ورڈ کے مسئلے کے طور پر رپورٹ ہوتی ہے۔
| Path | Outer protocol | Port |
|---|---|---|
| Control channel | TCP, protocol 6 | 1723 |
| Data channel | GRE, protocol 47 | None |
قاعدہ لکھتے وقت دونوں سطریں الگ الگ پڑھیں، اور ہر ایک کو فروش کے نحو کے مطابق جانچیں۔ ایک سطر کو پورٹ درکار ہے، دوسری کو پروٹوکول نمبر، اور کوئی واحد اندراج دونوں کو نہیں ڈھکتا۔
پورٹ فارورڈ صفحہ GRE کیوں بیان نہیں کر سکتا
صرف TCP اور UDP قبول کرنے والا فارورڈنگ فارم GRE بیان نہیں کر سکتا، فارم کا نام جو بھی ہو۔ پتہ ترجمہ دوسری مشکل شامل کرتا ہے، کیونکہ GRE میں پورٹ نہیں ہوتے اور مترجم کو اس کے بجائے کال شناخت کنندہ کی پیروی کرنی پڑتی ہے۔ کچھ صارفی راؤٹر ایسا سنبھالنے والا مددگار لے کر آتے ہیں؛ بہت سے نہیں آتے، اور کوئی اضافی TCP اجازت کا اندراج وہ رویہ پیدا نہیں کرے گا۔
جہاں اصل ضرورت جدید ٹنل ہو، وہاں مترجم کے درست اندازہ لگانے کی امید کے بجائے جان بوجھ کر TCP یا UDP استعمال کرنے والا ڈیزائن منتخب کریں۔
انکیپسولیشن طے کرتا ہے کہ فلٹر کیا دیکھتا ہے
انکیپسولیشن بیرونی پیکٹ بدلتا ہے، اور قاعدہ اسی بیرونی پیکٹ سے ملتا ہے۔ اصل ESP پروٹوکول 50 ہے، جبکہ NAT عبور ESP کو UDP 4500 کے اندر لپیٹتا ہے تاکہ وہ پتہ ترجمے سے بچ جائے۔ جو فلٹر UDP 4500 کی اجازت دیتا ہے وہ کبھی پروٹوکول 50 نہیں دیکھتا، اور پروٹوکول 50 کے لیے لکھا گیا فلٹر کبھی لپٹی شکل سے نہیں ملتا۔
پوچھیں کہ کلائنٹ اور گیٹ وے کس انکیپسولیشن پر متفق ہوئے، پھر قاعدہ صرف اسی بیرونی شکل کے لیے لکھیں، اس سے زیادہ کچھ نہیں۔
قاعدہ ایسے لکھیں کہ کوئی اس کی تصدیق کر سکے
ہر قاعدہ کو پتہ خاندان، بیرونی پروٹوکول، اگر ہوں تو نقل و حمل کے پورٹ، سمت اور دونوں سرے کے طور پر بیان کریں۔ جائزہ لینے والا اس جملے کو پیکٹ کیپچر سے ملا کر نتیجے تک پہنچ سکتا ہے۔ 47 کھولنے کی ہدایت کوئی تصدیق نہیں کر سکتا، اور اسی لیے وہ برسوں تک طریقہ کار کی کتابوں میں رہتی ہے۔
وہ آزمائش شامل کریں جو اسے ثابت کرے: بیرونی انٹرفیس پر کیپچر کرتے ہوئے جڑیں، اور اس بیرونی پروٹوکول اور پورٹ کی تصدیق کریں جو واقعی نشان میں نظر آتے ہیں۔