VPN کا پنگ کام کرتا ہے مگر ویب سائٹ رک جاتی ہے: سائز دیکھیں

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

سب سے چھوٹے سوال سے سب سے بڑے سوال تک جائیں، اور لکھیں کہ ہر قدم نے واقعی کیا ثابت کیا۔

ایکو جواب بہت چھوٹے سوال کا جواب دیتا ہے

ایکو جواب کہتا ہے کہ منزل کا IP اسٹیک آپ کے ماخذ سے آئی ICMP درخواست کا جواب دیا۔ یہ اس بارے میں کچھ نہیں کہتا کہ آپ کو درکار پورٹ پر TCP سننے والا موجود ہے یا نہیں، کوئی پالیسی اس پورٹ کی اجازت دیتی ہے یا نہیں، یا منزل ہوسٹ گیٹ وے سے آزاد ہو کر ٹریفک فلٹر کرتا ہے یا نہیں۔ ایک سروس کی اجازت دینے والا گیٹ وے دوسری کو گرا سکتا ہے، جبکہ دونوں ہدف پنگ کا جواب دیتے ہیں۔ جواب کو ایک پیکٹ اور ایک سمت کے بارے میں ایک ہی حقیقت سمجھ کر پڑھیں۔

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

معلوم کریں کہ کنکشن شروع ہوا یا نہیں

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

MTU ترتیبات کو چھونے سے پہلے لکھیں کہ ان تین میں سے کون سی صورت دیکھی۔ مسترد کنکشن ٹھیک کرنے کے لیے ٹنل کا سائز بدلنا وہ تبدیلی ضائع کرتا ہے اور اصل وجہ کو کچھ دیر چھپا دیتا ہے۔

بتائے گئے عدد سے سائز ناپیں

جب بوجھ تلے رکنا ظاہر ہو، تو ٹکڑے نہ کرنے والا بٹ لگا کر ایک پیکٹ سائز جانچیں اور حساب بتائیں تاکہ نتیجے کا مطلب ہو۔ iputils والے Linux پر، 1392 بائٹ کا پے لوڈ اور 8 بائٹ کا ICMP ہیڈر اور 20 بائٹ کا IPv4 ہیڈر مل کر ٹھیک 1420 بائٹ کا اندرونی پیکٹ بناتے ہیں۔ وہ حساب ٹکٹ میں لکھیں، کیونکہ گیٹ وے تک پہنچنے والا نرا ping ایپلیکیشن کے بارے میں کچھ ثابت نہیں کرتا۔

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

بیرونی راستے کا حساب رکھیں

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

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

ایک عدد بدلیں اور ایپلیکیشن دوبارہ جانچیں

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

بدلاؤ کے ریکارڈ میں حساب رکھیں: ناپا گیا سائز، جو اضافی بوجھ آپ نے فرض کیا، اور جو قدر آپ نے مقرر کی۔ بعد میں اس کا جائزہ لینے والا کوئی بھی ping کے اسکرین شاٹ سے مفروضہ دوبارہ نکالنے کی بجائے اسے جانچ سکتا ہے۔

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