.ovpn فائل میں واقعی کیا ہوتا ہے، اور یہ کیا نہیں کر سکتی

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

فائل کو اپنے کلائنٹ سے کی گئی درخواستوں کی فہرست کے طور پر پڑھیں، اور اس کی بیشتر سطریں واضح ہو جائیں گی۔

فائل آپ کے کلائنٹ کی وضاحت کرتی ہے، سرور کی نہیں

ایک پروفائل remote آخری نقطہ، منتقلی، انٹرفیس کی قسم، شناخت کا مواد اور آپریٹر کا مطلوبہ کوئی بھی کلائنٹ کی طرف کا رویہ یکجا کرتا ہے۔ ہر سطر کلائنٹ آغاز پر چلاتا ہے۔ ان میں سے کوئی بھی تشکیل کی تبدیلی کے طور پر سرور تک نہیں پہنچتی، اور کوئی بھی ایسا سننے والا نہیں بنا سکتی جو پہلے سے نہ چل رہا ہو۔ ایسا پروفائل جو TCP 443 کا ذکر کرتا ہے اُس سرور کے سامنے جو صرف UDP 1194 پر سنتا ہے پہلے ہی پیکٹ پر ناکام ہو جاتا ہے۔

اسی لیے وہی فائل دو کلائنٹس پر مختلف رویہ رکھتی ہے: فائل مانگتی ہے، اور کلائنٹ طے کرتا ہے کہ درخواست کا کتنا حصہ پورا کر سکتا ہے۔

منتقلی کی سطروں کو پہلے سے موجود سننے والے سے میل کھانا چاہیے

proto اور remote سطروں کو اُس سے میل کھانا چاہیے جو سرور واقعی باندھتا ہے۔ UDP عام انتخاب ہے کیونکہ گم شدہ ڈیٹاگرام سرنگ کو نہیں روکتا، جبکہ TCP پابند نیٹ ورکس میں سرنگ کے اندر قطار کے سر کی رکاوٹ کی قیمت پر ٹک سکتا ہے۔ پروفائل کو UDP سے TCP پر بدلنے سے سرور TCP قبول نہیں کرتا؛ یہ صرف کلائنٹ کو ایسی پورٹ پر بھیجتا ہے جسے کوئی نہیں پڑھتا۔

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

سرایت شدہ چابیاں فائل سے نمٹنے کا طریقہ بدل دیتی ہیں

سرٹیفکیٹ اور چابیاں <ca>، <cert> اور <key> ٹیگز کے درمیان اندرونی طور پر ہو سکتی ہیں، یا الگ فائلوں کے طور پر حوالہ دی جا سکتی ہیں۔ سرایت شدہ مواد پروفائل کو خود کفیل بناتا ہے اور اسے راز بھی بنا دیتا ہے، کیونکہ کلائنٹ کی نجی چابی اس کے اندر سفر کرتی ہے۔ CA سرٹیفکیٹ عوامی اعتماد کا مواد ہے اور اسے شیئر کرنا محفوظ ہے؛ نجی چابی نہیں، چاہے وہ ناقابلِ پڑھ متن کے بلاک جیسی نظر آئے۔

چابی کی حفاظت کرنے والا پاس فریز اکاؤنٹ پاس ورڈ سے الگ راز ہے، اور دونوں کو ملانا توثیق کی ناکامی پیدا کرتا ہے جو غلط اسناد جیسی لگتی ہے۔

روٹ اور DNS شاید فائل سے ہی نہ آئیں

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

DNS بھی وہی نمونہ اپناتا ہے: دھکیلی گئی dhcp-option DNS کو کلائنٹ لاگو کر سکتا ہے، نظر انداز کر سکتا ہے، یا مقامی حل کنندہ کا منتظم اسے منسوخ کر سکتا ہے۔ پروفائل دوبارہ پڑھنے کے بجائے منسلک ہونے کے بعد حل کنندہ کی حالت جانچیں۔

غیر معاون اختیارات کلائنٹ ورژن کا سوال ہیں

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

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

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