iOS VPN API: NEVPNManager، ٹنل فراہم کنندہ یا پروفائل؟

تین مختلف مصنوعات iOS VPN کے نام سے جواب دیتی ہیں، اور وہ ایک API مشترک نہیں کرتیں۔ Personal VPN نظام کے اندرونی IPsec اور IKEv2 ٹرانسپورٹ پر چلتا ہے۔ Custom tunnel آپ کا اپنا پروٹوکول network extension کے اندر چلاتا ہے۔ Configuration profile ان میں سے کسی ایک کو تشکیل دیتا ہے اور on-demand رویہ شامل کر سکتا ہے۔ جس ٹرانسپورٹ سے آپ کو بات کرنی ہے اس کی بنیاد پر انتخاب کرنا، پہلے کمپائل ہونے والے ٹیوٹوریل کی بنیاد پر انتخاب کرنے سے زیادہ تیز ہے۔

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

مرحلہ 1: ٹرانسپورٹ کی بنیاد پر منتخب کریں

اگر سرور IKEv2 یا Cisco طرز کا IPsec ہے، تو NEVPNManager کافی ہے اور نظام کے ٹرانسپورٹ مفت آتے ہیں۔ اگر سرور OpenVPN، WireGuard یا کچھ اور بولتا ہے، تو NEVPNManager مدد نہیں کر سکتا: اس کے پاس فریق ثالث کے پروٹوکول کے لیے کوئی ہک نہیں۔ اس صورت میں پروٹوکول نافذ کرنے والے packet tunnel provider کے ساتھ NETunnelProviderManager درکار ہے۔ پروفائل صرف تشکیل تقسیم کرتا ہے، اور وہ ایسی ٹرانسپورٹ شامل نہیں کر سکتا جو آپریٹنگ سسٹم کے پاس نہ ہو۔

موجودہ نظاموں پر PPTP ہدف نہیں ہے۔ Shared-secret IPsec اب بھی remoteIdentifier میں گروپ کا نام، راز رکھنے والی keychain شے، اور سرور کے صارف نام مانگنے پر توسیعی تصدیق کی توقع کرتا ہے۔ ہر گمشدہ حصہ اسی عام تشکیل کی غلطی کے طور پر ظاہر ہوتا ہے، اس لیے کچھ اور ڈیبگ کرنے سے پہلے وہ سب شامل کریں۔

مرحلہ 2: محفوظ، لوڈ، آغاز کی ترتیب کا احترام کریں

NEVPNManager preferences میں لکھتا ہے، انہیں واپس پڑھتا ہے، اور پھر ہی شروع کرتا ہے۔ پروٹوکول اور manager اشیاء بھریں، saveToPreferences کال کریں، loadFromPreferences کال کریں، اور load completion handler سے startVPNTunnel کال کریں۔ لوڈ کے واپس آنے سے پہلے آغاز کرنا ورنہ درست تشکیل پر configuration-invalid غلطی، NEVPNErrorDomain code 1، پیدا کرتا ہے۔

شکل ایک ہی جگہ رکھنے کے لیے کافی مختصر ہے:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel درخواست کے قبول ہونے پر واپس آتا ہے، ٹنل کے کھڑے ہونے پر نہیں۔ NEVPNStatusDidChange کا مشاہدہ کریں اور اصل حالت کے لیے connection.status پڑھیں۔ وہ ایپ جو کال کے مقام پر کامیابی فرض کرتی ہے VPN کو منسلک بتاتی ہے جبکہ extension اب بھی بات چیت کر رہا ہوتا ہے۔ Connecting حالت ایک لمحے کے لیے معمول ہے؛ وہ حالت جو کبھی اس سے نہ نکلے وہی لاگ کرنے کے قابل ناکامی ہے۔

مرحلہ 3: provider عمل کو وہ دیں جس کی اسے ضرورت ہے

Custom transport اپنے bundle identifier اور اپنے entitlement کے ساتھ الگ عمل میں چلتا ہے۔ container ایپ اور provider دونوں کو دستخط کے وقت network-extension entitlement درکار ہوتا ہے، اور App Store سے باہر Developer ID build کو بھی اسے provisioning profile میں رکھنا ہوتا ہے۔ گمشدہ entitlement پروٹوکول بگ جیسا لگتا ہے کیونکہ extension شروع ہی نہیں ہوتا۔

مانگنے کے لیے کوئی عوامی socket descriptor نہیں ہے۔ NEPacketTunnelProvider آپ کو read، write اور cancel کے ساتھ NEPacketTunnelFlow دیتا ہے، اور نجی کلید کے راستوں تک پہنچنے والا کوڈ ریلیز کے درمیان ٹوٹ جاتا ہے۔ ایپ کے پس منظر میں ہونے پر بھی provider چلتا رہتا ہے، اس لیے container ایپ کو اس کے لیے پس منظر موڈ کی ضرورت نہیں۔

مرحلہ 4: on-demand قواعد کا مجموعہ ہے، سوئچ نہیں

isOnDemandEnabled صرف قواعد کو تیار کرتا ہے؛ ٹنل کب کھڑا ہوگا یہ NEOnDemandRuleConnect اور اس کے بھائی طے کرتے ہیں۔ probe URL والا evaluate-connection قاعدہ اسی URL جتنا ہی اچھا ہوتا ہے۔ اگر probe ٹنل کے بغیر جواب دے، تو قاعدہ فیصلہ کرتا ہے کہ نجی نیٹ ورک پہلے ہی قابل رسائی ہے اور کبھی منسلک نہیں ہوتا، اس لیے اسے ایسی چیز کی طرف مبذول کریں جو صرف اندر سے جواب دے۔

Always-on ایک الگ وعدہ ہے۔ اس کے لیے زیر نگرانی آلہ اور زیر انتظام پروفائل درکار ہے، اور غیر زیر نگرانی صارف پروفائل کبھی بھی ہٹا سکتا ہے۔ بیڑے کی نگرانی نہ ہو تو always-on پر منحصر ڈیزائن نہ بھیجیں۔

مرحلہ 5: لیبل نہیں، راستہ ثابت کریں

tun، tap، ppp یا ipsec انٹرفیس اسکین کرنا ثابت کرتا ہے کہ VPN تشکیل شدہ ہے، یہ نہیں کہ آپ کی درخواست نے اسے استعمال کیا۔ usesInterfaceType(.other) کے ساتھ NWPathMonitor بتاتا ہے کہ مجازی انٹرفیس دستیاب ہے، اور viability handler ایک ہوسٹ جانچ سکتا ہے۔ دونوں میں سے کوئی بھی خارجی راستہ ثابت نہیں کرتا، اس لیے انہیں اس وسیلے کی درخواست کے ساتھ جوڑیں جہاں صرف ٹنل پہنچ سکتا ہے۔ انٹرفیس کے نام تشخیصی مدد ہیں، کبھی وہ دروازہ نہیں جس پر ایپلیکیشن منطق کو شاخیں بنانی چاہئیں۔

میدانی جانچ کے لیے، عوامی پتہ ٹنل کے ساتھ اور بغیر موازنہ کریں اور صرف داخلی صفحہ لائیں۔ provider کی بات چیت کے دوران status کال منسلک بتا سکتی ہے، اس لیے فیصلہ وسیلے کے نتیجے کو کریں اور status کو معاون ثبوت سمجھیں۔