سرور سے منسلک پروفائل TLS پراکسی کے پیچھے ناکام ہوتا ہے: کون سی نسل؟
Access Server 2.8 اور 2.9 سرور سے منسلک پروفائل مختلف طریقے سے بناتے ہیں۔ سامنے کا حصہ بدلنے سے پہلے طے کریں کہ آپ کی پراکسی کون سا راستہ توڑتی ہے۔
ایک صارف جڑ سکتا ہے اور دوسرا نہیں، اسی پورٹل سے، اسی دن۔ دونوں کے پاس سرور سے منسلک پروفائل ہیں، دونوں ایک ہی Access Server بلڈ پر ہیں، اور واحد فرق یہ ہے کہ ان کا پروفائل کب بنایا گیا۔ یہی وہ نمونہ ہے جسے پہچاننا چاہیے، کیونکہ "سرور سے منسلک" کسی رابطے کی ترتیب نہیں بلکہ پالیسی کا نام ہے۔ Access Server نے اس آرٹیفیکٹ کی دو نسلیں جاری کی ہیں، اور ایک TLS ریورس پراکسی ان کے صرف ایک راستے کے سامنے ہے۔ آپ کس شاخ میں ہیں، یہ تین شرطیں طے کرتی ہیں۔
دو نسلیں، دو رابطہ ترتیبیں
2.8 تک رائج پرانے ڈیزائن میں درآمد شدہ فائل ایک جعلی پروفائل ہے۔ OpenVPN Connect اسے HTTPS کے ذریعے Access Server کے ویب API کے سامنے تصدیق کے لیے استعمال کرتا ہے، عارضی کاربر سے منسلک پروفائل اور سیشن ٹوکن وصول کرتا ہے، اور اسی کے بعد VPN قائم کرتا ہے۔ دو ٹرانسپورٹ ترتیب سے چلتے ہیں، اور پہلا ایک عام ویب درخواست ہے۔
2.9 کے ساتھ متعارف کرایا گیا فارمیٹ وہ فی ربط آغاز نہیں کرتا۔ یہ ایک مقامی پروفائل ہے جسے ہم آہنگ OpenVPN کلائنٹ استعمال کر سکتے ہیں، صرف OpenVPN Connect نہیں۔ اسے ڈاؤن لوڈ کرنا یا URL کے ذریعے درآمد کرنا اب بھی HTTPS شامل کر سکتا ہے — یہ اشاعت کا مرحلہ ہے، فی ربط عارضی پروفائل حاصل کرنا نہیں۔
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
اپ گریڈ پہلے سے جاری شدہ پروفائلز کو لازماً دوبارہ نہیں لکھتا، اس لیے موجودہ سرور ورژن اب بھی پرانا آرٹیفیکٹ تقسیم کر سکتا ہے۔ سرور بلڈ بتاتا ہے کیا ممکن ہے، یہ نہیں کہ اس صارف نے کیا درآمد کیا۔
آپ کی شاخ چننے والی تین شرطیں
پہلی شرط آرٹیفیکٹ کی نسل ہے۔ فائل طلب کریں، دیکھیں کہ وہ کیسے بنی، اور درآمد کرنے والے کلائنٹ کا ورژن نوٹ کریں۔ اگر فائل سے نسل متعین نہ کر سکیں تو ٹیسٹ اکاؤنٹ کے لیے جاری کردہ نیا پروفائل بتائے گا کہ سرور آج کیا پیدا کرتا ہے، اور یہ ناکام صارف کے پاس موجود معلومات سے مختلف ہے۔
دوسری شرط یہ ہے کہ آپ کا سامنے کا حصہ واقعی کیا ختم کرتا ہے۔ ساتویں پرت کی HTTP ریورس پراکسی جو TLS ہٹاتی ہے چوتھی پرت کے TCP فارورڈر کے برابر چیز نہیں، اور UDP فارورڈر بھی نہیں۔ پورٹ 443 پر Access Server کی معمول کی ترتیب OpenVPN TCP ڈیمان کو براؤزر کی ٹریفک پہچاننے اور ویب سروسز کے حوالے کرنے پر مجبور کرتی ہے، اس لیے سامنے غیر متعلق HTTPS ٹرمنیٹر لگانا اس ڈیمان کی پروٹوکول ہینڈلنگ کو محفوظ نہیں رکھتا۔ ایک ہی عدد 443 بانٹنا دو ڈیزائن برابر نہیں کرتا۔
تیسری شرط یہ ہے کہ ناکامی کہاں پڑتی ہے۔ VPN سے پہلے کی ناکامی اور کنٹرول چینل کی ناکامی صرف "جڑ رہا ہے" کہنے والے کلائنٹ میں ایک جیسی نظر آتی ہیں، لیکن وہ مختلف جگہوں پر ثبوت چھوڑتی ہیں۔ اگر پرانا فارمیٹ چل رہا ہو تو آغاز امیدوار ہے۔ اگر نیا فارمیٹ چل رہا ہو تو خالی ویب رسائی لاگ متوقع ہے اور کسی بھی طرف کچھ ثابت نہیں کرتا۔
جب آرٹیفیکٹ پرانا ہو: آغاز پہلے ناکام ہوتا ہے
کلائنٹ کی آخری حالت کے بجائے اس کی اصل خرابی پڑھیں۔ دلچسپی کے میدان HTTPS خرابی، وہ سرور شناخت جس کی کلائنٹ توقع رکھتا تھا، وہ منزل جہاں درخواست گئی، اور یہ کہ سرٹیفکیٹ کی تصدیق مکمل ہوئی یا نہیں۔ پھر انہیں سرور کی طرف ویب سروس اور پراکسی لاگز سے ملا کر دیکھیں۔
براؤزر کا لاگ ان صفحے تک پہنچنا اس بات کا ثبوت نہیں کہ اس کلائنٹ کی API تصدیق کامیاب ہوئی۔ یہ مختلف درخواستیں ہیں، مختلف سرٹیفکیٹ توقعات اور اکثر مختلف ہوسٹ ناموں کے ساتھ۔ اگر پورٹل درست طور پر پیش کیا جاتا ہے اور کلائنٹ پھر بھی ناکام ہوتا ہے، تو اختلاف آغاز کے راستے میں ہے، صارف کے پاس ورڈ میں نہیں۔
TLS تصدیق بند کر کے یا تصدیق کی پالیسی نرم کر کے موازنہ کو کامیاب نہ بنائیں۔ یہ تشخیص کے قابل کنفیگریشن عدم مطابقت کو ایسے راستے میں بدل دیتا ہے جو چلتا ہے مگر تصدیق شدہ نہیں، اور یہی وہ تبدیلی ہے جو عارضی جانچ کو مستقل سوراخ بنا دیتی ہے۔ Access Server کی کنکشن پروفائل دستاویز دونوں نسلوں اور عارضی پروفائل کے بہاؤ کی وضاحت کرتی ہے، اور یہی وہ حوالہ ہے جسے پراکسی کو قصوروار ماننے سے پہلے جانچنا چاہیے۔
جب آرٹیفیکٹ نیا ہو: اس کے بجائے کنٹرول چینل پڑھیں
2.9 طرز کے پروفائل کے ساتھ کلائنٹ سیدھا مقامی VPN اینڈ پوائنٹ پر جاتا ہے۔ پروفائل میں اینڈ پوائنٹس، استعمال شدہ ٹرانسپورٹ، اور کنٹرول چینل کی خرابی جانچیں۔ اگر کلائنٹ کبھی HTTP درخواست جاری نہ کرے تو یہ ڈیزائن کے مطابق ہے اور علامت نہیں۔
یہیں پراکسی کا سوال بھی شکل بدلتا ہے۔ HTTPS ان لوڈ صرف TCP والے اس اسٹریم کو نہیں توڑ سکتا جو اسے کبھی نظر نہیں آتا، لیکن وہ ڈاؤن لوڈ کو اب بھی توڑ سکتا ہے جو پروفائل شائع کرتا ہے، اور صرف TCP فارورڈر UDP بالکل نہیں اٹھائے گا۔ سامنے کا حصہ غیر متعلق ہے کا نتیجہ اخذ کرنے سے پہلے دیکھیں کہ پروفائل کون سا ٹرانسپورٹ مانگتی ہے۔
ایک اسٹریم کے لیے TLS گزر تنگ ترتیب ہے۔ یہ UDP فارورڈنگ فراہم نہیں کرتا، اور 443 پر ڈیمان کے اپنے سروس فارورڈنگ رویے کو دوبارہ پیدا نہیں کرتا۔ اگر آپ کا سامنے کا حصہ ان میں سے کوئی ایک کرتا ہے تو بتائیں کون سا، کیونکہ علاج مختلف ہے۔
تنگ رہنے والے علاج
سب سے کم مداخلت والی جانچ یہ ہے کہ ٹیسٹ اکاؤنٹ کے لیے نیا معاون پروفائل بنائیں اور وہی تصدیقی تقاضے رکھتے ہوئے مطلوبہ مقامی اینڈ پوائنٹ سے جڑیں۔ اگر وہ چلے اور محفوظ پرانا پروفائل نہ چلے، تو آپ نے ایک ہی قدم میں آرٹیفیکٹ کو سرور اور پراکسی سے الگ کر دیا۔
کاربر سے منسلک پروفائل کی تقسیم پرانے آغاز کا انحصار مکمل طور پر ہٹا دیتی ہے، کیونکہ کوئی عارضی پروفائل تبادلہ نہیں جو ناکام ہو سکے۔ یہ مطلوبہ صارف کے لیے جاری ہونا چاہیے، کبھی منتظم سے نقل نہیں، اور یہ بدلتا ہے کہ کلائنٹ کس چیز کا مجاز ہے، اس لیے اسے عارضی حل نہیں بلکہ پالیسی فیصلہ سمجھیں۔
پھر اشاعت کا خاکہ اس طرح درست کریں کہ ہر ضروری راستہ موجود ہو: ڈاؤن لوڈ اور پورٹل استعمال کے لیے ویب راستہ، اور اس ٹرانسپورٹ پر مقامی VPN راستہ جس کی پروفائل توقع رکھتی ہیں۔ پراکسی کا کام ایک ہی پرت میں رکھیں۔ چلنے والا کاربر سے منسلک سرنگ ثابت کرتا ہے کہ وہ راستہ چلتا ہے؛ یہ ثابت نہیں کرتا کہ ہر پراکسی ترتیب ہر نسل کی معاونت کرتی ہے، اور پرانے آغاز کی ناکامی نئے فارمیٹ کی مذمت نہیں کرتی۔
- پراکسی کو چھونے سے پہلے آرٹیفیکٹ کی نسل کی نشاندہی کریں۔
- طے کریں کہ ناکامی سرنگ سے پہلے ہوتی ہے یا اس کے اندر۔
- تصدیق کریں کہ سامنے کا حصہ کیا ختم کرتا ہے: HTTP، TCP اسٹریم، یا UDP۔
- پالیسی بدلے بغیر نئے جاری شدہ پروفائل کو مقامی اینڈ پوائنٹ کے سامنے جانچیں۔