OpenVPN پروفائل کی منتقلی: منتقلی کلیدیں بمقابلہ پلیٹ فارم کے اختیارات

وہی .ovpn فائل ایک کلائنٹ میں ٹنل کھولتی ہے اور دوسرے میں شروع نہیں ہوتی، اور سرٹیفکیٹ عموماً پہلا مشتبہ ہوتا ہے۔ اکثر فائل میں ایسی ہدایت ہوتی ہے جسے صرف ایک انجن نافذ کرتا ہے۔ پروفائل کسی مخصوص کلائنٹ کے ساتھ معاہدہ ہے، منتقلی اسکرپٹ نہیں۔

شناخت کے ساتھ سفر کرنے والی چیز کو پلیٹ فارم سے تعلق رکھنے والی چیز سے الگ کریں۔ پھر ناکامی عموماً خود اپنا نام بتا دیتی ہے۔

ایک فائل، دو معاہدے

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

ایک پلیٹ فارم کے GUI میں چلنے والی فائل دوسرے پلیٹ فارم کے کمانڈ لائن کلائنٹ کے لیے خودکار طور پر درست نہیں ہوتی۔ جب دونوں OpenVPN ہوں تب بھی پارسر اور اختیارات کے مجموعے مختلف ہوتے ہیں۔ اسی لیے کامیاب درآمد منتقلی پروفائل کا ثبوت نہیں ہے۔

منتقلی مواد بمقابلہ پلیٹ فارم ہدایات

شناخت اور نقل و حمل کے حصے وہ حصہ ہیں جنہیں محفوظ رکھنا ہے۔ ca, cert, key اور remote بتاتے ہیں کون کہاں جڑتا ہے، اور یہ ہر موزوں کلائنٹ کے لیے ایک ہی معنی رکھتے ہیں۔

رویے کی ہدایات وہ حصہ ہیں جن کا موازنہ کرنا ہے۔ block-outside-dns، مثال کے طور پر، Windows میں DNS کے رویے کو بدلنے کے لیے موجود ہے۔ ہو سکتا ہے Unix کلائنٹ اسے بالکل نہ پہچانے۔

وصول کرنے والے کلائنٹ کی اختیارات کی فہرست پڑھیں، بھیجنے والے کی نہیں۔ OpenVPN 2.6 حوالہ دستی انجن کے اختیارات درج کرتا ہے، اور GUI کا درآمدی ڈائیلاگ وہ فہرست نہیں ہے۔

سرٹیفکیٹ سے پہلے پارسر کی خرابی پڑھیں

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

اگر خرابی مصافحہ، سرٹیفکیٹ یا سائفر کا ذکر کرے تو پروفائل پارس ہو چکا ہے اور مسئلہ کہیں اور ہے۔

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

مراعات دوسری حد ہیں

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

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

جان بوجھ کر موافق بنائیں

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

شناخت، روٹنگ اور DNS کو تین الگ نتائج کے طور پر جانچیں۔ جو پروفائل توثیق اور روٹنگ کرتا ہے مگر ناموں کا حل توڑ دیتا ہے وہ جزوی طور پر موافق بنایا گیا پروفائل ہے، چلنے والا نہیں۔