HTTP پراکسی، SSH ٹنل یا VPN: درست پرت منتخب کریں

تین انجینئروں سے پوچھیں کہ اندرونی سروس تک کیسے پہنچا جائے تو آپ کو تین ڈیزائن ملیں گے: ایک ویب پراکسی، ایک SSH ٹنل یا مکمل VPN۔ تینوں دور دراز سروس کو قابل رسائی بنا سکتے ہیں، اور تینوں ٹریفک کو ایسا دکھا سکتے ہیں جیسے وہ کہیں اور سے آ رہا ہو۔ فرق بعد میں ظاہر ہوتا ہے، جب استعمال ہونے والا پروٹوکول وہ نہ ہو جو منتخب ٹول فرض کرتا ہے۔ وہ ڈیزائن جو براؤزر میں فوری جانچ پاس کر جاتا ہے، اکثر اسی ایپلیکیشن میں ناکام ہوتا ہے جس نے درخواست کی وجہ بنی۔

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

پراکسی صرف وہی منتقل کرتی ہے جو وہ سمجھتی ہے

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

SSH ڈائنامک فارورڈنگ ایک مقامی پورٹ کھولتی ہے جو SOCKS بولتی ہے، اور وہ پورٹ TCP اسٹریم کو کسی بھی منزل تک پہنچاتی ہے جس کا کلائنٹ نام لے۔ TCP پر بنے پروٹوکول عام طور پر اس کے ذریعے کام کرتے ہیں۔ UDP نہیں کرتا، جب تک کوئی ٹول واضح طور پر معاونت نہ شامل کرے۔ مقامی فارورڈنگ اس سے بھی تنگ ہے: ایک مقامی پورٹ ایک مقررہ ہوسٹ اور پورٹ پر نقش ہے، جو صرف ایک معلوم سروس کی خدمت کرتا ہے اور اس سے زیادہ کچھ نہیں۔

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN پیکٹ منتقل کرتا ہے۔ کلائنٹ جو کچھ ٹنل میں روٹ کرتا ہے وہ سب اس سے گزرتا ہے، بشمول UDP اور ICMP، اسی لیے یہ نیٹ ورک کی ضرورت کے لیے موزوں ہے، کسی ایک کنکشن کے لیے نہیں۔

کسی کو نام حل کرنا ہوگا

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

curl تقسیم کو واضح دکھاتا ہے: ایک فلیگ ہوسٹ نام پراکسی کو دیتا ہے، دوسرا اسے پہلے مقامی طور پر حل کرتا ہے۔ مقامی حل کے ساتھ اندرونی نام کسی ٹنل کو چھونے سے پہلے ہی ناکام ہو جاتا ہے، اور خرابی پراکسی کو اس بات کا ذمہ دار ٹھہراتی ہے جو درحقیقت DNS کا فیصلہ تھا۔

VPN تیسرا راستہ اختیار کرتا ہے: نجی حل کنندہ اور تلاش ڈومین کو راستوں کے ساتھ نصب کر کے۔ یہ سہولت ہے، اور ایک مانوس فریب پیدا کرتی ہے: ایسا راستہ جو موجود ہو مگر حل کنندہ جواب نہ دے، بالکل مردہ ٹنل جیسا لگتا ہے، حالانکہ پیکٹ دوسری طرف پہنچ رہے ہوتے ہیں۔

جب نیٹ ورک صرف ایک نکلنے کی اجازت دے

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

TCP پر بنی ٹنلیں اس پابندی سے بچ جاتی ہیں، اور UDP پر مبنی VPN نہیں بچتا، جو بہت سی ایسی ترتیبات کی وضاحت کرتا ہے جو گھر میں کام کرتی ہیں اور دفتر میں ناکام ہوتی ہیں۔ دوسری قیمت نظرانداز کرنا آسان ہے: پراکسی شدہ TCP کنکشن کے اندر لے جایا جانے والا TCP ٹنل اب دوبارہ بھیجنے والی دو تہوں کا حامل ہے، اور نقصان کے تحت وہ جوڑا ایسے رک جاتا ہے جیسے کوئی تہہ اکیلے نہیں کرتی۔

درمیانی افراد کو زنجیر بنانا پرت منتخب کرنے سے الگ سوال ہے۔ دوسری پراکسی یا Tor شامل کرنا بدلتا ہے کہ کون کیا مشاہدہ کرتا ہے، اور زنجیر میں مقام طے کرتا ہے کہ کون سی چھلانگ خفیہ متن دیکھتی ہے۔

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

جعل شدہ پتہ کوئی آپشن نہیں

کسی اور کے ماخذ پتے کے ساتھ پیکٹ بنانا کوئی مفید چیز حاصل نہیں کرتا: جواب اصل مالک کو جاتے ہیں، اور زیادہ تر نیٹ ورک ٹریفک کو فوراً ضائع کر دیتے ہیں۔ درمیانی فرد اسی لیے ضروری ہے کہ ماخذ ایجاد نہیں کیا جا سکتا، اور یہی تینوں ڈیزائنوں کا ایماندار جواز ہے۔

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

پروٹوکولز اور ناموں سے فیصلہ کریں

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

پھر اصل کلائنٹ اور اصل نام کے ساتھ تصدیق کریں۔ پراکسی کے ذریعے صفحہ لوڈ کرنا آپ کو UDP کے بارے میں کچھ نہیں سکھاتا، اور ایک ٹول کو SOCKS پر چلانا نظام کے حل کنندہ کے بارے میں کچھ نہیں سکھاتا۔ پڑھیں کہ پروسیس نے کون سا مقامی پتہ باندھا اور کس حل کنندہ نے جواب دیا۔ یہی فرق ہے ایک کام کرنے والے راستے اور ایسے راستے میں جو ایک بار اتفاقاً کام کر گیا۔