NM OpenVPN: محفوظ شدہ پروفائل آپ کی .ovpn فائل نہیں ہے

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

فائل پروفائل نہیں ہے

درآمد ایک ترجمہ ہے، ماؤنٹ نہیں۔ پلگ ان جن اختیارات کو سمجھتا ہے وہ کنکشن کی vpn.data لغت میں کلیدیں بن جاتے ہیں؛ جن اختیارات کو نہیں سمجھتا وہ خارج کر دیے جاتے ہیں یا کہیں اور درج ہوتے ہیں، اور اصل راستہ صرف ایک حوالہ ہے۔ بعد میں ماخذ فائل میں ترمیم پہلے سے محفوظ کنکشن میں کچھ نہیں بدلتی۔

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

محفوظ شدہ پروفائل پڑھیں، مکالمہ نہیں

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

جب دو پروفائل ایک ہی نام شیئر کریں تو UUID استعمال کریں، اور تصدیق کریں کہ سروس کی قسم آپ کی متوقع OpenVPN پلگ ان ہے، کوئی دوسری VPN قسم نہیں جو اتفاقاً نصب ہو۔ پھر اینڈ پوائنٹ، ٹرانسپورٹ اور سرٹیفکیٹ حوالوں کا کام کرنے والی کال سے موازنہ کریں۔

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

دو کلیدیں، اور ایک اہم سمت

TLS توثیق استعمال کرنے والے کنکشن کے لیے، پلگ ان مشترکہ کلید کا راستہ ta میں اور سمت ta-dir میں محفوظ کرتا ہے، جب تعیناتی کوئی سمت استعمال کرتی ہے۔ دونوں پروفائل کی ڈیٹا لغت میں رہتے ہیں، اور دونوں کو وہی ہونا چاہیے جس کی سرور توقع کرتا ہے۔

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

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

ایک اندراج اپ ڈیٹ کریں، لغت نہیں

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

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

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

کنٹرول چینل کے طریقوں کو نہ ملائیں

tls-auth, tls-crypt، اور tls-crypt-v2 مختلف ترتیبیں ہیں۔ ملتی جلتی کلید کی فائل انہیں قابل تبادلہ نہیں بناتی، اور TLS-Auth فیلڈز بھرنا کسی دوسرے پروفائل میں فارمیٹ شدہ کلید ہونے کی وجہ سے ایسا پروفائل بناتا ہے جو غلط کلید جیسے انداز میں ناکام ہوتا ہے۔

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

جب سرنگ آپ کا انتظامی سیشن لے کر جاتی ہے تو بازیابی کا راستہ رکھیں۔ محفوظ شدہ تبدیلی لازماً لاگو شدہ تبدیلی نہیں، اور کامیاب درآمد اس بات کا ثبوت نہیں کہ ہر ماخذ اختیار معاون تھا۔ آپ جس لنک پر کام کر رہے ہیں اسے دوبارہ جوڑنے سے پہلے دونوں خلا جاننے کے قابل ہیں۔