کئی ذیلی نیٹ ورکس والا IPsec واپسی ٹریفک کھو رہا ہے؟ reqid گنیں

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

کوئی بھی چیز بدلنے سے پہلے علامت کو الگ کریں

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

MTU سے آغاز نہ کریں۔ غلط MTU رکاوٹیں اور ٹکڑوں کے آثار پیدا کرتا ہے، بڑھتے ہوئے باہر جانے والے کاؤنٹروں کے ساتھ صاف سمت کی تقسیم نہیں۔

پالیسی ڈیٹا بیس اور حالت کا ڈیٹا بیس پڑھیں

لینکس میں خفیہ کاری کا فیصلہ پالیسی اندراجات کرتے ہیں، اس لیے مماثل پالیسی، روٹ نہیں، پیکٹ کو سرنگ میں داخل کرتی ہے۔ ip xfrm policy چلائیں تاکہ ہر اندراج کے سلیکٹر، سمت، ترجیح اور سانچہ دیکھ سکیں، اور ip xfrm state تاکہ قائم شدہ ایسوسی ایشنز ان کے reqid کے ساتھ دیکھ سکیں۔ پالیسی اور ایسوسی ایشن اسی reqid سے جڑتے ہیں۔

تینوں سمتوں کو دیکھیں۔ باہر جانا اور اندر آنا اس میزبان تک اور اس سے ٹریفک کا احاطہ کرتے ہیں؛ آگے بھیجنے کی سمت اس وقت اہم ہے جب میزبان دوسروں کے لیے روٹنگ کرتا ہے۔ ایک سمت میں غائب یا غیر مماثل اندراج کسی بھی خفیہ کاری کی خرابی کے بغیر یک طرفہ نتیجہ کی وضاحت کرتا ہے۔

کلاسیکی عدم توازن: کئی ذیلی نیٹ ورکس کے لیے ایک reqid

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

اصلاح ایک ترتیب کی تبدیلی ہے، فائر وال اصول نہیں: generate_policy unique; ہر پالیسی کو اس کا اپنا reqid دیتا ہے، تاکہ ہم منصب کی فی پالیسی ایسوسی ایشنز کے مماثل ساتھی ہوں۔ اسے لاگو کریں، دوبارہ گفت و شنید کریں، اور کامیابی کا اعلان کرنے سے پہلے متوقع ذیلی نیٹ ورکس کے مختلف reqid گنیں۔

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

سلیکٹر گفت و شنید سے آتے ہیں، آپ کی ترتیب سے نہیں

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

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

اسی ترتیب سے تصدیق کریں، اور جانیں کہ کیسے واپس ہٹنا ہے

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

ہم منصب بدلنے سے پہلے دونوں xfrm کمانڈوں کی موجودہ آؤٹ پٹ محفوظ کریں۔ اگر نئی ترتیب واپسی کی سمت بحال نہ کرے، تو اس آؤٹ پٹ کو بحال کرنا یادداشت سے سرنگ دوبارہ بنانے سے تیز واپسی ہے، اور موازنہ دیانت دار رکھتا ہے۔