iOS VPN API: NEVPNManager, టన్నెల్ ప్రదాతా లేదా profile?

మూడు వేర్వేరు ఉత్పత్తులు 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 అవసరం. Profile కాన్ఫిగరేషన్ను మాత్రమే పంపిణీ చేస్తుంది, ఆపరేటింగ్ సిస్టమ్కు లేని రవాణాను అది జోడించలేదు.

ప్రస్తుత సిస్టమ్లలో 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 చదవండి. కాల్ స్థలంలో విజయాన్ని ఊహించే యాప్ extension ఇంకా చర్చలు జరుపుతున్నప్పుడే VPN కనెక్ట్ అయినట్లు నివేదిస్తుంది. 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 వేరే హామీ. దానికి పర్యవేక్షించబడిన పరికరం మరియు నిర్వహించబడే profile కావాలి, పర్యవేక్షణ లేని వినియోగదారు ఎప్పుడైనా profile తీసివేయగలడు. సమూహం పర్యవేక్షణలో లేకపోతే always-on పై ఆధారపడిన డిజైన్ను పంపవద్దు.

దశ 5: లేబుల్ కాదు, మార్గాన్ని నిరూపించండి

tun, tap, ppp లేదా ipsec ఇంటర్ఫేస్లను స్కాన్ చేయడం VPN కాన్ఫిగర్ అయిందని నిరూపిస్తుంది, మీ అభ్యర్థన దాన్ని ఉపయోగించిందని కాదు. usesInterfaceType(.other) తో NWPathMonitor వర్చువల్ ఇంటర్ఫేస్ అందుబాటులో ఉందని చెబుతుంది, మరియు viability handler ఒక హోస్ట్ను పరీక్షించగలదు. రెండూ నిష్క్రమణ మార్గాన్ని నిరూపించవు, కాబట్టి టన్నెల్ మాత్రమే చేరుకోగల వనరుకు అభ్యర్థనతో వాటిని కలపండి. ఇంటర్ఫేస్ పేర్లు నిర్ధారణ సహాయకం, యాప్ లాజిక్ శాఖలు విడగొట్టాల్సిన ద్వారం ఎప్పటికీ కాదు.

క్షేత్ర తనిఖీ కోసం, పబ్లిక్ చిరునామాను టన్నెల్తో మరియు లేకుండా పోల్చి అంతర్గత-మాత్రమే పేజీని తీసుకురండి. provider చర్చలు జరుపుతున్నప్పుడు status కాల్ కనెక్ట్ అయినట్లు నివేదించవచ్చు, కాబట్టి నిర్ణయం వనరు ఫలితమే తీసుకోనివ్వండి, status ను సహాయక సాక్ష్యంగా పరిగణించండి.