کام کرنے والا VPN ہونے کے باوجود جواب پر وقت کیوں ختم ہوتا ہے
درخواست کا نجی سرور تک پہنچنا تبادلے کا صرف آدھا حصہ ہے۔ اس کے جواب کو مطلوبہ گیٹ وے، راستے یا ترجمے کے ذریعے ٹنل کلائنٹ تک پہنچنا ہوتا ہے۔
درخواست آتی ہے، سرور اسے لاگ کرتا ہے، اور کلائنٹ پھر بھی وقت ختم ہونے کی اطلاع دیتا ہے۔ اس امتزاج کا مطلب ہے کہ جواب کو واپسی کا راستہ نہیں ملا، اور یہ ان گنے چنے خرابیوں میں سے ایک ہے جنہیں آپ دونوں سروں سے ایک ساتھ تصدیق کر سکتے ہیں۔ جانچ ترتیب سے کریں اور جب کوئی ایک ناکام ہو تو رک جائیں۔
اس بات سے شروع کریں کہ درخواست کہاں پہنچی
کوئی اور چیز جانچنے سے پہلے تصدیق کریں کہ پیکٹ خدمت تک پہنچ گیا ہے۔ سرور کی طرف لاگ اندراج، کنکشن شمار یا دور سرے پر اجازت شدہ گرفت، سب ایک ہی سوال کا جواب دیتے ہیں، اور ان کا نہ ہونا آپ کو جواب کی طرف نہیں بلکہ ٹنل کی طرف واپس بھیجتا ہے۔ یہی وہ جانچ ہے جو فارورڈنگ کے مسئلے کو واپسی راستے کے مسئلے سے الگ کرتی ہے۔
اگر درخواست کبھی نہیں پہنچی تو یہیں رک جائیں۔ ٹنل، نجی سابقے تک روٹنگ یا رسائی کا اصول موضوع ہے، اور جواب کا راستہ ابھی متعلقہ نہیں۔ سرور نے جو ماخذ پتہ دیکھا وہ بھی نوٹ کریں۔ وہ یا تو کلائنٹ کو ملا پول پتہ ہے یا ترجمہ شدہ پتہ، اور یہی فرق طے کرتا ہے کہ آگے کون سی جانچ لاگو ہوتی ہے۔
جواب کو پول تک راستہ درکار ہے
ریموٹ رسائی کا کلائنٹ عام طور پر پول سے پتہ حاصل کرتا ہے، اور نجی نیٹ ورک کو اس پول تک واپسی کے راستے کی ضرورت ہوتی ہے۔ جس سرور کا طے شدہ راستہ اس کے اپنے گیٹ وے کی طرف اشارہ کرتا ہے وہ پیکٹ اسی گیٹ وے کو دے دیتا ہے، جسے پول کے مقام کا کوئی علم نہیں، اس لیے جواب وہیں دم توڑ دیتا ہے۔ کلائنٹ کو وقت ختم ہونے کی اطلاع اس لیے ملتی ہے کہ کچھ واپس نہیں آیا، اور اسے ایسی درخواست سے الگ نہیں کیا جا سکتا جو کبھی نکلی ہی نہیں۔
سرور جو راستہ اپنے ذیلی نیٹ کے لیے استعمال کرتا ہے وہ نہیں، بلکہ کلائنٹ پتے کے لیے منتخب کرتا ہے وہ راستہ جانچیں۔ یہ دو تلاشیں مختلف جواب دے سکتی ہیں، اور یہاں دوسری ہی اہم ہے۔ ترجمہ متبادل ڈیزائن ہے اور یہ بدل دیتا ہے کہ سرور کیا دیکھتا ہے۔ یہ واپسی راستہ آسان کر سکتا ہے، اور سرور کے لاگوں سے اصل کلائنٹ پتہ بھی ہٹا دیتا ہے، جو اس فیلڈ پر بنی کسی بھی اصول یا رپورٹ کو متاثر کرتا ہے۔
سرور کی گرفت کا گیٹ وے کی گرفت سے موازنہ کریں
سرور سے جو نکلتا ہے اس کا گیٹ وے پر پہنچنے والے سے موازنہ کریں۔ سرور کے آؤٹ باؤنڈ انٹرفیس پر گرفت اور ٹنل گیٹ وے پر گرفت سوال کے مختلف آدھوں کا جواب دیتی ہیں، اور ان کے درمیان فرق نقصان کی جگہ دکھاتا ہے۔
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
گیٹ وے خود جو درخواست بناتا ہے وہ کلائنٹ آزمائش کا کمزور متبادل ہے، کیونکہ وہ دوسرے پتے سے آتی ہے اور دوسرے اصولوں سے ٹکراتی ہے۔ اسی لیے گیٹ وے سے کامیاب ping اور کلائنٹ سے ناکام درخواست دونوں بیک وقت درست ہو سکتی ہیں۔
جب راستے پر کئی راؤٹر ہوں تو ہر اس ایک کو جانچیں جسے پول تک راستہ درکار ہے۔ سائٹ سے سائٹ ڈیزائن میں اکثر ضروری ہوتا ہے کہ دور کا سابقہ ایک سے زیادہ آلات پر معلوم ہو، اور گیٹ وے کو خود ٹنل اور LAN کے درمیان فارورڈ کرنا پڑتا ہے؛ strongSwan کے فارورڈنگ نوٹس اس کے sysctl اور فائر وال پہلو کا احاطہ کرتے ہیں۔
پول، سابقہ اور ذمہ دار شخص نوٹ کریں
نوٹ میں چار حقائق آتے ہیں: کلائنٹ کو ملا پول، اسے درکار نجی سابقہ، جواب کا ذمہ دار راؤٹر، اور اگر ہو تو ترجمے کا اصول۔ ان کے ساتھ بعد میں گیٹ وے کی تبدیلی جانچ نہیں، موازنہ بن جاتی ہے۔
پھر عام کلائنٹ اور ایپلیکیشن کے اصل اکاؤنٹ کے ساتھ دوبارہ جانچ کریں۔ ایپلیکیشن کے اختیارات بڑھانے سے پیکٹ کا واپسی راستہ ٹھیک نہیں ہوتا، اور اس تشخیص کے دوران اکاؤنٹ بدلنے سے اگلا موازنہ الجھ جائے گا۔ اگر ڈیزائن ترجمے پر منحصر ہے تو اسے وہیں دستاویز کریں جہاں سرور کے لاگ پڑھے جاتے ہیں۔ آڈٹ ٹریل میں ناواقف ماخذ پتہ دیکھنے والے کو ٹکٹ سے میپنگ دوبارہ تلاش نہیں کرنی چاہیے۔