ایک عوامی پراکسی VPN کے ذریعے نجی اصل تک کیسے پہنچتی ہے

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

دو ماڈل جو ایک خاکے پر ایک جیسے دکھتے ہیں

کچھ بھی منتخب کرنے سے پہلے تیر کھینچیں۔ عوامی اشاعت کا ماڈل براؤزر سے پراکسی تک HTTPS پر جاتا ہے، پھر پراکسی سے اصل تک ٹنل کے ذریعے جاتا ہے، اور اصل انٹرنیٹ سے کبھی کنکشن قبول نہیں کرتا۔ صرف-VPN ماڈل کلائنٹ سے گیٹ وے تک جاتا ہے، اور ایپلیکیشن صرف اسی راستے کے اندر سے قابل رسائی ہے۔ صارف کا لیپ ٹاپ ایپلیکیشن کے ساتھ اسی نیٹ ورک پر بیٹھا ہے، اور یہی اس ماڈل کا پورا مقصد ہے۔

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

TLS کہاں رکتی ہے، اور یہ واقعی کیا ثابت کرتی ہے

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

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

فارورڈ شدہ ہیڈر پر صرف پراکسی سے بھروسا کریں

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

اصل کو بالکل ایک ہی جگہ سے قابل رسائی رکھیں

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

ss -ltnp | grep -E ':(80|443)'

انتظامی انٹرفیس کے لیے بھی وہی جائزہ لیں، کیونکہ حادثاتی بے نقابی عام طور پر وہیں ہوتی ہے۔ پھر دونوں ماڈل الگ الگ لکھیں: پراکسی کے ذریعے عوامی سائٹ، اور انتظامی انٹرفیس جو صرف ٹنل کے ذریعے قابل رسائی ہے۔ یہ جملہ کہ سرور VPN کے پیچھے ہے ان میں سے کچھ نہیں کہتا۔