VPN بمقابلہ پراکسی: ہر ایک کیا ڈھکتا ہے اور کیا نہیں
VPN روٹ کی گئی ایپ ٹریفک کو ڈھکتا ہے؛ پراکسی صرف وہی ایپ ڈھکتی ہے جو آپ ترتیب دیتے ہیں۔ انتخاب سے پہلے کوریج، انکرپشن، DNS اور ناکامی کا رویہ جانچیں۔
VPN اور فارورڈ پراکسی دونوں وہ پتہ بدلتے ہیں جو ویب سائٹ دیکھتی ہے، اور زیادہ تر موازنے وہیں رک جاتے ہیں۔ آپ کا سیٹ اپ طے کرنے والا فرق کوریج ہے: فارورڈ پراکسی ایسا واسطہ ہے جسے آپ کی ایپ خود استعمال کرنے کا انتخاب کرتی ہے، ویب سائٹ کے سامنے کھڑی ریورس پراکسی کے برعکس، جبکہ VPN وہ سب کچھ منتقل کرتا ہے جو آپریٹنگ سسٹم کسی ٹنل میں روٹ کرتا ہے۔ انکرپشن، DNS کی دیکھ بھال اور ناکامی کا رویہ سب اسی تقسیم سے آتے ہیں۔ یہ پانچ جانچیں ترتیب سے کریں، اور پہلی جو ناکام ہو وہی بتائے گی کہ آپ کو واقعی کون سا آلہ چاہیے۔
واسطہ کن ایپس کو ڈھکتا ہے؟
براؤزر میں پراکسی ایکسٹینشن صرف اسی براؤزر پروفائل پر لاگو ہوتی ہے۔ میل کلائنٹ، پیکج مینیجر اور دوسرا براؤزر اپنی ہی ترتیبات استعمال کرتے رہتے ہیں، اور کچھ ایپس سسٹم پراکسی متغیرات کو بالکل نظرانداز کر دیتی ہیں۔ VPN وہ ڈھکتا ہے جو روٹنگ ٹیبل ٹنل میں بھیجتی ہے، اور یہ راستوں اور کلائنٹ پالیسی کے مطابق تمام ایپس یا اسپلٹ ٹنل میں کوئی ذیلی مجموعہ ہو سکتا ہے۔
ایک صفحے کے لوڈ سے اندازہ لگانے کے بجائے اہم ایپس کی جانچ کریں۔ curl https://ifconfig.me ماحول کے پراکسی متغیرات کی پیروی کرتا ہے؛ ڈیسک ٹاپ ایپ شاید نہ کرے۔ Windows پر netsh winhttp show proxy وہ WinHTTP پراکسی چھاپتا ہے جو سروسز استعمال کرتی ہیں، اور یہ براؤزر کی ترتیب سے الگ ترتیب ہے۔
کیا ہاپ انکرپٹڈ ہے، اور TLS کہاں ختم ہوتا ہے؟
پراکسی پروٹوکول ملنے کی جگہ ہے، ضمانت نہیں۔ SOCKS5 TCP کو انکرپٹ کیے بغیر آگے بھیجتا ہے، اور سادہ HTTP پراکسی درخواست کی سطر اور ہیڈر صاف متن میں لے جاتی ہے۔ پراکسی کے ذریعے HTTPS CONNECT استعمال کرتا ہے، اس لیے آپ کا TLS سیشن پراکسی پر نہیں، منزل پر ہی ختم ہوتا ہے۔ پراکسی سرورز اور ٹنلنگ کے بارے میں MDN گائیڈ یہ فرق پروٹوکول کی طرف سے بیان کرتی ہے۔
VPN آپ کے ڈیوائس اور اس کے اینڈ پوائنٹ کے درمیان حصے کو انکرپٹ کرتا ہے۔ اینڈ پوائنٹ سے آگے کسی بھی دوسرے نیٹ ورک کی طرح وہی اصول لاگو ہوتے ہیں، اسی لیے صرف ٹنل سادہ HTTP پر اسناد بھیجنے والی ایپ کی حفاظت نہیں کرتا۔ دونوں میں سے کوئی ڈیزائن لاگ ان شدہ اکاؤنٹ، کوکی یا براؤزر فنگر پرنٹ نہیں چھپاتا۔
curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/nullتفصیلی آؤٹ پٹ دکھاتا ہے کہ curl نے پورٹ 443 پر CONNECT بھیجا یا مکمل URL کے ساتھ سادہ GET۔ socks5h:// کے ساتھ ہوسٹ نام SOCKS5 درخواست کے اندر پراکسی کو دیا جاتا ہے اور پھر وہ وہ TLS آگے بھیجتی ہے جسے وہ پڑھ نہیں سکتی، اس لیے وہ نام اور بائٹ کی گنتی دیکھتی ہے۔ http:// پراکسی کے ذریعے https:// URL ایک CONNECT ہے، اس لیے وہ پراکسی بھی منزل کا نام اور حجم دیکھتی ہے، درخواست یا جواب کا اصل حصہ نہیں۔
کون سا حل کنندہ نام دیکھتا ہے؟
ناموں کا حل درخواست نکلنے سے پہلے مقامی طور پر ہو سکتا ہے، یا پراکسی پر دور سے۔ curl کے ساتھ socks5h:// ہوسٹ نام پراکسی کو بھیجتا ہے جبکہ socks5:// پہلے اسے مقامی طور پر حل کرتا ہے۔ براؤزر کی پراکسی ترتیبات موازنے کے قابل DNS آپشن دیتی ہیں، اور PAC فائلیں مختلف ہوسٹس کو مختلف طریقوں سے روٹ کر سکتی ہیں۔
دو پروٹوکول کسی بھی غلط ترتیب کے بغیر پراکسی سے بچ سکتے ہیں۔ WebRTC STUN کے ذریعے امیدوار جمع کرتا ہے، اور QUIC UDP پر HTTP/3 چلاتا ہے، جسے TCP پراکسی لے نہیں سکتی۔ UDP 443 بلاک ہو تو براؤزر TCP پر واپس آ جائے گا، اس لیے ہوسٹ کے فائر وال پر (یا پورے نیٹ ورک کے لیے راؤٹر پر) UDP 443 بلاک کرنا، براؤزر کا جھنڈا نہیں، HTTP/3 کو پراکسی راستے میں رکھنے کا قابل اعتماد طریقہ ہے۔
حل کنندہ کو اپنے لیپ ٹاپ کی نظر سے نہیں، منزل کی نظر سے جانچیں۔ جو درخواست پراکسی کے اخراجی پتے کے ساتھ مگر مقامی طور پر حل شدہ نام کے ساتھ آتی ہے وہ مقامی حل کنندہ کو پھر بھی بتاتی ہے کہ آپ کون سی سائٹیں دیکھتے ہیں۔
واسطہ ناکام ہونے پر کیا ہوتا ہے؟
واضح پراکسی بند شکل میں ناکام ہوتی ہے: پراکسی عمل روکیں اور براؤزر یا ایپ سیدھا جانے کے بجائے کنکشن کی غلطی لوٹاتی ہے۔ PAC اور WPAD ترتیبات وہ ہیں جو کھلی شکل میں ناکام ہوتی ہیں - اگر اسکرپٹ نہ مل سکے تو کلائنٹ DIRECT پر واپس آ جاتا ہے اور سائٹ پھر آپ کا اصل پتہ دیکھتی ہے۔ VPN کلائنٹ اور اس بات پر منحصر ہو کر کہ کِل سوئچ یا فائر وال اصول فعال ہے، کھلی یا بند شکل میں ناکام ہو سکتا ہے۔
ناکامی کی صورت جان بوجھ کر جانچیں: پراکسی سروس روک کر دوبارہ لوڈ کریں؛ سیدھے لوڈ کے بجائے غلطی کا صفحہ ملے تو فال بیک دیکھنے کے لیے PAC URL کو ناقابل رسائی ہوسٹ کی طرف دکھائیں۔ اگر صفحہ اب بھی آپ کے معمول کے راستے سے لوڈ ہوتا ہے تو پراکسی اپنی ہی رکاوٹ کے خلاف کوئی تحفظ نہیں دیتی، اور یہ وہ خصوصیت ہے جو اس پر بھروسا کرنے سے پہلے جاننی چاہیے۔
ترتیب طے کرتی ہے کہ سائٹ کیا دیکھتی ہے۔ جس پراکسی کا اخراجی ٹریفک VPN سے گزرتا ہے وہ سائٹ کو VPN اینڈ پوائنٹ کا پتہ دکھاتی ہے؛ پراکسی کو ٹنل سے باہر رکھیں (دور دراز ہوسٹ پر پراکسی کی طرف VPN) اور سائٹ اس کے بجائے اس پراکسی کا اخراجی پتہ دیکھتی ہے۔ بہرحال دونوں ہاپ مختلف چیزیں ریکارڈ کر سکتے ہیں۔
پانچ جانچیں، ترتیب سے
نیچے دی گئی چیک لسٹ پورا فیصلہ ایک جگہ ہے۔ کوریج پہلے آتی ہے کیونکہ یہ زیادہ تر عدم مطابقت دور کرتی ہے: اگر جس ایپ کو ڈھکنا ہے وہ ترتیب کا احترام نہیں کرتی، تو فہرست میں آگے کچھ بھی اسے نہیں بچاتا۔
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
پھر نتیجے کی تصدیق اسی ایپ سے کریں جس نے تبدیلی پیدا کی۔ ترتیب دیے گئے براؤزر میں صفحہ لوڈ کریں، وہی صفحہ curl سے حاصل کریں، اور دونوں کے بتائے پتے کا موازنہ کریں۔ اگر وہ مختلف ہیں تو کوئی ایکسٹینشن، PAC اصول یا ایپ سطح کی اوور رائیڈ اب بھی کام کر رہی ہے، اور ٹنل کی کوئی بھی ٹیوننگ اسے درست نہیں کرے گی۔
جو آپ نے ترتیب دیا اسے لکھ لیں: کون سی ایپس پراکسی استعمال کرتی ہیں، DNS مقامی ہے یا دور دراز، UDP بلاک ہے یا نہیں، اور ناکامی کا رویہ کیا ہے۔ یہی چھوٹی فہرست اگلا موازنہ ممکن بناتی ہے، کیونکہ ”IP بدل گیا“ نے کبھی نہیں بتایا کہ ان پانچ جانچوں میں سے کون سی پاس ہوئی۔