نیٹ ورک انٹرفیس کا نام بدلنے کے بعد Access Server نے اپنا بندھن کھو دیا: چابیاں درست کریں

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

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

علامت دراصل کیا کہتی ہے

جو ڈیمون بندھ نہیں سکتا وہ عام طور پر اپنے لاگ میں کہتا ہے: پتہ دستیاب نہیں یا انٹرفیس موجود نہیں۔ پیغام مخصوص ہے: یہ اس پتے کا نام لیتا ہے جو ڈیمون نے آزمایا؛ میزبان پر ip -br addr سے موازنہ کریں تاکہ معلوم ہو کہ انٹرفیس کا نام بدلا، ہٹایا گیا یا پرانے پتے کے بغیر اٹھایا گیا۔

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

ترمیم سے پہلے ترتیب پوچھیں

Access Server اپنی ترتیب اپنے CLI کے ذریعے دکھاتا ہے۔ دستاویزی منظر یہ ہے:

sacli ConfigQuery

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

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

مقرر کریں کہ کون سا سننے والا ٹوٹا ہے

Access Server ایک سے زیادہ سننے والے چلاتا ہے۔ OpenVPN ڈیمون سرنگ کی ٹریفک لے کر چلتے ہیں، ویب سروس انتظامی اور گاہک پورٹل، اور دیگر حصوں کے اپنے پورٹ ہو سکتے ہیں۔ ناکام براؤزر درخواست نہیں بتاتی کہ کون ناکام ہوا، اور نہ غلطی کے پیغام میں پورٹ نمبر۔

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

نامزد ترتیب بدلیں، ملتی ہوئی سطریں نہیں

سبق ConfigPut کو مخصوص چابیوں پر دستاویز کرتا ہے، جیسے vpn.daemon.0.server.ip_address اور vpn.daemon.0.listen.ip_address۔ مصنوعات کا اپنا طریقہ چابی کے نام اور نئی قدر کے ساتھ، اپنے ورژن کے دستاویزی نحو میں استعمال کریں، اور صرف اسی سننے والے کی چابیاں بدلیں جس کی آپ نے تشخیص کی۔

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

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

اسے نافذ کریں، پھر ثابت کریں کہ راستہ کام کرتا ہے

قدر درست ہونے کے بعد اسے مصنوعات کے دستاویزی حیاتی دور کے ذریعے نافذ کریں ( حیاتی دور )۔ سبق چابیاں مقرر کرنے کے بعد sacli start استعمال کرتا ہے؛ یہ مکمل میزبان ری بوٹ یا ڈیٹا بیس ری سیٹ نہیں ہے۔

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

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