VPN ٹنل میں traceroute صرف ایک سمت میں کیوں مرتا ہے

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

سراغ نقل و حمل کے بارے میں ثبوت بننے سے پہلے تشخیص کے بارے میں ثبوت ہے۔ پوچھنے کے قابل سوال یہ ہے کہ تینوں کڑیوں میں سے کون سی ناکام ہوئی، اور جواب آؤٹ پٹ کی شکل سے نہیں بلکہ پیکٹوں سے آتا ہے۔

ستارہ ایک گم شدہ جواب ہے، گم شدہ ہاپ نہیں

traceroute ہر دور میں ایسے پروب بھیج کر باہر کی طرف بڑھتا ہے جن کا TTL ایک راؤٹر مزید دور ختم ہوتا ہے۔ ختم شدہ پروب پھینکنے والے راؤٹر کو اپنا نام بتانے والا ICMP Time Exceeded پیغام واپس دینا چاہیے، اور آلہ وہ نام چھاپتا ہے۔ آلہ دراصل اس بات کا انتظار کرتا ہے کہ وہ پیغام ایک وقت کی حد کے اندر پہنچے۔ اگر راؤٹر کسی دوسرے ماخذ پتے سے جواب دے، غلطیاں بنانے کی تعدد محدود کرے یا پروب کو بغیر کچھ کہے گرا دے، تو دور چھاپنے کے قابل کچھ نہیں دیتا۔

ان نتائج میں سے کوئی بھی یہ نہیں کہتا کہ آگے کا راستہ ٹوٹا ہوا ہے۔ ستارہ بلا جواب ڈاک کی رپورٹ ہے، خالی سڑک کی نہیں۔

پروب کا طریقہ طے کرتا ہے کہ آپ کو کون سا فلٹر ملے گا

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

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

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

واپسی راستہ اپنا الگ راستہ ہے

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

سراغ مکمل ہونے تک ہر انتخاب کنندہ کو چوڑا کرنا تصویر کو خوبصورت اور پالیسی کو خراب بناتا ہے۔ مخصوص تشخیصی پتہ ٹھیک کریں، یا ستارہ قبول کریں اور ایپلیکیشن کسی اور طرح جانچیں۔

حقیقی درخواست سے ٹنل کی تصدیق کریں

سروس کے اپنے پورٹ پر TCP ہاتھ ملانا اہم سمت میں فارورڈنگ، واپسی راؤٹنگ اور فلٹرنگ کی جانچ کرتا ہے۔ نیچے دی گئی کمانڈیں دونوں سروں پر چلتی ہیں اور موازنہ کرتی ہیں کہ ہر طرف کیا کھول سکتا ہے۔ اپنی ترتیب سے سروس پورٹ اور ٹنل انٹرفیس کا نام بدلیں۔

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

پہلے دونوں traceroute چلانے پڑھیں: اگر ICMP چلانا ہاپ دکھاتا ہے اور TCP چلانا نہیں، تو فرق طریقے میں ہے، راستے میں نہیں۔ پھر curl کے نتیجے کو ایپلیکیشن سطح کا جواب سمجھیں، کیونکہ مناسب حالت کوڈ کے ساتھ مکمل ہونے والا تبادلہ یعنی آگے اور واپسی دونوں راستے حقیقی ٹریفک کے لیے کام کرتے ہیں۔ ساکٹ فہرست دکھاتی ہے کہ کنکشن بنا بھی ہے یا نہیں، جو کوئی سراغ آپ کو نہیں بتا سکتا۔

جو ٹنل دونوں سمتوں میں متعامل نشست ڈھوتی ہے جبکہ ایک traceroute ستارے چھاپتا ہے، وہ صحت مند ہے اور صرف تصویری طور پر اچھا نہیں۔ ہر طرف کی کمانڈ آؤٹ پٹ ریکارڈ کے طور پر رکھیں، اور گم شدہ ہاپوں کو VPN کے بارے میں فیصلہ نہیں بلکہ تشخیص کے بارے میں کھلا سوال سمجھیں۔