VPN جڑتا ہے مگر LAN آلات تک نہیں پہنچتا: کیا جانچنا ہے

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

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

گیٹ وے اپنے ہی اسٹیک سے جواب دیتا ہے

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

سرنگ کے ذریعے پہنچنے والے انتظامی صفحات بھی پہلی قسم میں آتے ہیں۔ وہ سرنگ کے بارے میں ثبوت ہیں، اس کے پیچھے کے نیٹ ورک کے بارے میں نہیں۔

بہاؤ کو پہلی اس حد تک ٹریس کریں جو اسے گرا دیتی ہے

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

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

واپسی کے راستے اور میزبان فائر وال الگ الگ ناکام ہوتے ہیں

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

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

کلائنٹ کے ماخذ پتے کے ساتھ ہر ہاپ کی تصدیق کریں

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

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

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

درج کریں کہ کس پتے نے جواب دیا اور کون سی فارورڈ شدہ منزل ناکام ہوئی۔ وہی جملہ رپورٹ کو سرور ناقابل رسائی ہونے کے دعوے کے بجائے قابل عمل بناتا ہے۔