OpenVPN پروفائل SoftEther میں کیوں درآمد نہیں ہوتا

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

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

OpenVPN پروفائل ایک کلائنٹ کنفیگریشن ہے: دور دراز اختتامی نقطہ، نقل و حمل، TLS مواد، اور روٹنگ و دوبارہ گفتگو کے لیے ہدایات۔ SoftEther کنکشن مجازی مرکز کے سامنے مقامی کلائنٹ سیشن ہے، جس کے ساتھ مجازی اڈاپٹر جڑا ہوتا ہے۔

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

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

سرٹیفکیٹ بلاک چھونے سے پہلے سرور پڑھیں

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

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

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

سننے والوں کی فہرست سے غائب UDP پورٹ غیر فعال خصوصیت ہے، فائر وال کا مسئلہ نہیں۔

مقامی کلائنٹ کو کیا چاہیے اور پروفائل کیا نہیں دے سکتا

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

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

نجی چابی کو کسی بھی تبدیلی کی خدمت سے دور رکھیں، کیونکہ مشین چھوڑنے والی چابی کو افشا شدہ سمجھا جانا چاہیے۔

OpenVPN کے ساتھ ہم آہنگ سننے والا کیا قبول کرتا ہے

کلائنٹ کے نقطہ نظر سے ہم آہنگی سننے والا ایک حقیقی OpenVPN سرور ہے: یہ OpenVPN کلائنٹ اور اس کلائنٹ کی معاونت کردہ ہدایات کی توقع کرتا ہے۔ اندرونی سرٹیفکیٹ بلاک OpenVPN کی خصوصیت ہیں، اور وہ باڑ کے اسی جانب کے ہیں۔

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

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

ہدایات میں ترمیم سے پہلے راستہ ثابت کریں

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

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

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