درآمد کرنے سے پہلے OpenVPN پروفائل کے سرور کی تصدیق کیسے کریں

کوئی آپ کو پروفائل بھیجتا ہے، آپ اسے درآمد کرتے ہیں، اور تیس سیکنڈ بعد کوئی کلائنٹ ایسی منزل کی طرف ڈائل کر رہا ہوتا ہے جسے کسی نے جانچا نہیں۔ پہلے فائل کو متن کے مدیر میں پڑھیں، کیونکہ جو کچھ اہم ہے وہ مٹھی بھر ہدایات میں سمایا ہوتا ہے: remote، proto، port، ca، cert، tls-crypt اور verify-x509-name۔ باقی سب ڈیفالٹ ہیں، اور حیرتیں ڈیفالٹ ہی میں رہتی ہیں۔

فائل جو بھی اینڈ پوائنٹ استعمال کر سکتی ہے، سب گنوائیں

اینڈ پوائنٹس سے شروع کریں، کیونکہ ایک پروفائل میں کئی ہو سکتے ہیں۔ grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn ہر امیدوار کو فائل کی ترتیب سے چھاپتا ہے، بشمول اُن کے جو اندرونی <connection> بلاکس کے اندر ہوں۔

جب کوئی ہدایت پورٹ نہیں دیتی، کلائنٹ سننے والے کی طے شدہ قدر پر واپس آ جاتا ہے، لہٰذا remote vpn.example.com اکیلے کا مطلب پورٹ 1194 ہے، چاہے proto فائل میں بعد میں کچھ بھی ہو۔ کئی سادہ remote سطریں متبادل ہیں: کلائنٹ اُنہیں ترتیب سے آزمانا ہے جب تک remote-random اُنہیں گڈمڈ نہ کرے، اور یہ خاموشی سے کسی دوسرے آپریٹر کا میزبان کبھی نہیں لگاتا۔ غیر متعلقہ ڈومینز پر دو remote سطریں وہ مقام ہیں جہاں آپ رک کر پوچھیں کہ کون سی مراد تھی۔

proto کی ہجے پر بھی غور کریں۔ tcp کو کلائنٹ کی طرف tcp-client کا مترادف مانا جاتا ہے، لیکن کلائنٹ پروفائل میں tcp-server ترتیب کی خرابی ہے جو صاف ناکامی کے بجائے لٹکنے کا رجحان رکھتی ہے۔

پہلے نام کی، پھر پورٹ کی تصدیق کریں

dig +short vpn.example.com بتاتا ہے کہ نام موجود ہے یا نہیں اور کون سے پتے واپس کرتا ہے، اور کثیر الوصلہ یا پراکسی کے پیچھے والا اینڈ پوائنٹ جائز طور پر کئی پتے واپس کر سکتا ہے۔ نام کا حل ہونا پیشگی شرط ہے، ملکیت کا ثبوت نہیں؛ کوئی بھی نام کو کسی پتے کی طرف اشارہ کر سکتا ہے، اور ایک پتہ کئی ناموں کا جواب دے سکتا ہے۔

پھر جو پورٹ آپ نے پایا اُس پر سننے والے کی جانچ کریں، ٹرانسپورٹ سے ملاتے ہوئے۔ TCP پر openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com وہ سلسلہ چھاپتا ہے جو سرور پیش کرتا ہے۔ UDP پر آپ کو DTLS چاہیے: openssl s_client -dtls1_2 -connect vpn.example.com:1194 ڈیٹاگرامز پر وہی مصافحہ چلاتا ہے۔ مکمل مصافحہ ثابت کرتا ہے کہ کچھ سن رہا ہے اور اس کے پاس سرٹیفکیٹ ہے، جو ping کے دکھانے سے زیادہ اور پروفائل کی اپنی اعتماد کی ترتیبات کے تقاضے سے کم ہے۔

جب مصافحہ ناکام ہو اور میزبان ping کا جواب دے، تو پورٹ غالباً غلط یا فلٹر شدہ ہے۔ اسے درست پورٹ طلب کرنے کی وجہ سمجھیں، قریبی پورٹس صاف کرنے کی دعوت نہیں۔ nc -vzu بھی کچھ اسٹیکس پر کامیابی رپورٹ کرتا ہے جبکہ کچھ نہیں سن رہا ہوتا، لہٰذا بغیر مصافحے کے محض UDP پروب کچھ معنی نہیں رکھتا۔

اعتماد کے پن پتے سے الگ پڑھیں

پتہ طے کرتا ہے کہ کلائنٹ کہاں جائے گا؛ اعتماد کا بلاک طے کرتا ہے کہ پہنچنے کے بعد وہ کس پر یقین کرے گا۔ verify-x509-name "vpn.example.com" name موضوع کا عام نام پن کرتا ہے، اور remote-cert-tls server سرور کی تصدیق کے لیے توسیع شدہ کلید کے استعمال کا تقاضا کرتا ہے۔ آپریٹر کا دیا ہوا پروفائل دونوں رکھنا چاہیے۔

ca، اندرونی <ca> بلاک، اور tls-crypt یا tls-auth میں سے کوئی ایک تلاش کریں۔ tls-auth استعمال کرنے والے پروفائل کو کلائنٹ پر key-direction 1 درکار ہے جب سرور کی طرف سمت 0 استعمال کرے، اور عدم مطابقت مصافحہ کو TLS خرابی سے ناکام کرتی ہے جو سرٹیفکیٹ کی خرابی جیسی پڑھی جاتی ہے۔ ایسی اندرونی CA جو اُس آپریٹر کی نہ ہو جس کا نام آپ نے ابھی حل کیا، یعنی فائل دو ذرائع سے جوڑی گئی ہے، اور یہی وہ صورت ہے جسے صاف انکار کر دینا چاہیے۔

verify-x509-name name، name-prefix یا subject کے اوضاع لیتا ہے، اور آخری مکمل امتیازی نام اُسی ترتیب سے توقع کرتا ہے جس میں سرور اُسے چھاپتا ہے۔ ایسا وضع چنیں جو قدر کی شکل سے میل کھائے، کیونکہ کلائنٹ قریبی مطابقت پر تنبیہ کرنے کے بجائے ہر کنکشن مسترد کر دیتا ہے۔ ایسی فائل کے لیے جو آپ نے نہ لکھی ہو، سادہ میزبان نام کے ساتھ name سب سے کم حیران کن انتخاب ہے۔

وہ آپشنز دیکھیں جو خاموشی سے ناکام ہوتے ہیں

OpenVPN 2.6 data-ciphers کے ذریعے سائفرز پر بات چیت کرتا ہے، اور صرف پرانی cipher AES-256-CBC سطر رکھنے والا پروفائل کنٹرول چینل مکمل کر کے ڈیٹا پر رک سکتا ہے۔ اس قدر کو پڑھنا بتاتا ہے کہ فائل اُس سرور سے پہلے کی ہے یا نہیں جس سے آپ جڑ رہے ہیں؛ اور 2.6 کا دستاویزی صفحہ بات چیت کی ترتیب دیتا ہے اگر آپ کو آپریٹر کو نقل کرنا ہو۔

بغیر فائل نام کے auth-user-pass کا مطلب ہے کلائنٹ پوچھے گا، لہٰذا خود مکمل دکھنے والے پروفائل کو بھی اسناد درکار ہیں۔ auth-user-pass credentials.txt کا مطلب ہے وہ ایسی فائل توقع کرتا ہے جو غالباً آپ کو بھیجی نہیں گئی۔ nobind اور resolv-retry infinite معمولی اور بے ضرر ہیں، جبکہ explicit-exit-notify صرف UDP کے لیے ہے اور TCP پر بے کار ہے۔

ان میں سے کوئی بھی نہیں بدلتا کہ پروفائل کہاں جڑتا ہے، مگر ہر ایک بدلتا ہے کہ وہ جڑتا ہے یا نہیں، اور ان میں سے کوئی بھی کلائنٹ کے درآمد مکالمے میں نظر نہیں آتا۔

فیصلہ کریں، پھر جو فیصلہ کیا اسے درج کریں

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

جو ہیش آپ نے دیکھا اُسے درج کریں، تاکہ اگلا شخص جان سکے کہ فائل بدلی یا نہیں: sha256sum profile.ovpn، اپنے نوٹس میں اینڈ پوائنٹ کے ساتھ لگا دیں۔ پروفائل ایک پورا انتظام ہے، پتوں کی فہرست نہیں، لہٰذا کبھی کام کرنے والے remote کو کسی اور کے اعتماد بلاک میں اُس کی اسناد رکھتے ہوئے نہ جوڑیں۔

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

اگر آپ اسے درآمد کریں اور پہلی کوشش ناکام ہو، تو کلائنٹ کو --verb 3 کے ساتھ چلائیں اور پہلی دس سطریں پڑھیں: حل شدہ remote پتہ، طے شدہ proto اور TLS خرابی اسی ترتیب سے آتے ہیں، جو بتاتا ہے کہ آپ نے اوپر کے کون سے جائزے چھوڑے۔