OpenVPN روٹ حد دراصل کس جزو کی ملکیت ہے؟

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

تین مراحل، تین مختلف حدیں

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

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

کچھ بھی ناپنے سے پہلے تینوں کو الگ کریں۔ پارسر کی خرابی ایک ٹوکن کا نام لیتی ہے، انسٹالر کی حد مختصر راستہ جدول چھوڑتی ہے، اور پالیسی کا فیصلہ کچھ بھی نہیں چھوڑتا۔ ثبوت بتاتا ہے کہ پہلے کون سا مرحلہ جانچنا ہے۔

پارسر پہلے بولتا ہے

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

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

نسخے کی تار اسی بائنری سے درج کریں جو واقعی چلی، پیکیج مدیر کے اس تصور سے نہیں کہ کیا نصب ہے۔ یہ دونوں توقع سے زیادہ بار نہیں ملتے۔

انسٹالر کی اپنی چھت ہے

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

کیا ترتیب دیا گیا نہیں، کیا پہنچا اسے گنیں۔ ip route show dev tun0 حکم نصب شدہ راستوں کی فہرست دیتا ہے، اور اس عدد کا بھیجی گئی فہرست سے موازنہ پھینکے گئے راستے کو کبھی نہ بھیجے گئے راستے سے الگ کرتا ہے۔ بھیجنے سے ملنے والا عدد شک کو واپس سرور کی طرف موڑتا ہے۔

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

آپ کو کیا پیش کیا گیا، یہ سرور طے کرتا ہے

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

سرور ریکارڈ کا موازنہ موصولہ فہرست سے کریں۔ ان کے درمیان فاصلہ پالیسی کی تہہ ہے، اور یہ عام طور پر اس سے کم ہوتا ہے جو پروفائل اشارہ کرتا ہے۔

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

عدد صحیح جگہ پر بدلیں

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

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