Apple VPN پروفائل میں Proxy فیلڈ دراصل کیا کرتی ہے
پروکسی فیلڈ بھرنے سے VPN، HTTP نہیں بن جاتا۔ یہاں دو کنکشن شامل ہیں، اور فیلڈ صرف ایک تک پہنچتی ہے۔
Apple VPN کنفیگریشن میں Proxy فیلڈ بھرنے سے لگتا ہے کہ یہ ٹنل کو ویب پورٹ سے گزرے گا۔ لیکن ایسا نہیں کرتا۔ فیلڈ اُس ٹریفک کے لیے ایپلیکیشن سطح کا واسطہ چنتی ہے جو کوئی موزوں ایپ وہاں بھیجنے کا فیصلہ کرتی ہے۔ البتہ VPN کلائنٹ کا اپنے گیٹ وے سے کنکشن اُس پروٹوکول، سننے والے اور ٹرانسپورٹ سے طے ہوتا ہے جو آپ نے ترتیب دیا، اور یہ الگ فیصلے ہیں۔
دو کنکشن، دو مالک
ایسی کوئی بھی ترتیب کلائنٹ سے گیٹ وے تک کنکشن اور ایپ سے منزل تک کنکشن رکھتی ہے۔ Proxy کا حصہ دوسرے کے بارے میں بولتا ہے، اگرچہ وہ پہلے والے ہی پروفائل میں ہے۔
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Apple کا پراکسی سیٹنگز کا حوالہ HTTP، HTTPS، SOCKS اور خودکار پراکسی کنفیگریشن کی فہرست دیتا ہے، جو ایپس کے پراکسی انتخاب کی وضاحت ہے۔ اِن اندراجات میں سے کوئی یہ نہیں کہتا کہ IPsec یا WireGuard پیکٹ گیٹ وے تک کیسے پہنچتا ہے۔
یہ معاملہ طے کرنے والا ایک فوری جائزہ یہ ہے۔ وہ پورٹ اور پروٹوکول بتائیں جو VPN کلائنٹ اپنے لاگ میں بتاتا ہے۔ اگر وہ سطر اب بھی UDP 500 یا UDP 51820 کہتی ہے تو پراکسی فیلڈ نے اُس میں کچھ نہیں بدلا۔
فیلڈ کب درست اوزار ہے
ایک حقیقی صورت ہے جہاں پراکسی ٹنل کے سامنے ہوتی ہے، مگر یہ پروفائل فیلڈ نہیں، کلائنٹ کی خصوصیت ہے. OpenVPN کا دستور HTTP CONNECT پراکسی کے ذریعے لے جانے والے TCP کنکشنز کے لیے --http-proxy درج کرتا ہے۔ اِسے استعمال کرنے کے لیے متعلقہ کلائنٹ آپشن، اُس راستے سے قابلِ رسائی گیٹ وے اور ایسی پراکسی درکار ہے جو زیرِ استعمال پورٹ تک CONNECT کی اجازت دے۔
اگر آپ کا کلائنٹ یہ آپشن دیتا ہے اور نیٹ ورک پورٹ تک CONNECT کی اجازت دیتا ہے تو یہ کام کر سکتا ہے۔ اگر کلائنٹ یہ نہیں دیتا تو سسٹم پراکسی بھرنے کا ٹنل پر کوئی اثر نہیں ہوتا۔
کب کچھ نہیں بدلتا
پراکسی فیلڈ بھری ہونے سے IKEv2 یا IPsec پروفائل HTTP ٹنل نہیں بن جاتا۔ WireGuard بھی نہیں، جس کی کنفیگریشن شکل میں پراکسی کا تصور نہیں۔ گیٹ وے پورٹ بدلنے سے اُس کا پروٹوکول بھی نہیں بدلتا۔ اور عام HTTPS کا جواب دینے والا اینڈ پوائنٹ خودبخود VPN سننے والا نہیں ہوتا۔
یہی جال اُن لوگوں کو بھی پکڑتا ہے جو پرانے iPad گائیڈز سے PPTP دور کے پروفائل کاپی کرتے ہیں۔ آپشنز اب بھی انٹرفیس میں موجود ہیں؛ اُن کے پیچھے کی سروس اب وہ پروٹوکول نہیں بولتی۔
طے کرنا کہ کون سی تہہ درست کرنی ہے
کچھ بھی بدلنے سے پہلے پوچھیں کہ کون سی تہہ ناکام ہوئی۔ اگر کلائنٹ سیشن قائم نہیں کر سکتا تو مسئلہ ٹرانسپورٹ میں ہے اور پراکسی فیلڈ غیر متعلق ہے۔ اگر ٹنل چل رہا ہے مگر ایک ایپ اپنے سرور تک نہیں پہنچتی تو ایپلیکیشن پراکسی دیکھنی چاہیے۔ اگر ٹنل چل رہا ہے اور سب ایپس ناکام ہوں تو ٹنل کے اندر روٹنگ اور DNS مشتبہ ہیں۔
پہلی صورت کے لیے آپریٹر سے پوچھیں کہ وہ کون سی منظور شدہ متبادل ٹرانسپورٹ یا نیٹ ورک کی حمایت کرتا ہے۔ TCP 443 پر OpenVPN اِس لیے موجود ہے کہ کچھ نیٹ ورک صرف اِسی کی اجازت دیتے ہیں، اور اُسے اب بھی سرور کا اُسے سننا درکار ہے۔
بند UDP پورٹ کو فوری حل کی اجازت نہ سمجھیں۔ ہینڈ شیک کے موافق ہونے کے لیے گیٹ وے کے تصدیق نامے یا شناخت کی جانچچ بند کرنے کے بجائے اُنہیں برقرار رکھیں۔
دونوں تہوں کی ایک ایک کر کے تصدیق کریں
پہلے ٹنل کی تصدیق کریں: کلائنٹ کے اسٹیٹس صفحے پر قائم سیشن اور صفر سے مختلف بائٹ گنتی دیکھیں۔ پھر پراکسی سیٹنگ براہِ راست پڑھیں, مؤثر کنفیگریشن کے لیے scutil --proxy یا محفوظ قدر کے لیے networksetup -getwebproxy Wi-Fi استعمال کرتے ہوئے۔ پھر ایک ایپ آزمائیں جو سسٹم پراکسی کا احترام کرتی ہے اور ایک جو اُسے نظر انداز کرتی ہے، کیونکہ بہت سی مقامی ایپس اُسے نظر انداز کرتی ہیں۔
تین نتائج، تین مختلف اصلاحات۔
اگر دونوں تہیں کامیابی بتائیں اور ایپ پھر بھی ناکام ہو تو تقسیم شدہ ٹنل، DNS اور ایپ کی اپنی نیٹ ورک سیٹنگز دیکھیں۔ یہ تیسری تہہ ہے، اور وہ بھی پراکسی فیلڈ نہیں۔