مقررہ مجازی IP پر IKEv2 کلائنٹ تک پہنچنا

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

ٹنل ماخذ پتہ درست نہیں کرتا

ایک CHILD SA ٹریفک سلیکٹرز کے ایک جوڑے کا احاطہ کرتا ہے، ہر فریق کے لیے ایک، اور اس جوڑے کی دونوں سمتوں میں ٹریفک کی اجازت دیتا ہے۔ یہ اس بارے میں کچھ نہیں کہتا کہ کس پیر نے IKE تبادلہ پہلے کھولا۔ جو گیٹ وے شروع میں ٹنل کے لیے سن رہا تھا وہ اب بھی پہلا ایپلیکیشن پیکٹ بھیج سکتا ہے، بشرطیکہ منتخب ماخذ اور منزل نصب شدہ سلیکٹرز کے اندر ہوں۔ جب درخواست غلط انٹرفیس سے نکلتی ہے تو وہ ٹنل کے لیے موزوں نہیں ہوتی۔

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

نصب شدہ پالیسی پڑھیں، کنفگ فائل نہیں

فعال ایسوسی ایشن اور اس کے سلیکٹرز سے شروع کریں، کیونکہ متحرک تفویض کرنل میں نصب چیز کو بدل دیتی ہے۔

ipsec statusall
ip xfrm policy

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

کلائنٹ کو وہیں سننا چاہیے جہاں پیکٹ پہنچتا ہے

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

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

نئی سمت کو الگ سے جانچیں

کلائنٹ سے سرور تک کامیاب درخواست اس راستے کو کبھی استعمال نہیں کرتی۔ گیٹ وے سے درخواست بنائیں اور دونوں سرے دیکھیں۔

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

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

کلید کی تبدیلی یا دوبارہ جڑنے کے بعد ٹیسٹ دہرائیں، کیونکہ VIP بدل سکتا ہے۔ جو راستہ صرف اگلے سیشن تک کام کرے وہ کام کرنے والا راستہ نہیں۔