HTTP پراکسی کے ذریعے OpenVPN: پہلے CONNECT کا جواب پڑھیں
CONNECT پراکسی بائٹس منتقل کرتی ہے، اس لیے دونوں سروں کو TCP درکار ہے۔ سرٹیفکیٹس کو الزام دینے سے پہلے 407، 403 اور 503 پڑھیں، اور سرور کی تصدیق آن رکھیں۔
VPN کلائنٹ کو کارپوریٹ HTTP پراکسی کی طرف موڑیں، اور پہلی مفید حقیقت یہ ہے کہ پراکسی VPN کا پروٹوکول نہیں بولتی۔ یہ آپ کے بتائے گئے پتے پر ایک عام TCP کنکشن کھولتی ہے اور پھر ایک طرف ہٹ جاتی ہے، جس سے آپ کا کلائنٹ اور سرور اسی اسٹریم کے ذریعے اپنی ادل بدل کرتے ہیں۔ کلائنٹ کو جو کچھ درکار ہے، ٹرانسپورٹ کی قسم سے لے کر سرور کے سننے والے تک، اس ترتیب سے مطابقت رکھنا چاہیے۔ دو عدم مطابقت زیادہ تر ناکامیوں کی وضاحت کرتی ہیں: CONNECT پراکسی کی طرف نشانہ شدہ UDP پروفائل، اور VPN خرابی سمجھا گیا پراکسی کا جواب۔
پراکسی کیا اٹھاتی ہے اور کیا نہیں
پراکسی صرف ٹرانسپورٹ کا ایک مرحلہ ہے۔ یہ آپ کا براؤزر پراکسی نہیں بنتی، سرنگ کے ذریعے آپ جن سائٹس پر جاتے ہیں انہیں کیش نہیں کرتی، اور اندرونی ٹریفک نہیں دیکھتی جب تک کسی نے جان بوجھ کر معائنہ ترتیب نہ دیا ہو۔ جو سرنگ یہ کھولتی ہے وہ ڈیزائن کے مطابق ہی اس کے لیے غیر شفاف ہے۔
اس کا مطلب یہ بھی ہے کہ پراکسی ایسے سرور کو درست نہیں کر سکتی جس کا کوئی مطابق سننے والا نہ ہو۔ کسی منزل تک پہنچنے کی اجازت اور اسی منزل پر سننے والی سروس دو الگ حقائق ہیں، اور صرف پہلی پراکسی منتظم کی ہے۔
حامل کو دونوں سروں پر TCP ہونا چاہیے
روایتی CONNECT پراکسی صرف بائٹ اسٹریم منتقل کرتی ہے ، اس لیے کلائنٹ کو اسٹریم ٹرانسپورٹ استعمال کرنا چاہیے۔ اس صورت کے لیے کلائنٹ کا ٹکڑا ایسا دکھائی دیتا ہے:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128سرور کی جانب کو remote لائن میں بتائے گئے پورٹ پر حقیقی TCP سننے والا درکار ہے۔ پروفائل میں proto udp کو proto tcp-client میں بدلنے سے ایسا کلائنٹ بنتا ہے جو اسٹریم کی توقع کرتا ہے؛ یہ دوسری طرف اسٹریم نہیں بناتا۔ اگر وہی سرور اس پورٹ پر UDP کے ذریعے بھی جواب دے، تو وہ الگ سننے والا ہے، اسی کا دوسرا موڈ نہیں۔
جہاں الگ TCP انسٹانس موجود ہے، وہاں اس کا سرنگ آلہ، پتوں کا تالاب اور روٹنگ اپنے وسائل ہیں۔ کام کرنے والی ترتیب نقل کر کے ٹرانسپورٹ کا لفظ بدلنے سے وہ وسائل اصل انسٹانس کی طرف ہی اشارہ کرتے رہتے ہیں، جس سے ایسا کنکشن بنتا ہے جو تصدیق کرتا ہے اور پھر کچھ بھی روٹ نہیں کرتا۔
VPN نتیجے سے پہلے پراکسی کا جواب پڑھیں
کلائنٹ کی پہلی ادل بدل ایک درخواست لائن ہے جو منزل کا ہوسٹ اور پورٹ نام دیتی ہے۔ اس لائن کا جواب آپ کو بتاتا ہے کہ بائٹ اسٹریم ہے بھی یا نہیں، اور یہ کسی بھی سرٹیفکیٹ یا اسناد کی جانچ سے پہلے آتا ہے:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT پر 200 درجے کا جواب یعنی اسٹریم موجود ہے۔ یہ نہیں بتاتا کہ گیٹ وے سرٹیفکیٹ قابل اعتماد ہے یا نہیں، مشترکہ کلید میل کھاتی ہے یا نہیں، یا صارف کا اکاؤنٹ درست ہے یا نہیں۔ وہ جانچیں بعد میں، اسٹریم کے اندر ہوتی ہیں، اور وہ HTTP اسٹیٹس لائن کی بجائے کلائنٹ کے اپنے پیغامات سے ناکام ہوتی ہیں۔ کلائنٹ لاگ میں پہلا OpenVPN واقعہ پراکسی ہینڈ شیک کے بعد دیکھیں، ونڈو بند ہونے سے پہلے کی آخری لائن نہیں۔
پراکسی اسناد اور VPN اسناد اکثر الگ ٹیموں کے پاس الگ شناختیں ہوتی ہیں۔ 407 VPN اکاؤنٹ کا غلط پاس ورڈ نہیں ہے، اور مسترد شدہ سرٹیفکیٹ پراکسی اجازت کا مسئلہ نہیں ہے۔
CONNECT کیا ظاہر نہیں کرتی
واضح CONNECT سرنگ رکاوٹ نہیں ہے۔ پراکسی بائٹس آگے بھیجتی ہے اور VPN کا TLS سیشن ختم نہیں کرتی، اس لیے سرور سرٹیفکیٹ کی کلائنٹ کی تصدیق بامعنی رہتی ہے اور آن رہنی چاہیے۔ پراکسی سے گزرنے کے لیے تصدیق بند کرنا آپ کے مسئلے سے مختلف مسئلہ حل کرتا ہے۔
ایسی الگ ترتیبات بھی ہیں جہاں کوئی ادارہ جان بوجھ کر TLS ختم کر کے معائنہ کرتا ہے۔ انہیں اپنی اعتماد ترتیب اور اپنا پالیسی فیصلہ درکار ہے، اور وہ عام http-proxy لائن جو مانگتی ہے وہ نہیں ہیں۔
TCP کے اندر TCP کی قیمت
سرنگ کو TCP پر اٹھانے سے بیرونی اسٹریم ترتیب میں اور دوبارہ بھیجنے کے ساتھ رہتی ہے، اور اندرونی ٹریفک بھی عموماً TCP ہوتی ہے۔ دونوں بحالی طریقے ہم آہنگ نہیں ہوتے، اس لیے ایک گم شدہ حصہ اس بیرونی اسٹریم کو بانٹنے والی ہر چیز کو دوبارہ بھیجے جانے تک روک سکتا ہے۔ یہ مطابقت کے لیے حقیقی ادل بدل ہے، مفت اپ گریڈ نہیں۔
جب نیٹ ورک کوئی متبادل نہ چھوڑے تو پراکسی راستہ استعمال کریں، اور جہاں پالیسی اجازت دے وہاں براہ راست UDP راستہ ترجیح دیں۔ کسی بھی صورت میں، تبدیلی کے بعد تصدیق کریں کہ وہی پراکسی، منزل اور پروفائل اگلے مرحلے تک پہنچتے ہیں؛ اس پتے پر صفحہ لوڈ کرنے والا براؤزر دوسرا پروٹوکول چلاتا ہے اور سرنگ کے بارے میں کچھ ثابت نہیں کرتا۔