మీ యాప్ డిస్‌కనెక్ట్ అని చెబుతుంది, మెనూ బార్ కనెక్ట్ అని చెబుతుంది, మరియు ట్రాఫిక్ స్పష్టంగా ప్రవహిస్తోంది. ఆ అంతరం మళ్లీ ప్రయత్నంతో సరిచేయగల పోటీ స్థితి కాదు: యాప్ మరియు టన్నెల్ వేర్వేరు ప్రక్రియలు, మరియు మీ కోడ్ చదివే ఆబ్జెక్ట్ సిస్టమ్ నిల్వ చేసే కాన్ఫిగరేషన్ యొక్క కాష్ చేసిన వీక్షణ. Apple యొక్క Personal VPN ఉపరితలం నియంత్రణ API, డేటా మార్గం కాదు, మరియు దాని వింత ప్రవర్తనలో ఎక్కువ భాగం ఈ ఒక్క వాస్తవం నుండే వస్తుంది. ప్రతి పిలుపు కింద వాస్తవంగా ఏమి జరుగుతుందో ఇక్కడ ఉంది.

మేనేజర్ ఆబ్జెక్ట్ కాష్ చేసిన వీక్షణ, టన్నెల్ కాదు

NETunnelProviderManager సిస్టమ్ యాజమాన్యంలోని ప్రాధాన్యతల నిల్వ నుండి నింపబడుతుంది, కాబట్టి loadFromPreferences పూర్తయ్యే వరకు దాని లక్షణాలకు అర్థం లేదు. అంతకు ముందు connection.status చదివితే మీకు డిఫాల్ట్ విలువ వస్తుంది, అందుకే పునఃప్రారంభం తర్వాత మొదటి స్థితి రిఫ్రెష్ టన్నెల్ నడుస్తున్నప్పటికీ డిస్‌కనెక్ట్ అని నివేదిస్తుంది. మొదట లోడ్ చేయండి, తర్వాత అదే పూర్తి హ్యాండ్లర్ నుండి స్థితి మరియు ప్రోటోకాల్ కాన్ఫిగరేషన్ చదవండి. తర్వాతి మార్పులను పోలింగ్‌కు బదులు NEVPNStatusDidChange ద్వారా గమనించండి, మరియు On Demand ప్రారంభించిన కనెక్షన్లకు కూడా నోటిఫికేషన్ వస్తుందని గమనించండి, అక్కడ ఏదైనా తిరిగి ఇచ్చే యాప్ పిలుపే ఉండదు. ప్రోటోకాల్ సెట్టింగ్‌లకూ ఇదే వర్తిస్తుంది: అవి లోడ్ చేసిన కాన్ఫిగరేషన్ నుండి చదవబడతాయి, యాప్ పంపిన దాని నుండి కాదు.

టన్నెల్ స్వయంగా Network Extension ప్రొవైడర్ ప్రక్రియలో జీవిస్తుంది, కాబట్టి యాప్ కనెక్షన్ కోల్పోకుండా తన స్థితిని కోల్పోవచ్చు. ఇంటర్‌ఫేస్ చూపించే ప్రతిదీ మేనేజర్ నుండి తిరిగి నిర్మించాలి, గత సెషన్ నుండి గుర్తుంచుకోకూడదు.

ప్రారంభ క్రమం: సేవ్ చేయండి, లోడ్ చేయండి, తర్వాత ప్రారంభించండి

ప్రొవైడర్ ఆధారిత కనెక్షన్‌కు క్రమంగా మూడు దశలు అవసరం. ప్రొవైడర్ కాన్ఫిగరేషన్ రాసి saveToPreferences పిలవండి, సేవ్ చేసిన కాన్ఫిగరేషన్ మీ చేతిలో ఉన్నదే అయ్యేలా మేనేజర్ లోడ్ చేయండి, తర్వాత NETunnelProviderSession.startVPNTunnel() ద్వారా ప్రారంభించండి. సేవ్ దాటవేస్తే ప్రారంభానికి ప్రారంభించడానికి ఏమీ ఉండదు; సేవ్‌కు ముందు లోడ్ చేస్తే మేనేజర్ ఇప్పటికీ పాత కాన్ఫిగరేషన్‌నే ప్రతిబింబిస్తుంది.

startVPNTunnel తిరిగి ఇచ్చే బూలియన్ అభ్యర్థన అంగీకరించబడిందని మాత్రమే చెబుతుంది. ప్రొవైడర్ స్థాయి వైఫల్యాలు తర్వాత డిస్‌కనెక్ట్ స్థితికి మార్పుగా వస్తాయి, దాన్ని మీరు NEVPNStatusDidChange నోటిఫికేషన్ ద్వారా గమనిస్తారు, మరియు నోటిఫికేషన్ హ్యాండ్లర్ loadFromPreferences తర్వాత connection.status తిరిగి చదవాలి ఎందుకంటే కాష్ చేసిన విలువ ఇంకా పాతదే ఉండవచ్చు. అభ్యర్థన స్థాయి వైఫల్యాలు పిలుపు యొక్క మినహాయింపు విసిరే రూపం నుండి వెంటనే తిరిగి వస్తాయి, లేదా startVPNTunnelAndReturnError: యొక్క లోపం అవుట్-పరామితి ద్వారా. తిరిగి వచ్చిన విలువను ఫలితంగా భావించే కోడ్ ఎప్పుడూ ఏర్పడని కనెక్షన్‌ను నివేదిస్తుంది. మరో నిశ్శబ్ద వైఫల్యం ఏమిటంటే ఇన్‌స్టాల్ చేసిన పొడిగింపుతో సరిపోలని ప్రొవైడర్ బండిల్ ఐడెంటిఫైయర్: అభ్యర్థన తిరస్కరించబడుతుంది, మరియు సందేశంలో ఏదీ ఐడెంటిఫైయర్‌ను సూచించదు. ఐడెంటిఫైయర్ తప్పుగా ఉంటే అభ్యర్థన సాధారణంగా వెంటనే విఫలమవుతుంది, ప్రొవైడర్ యొక్క ఒక లాగ్ లైన్ కూడా రాకముందే.

ప్రారంభం తర్వాత ప్రాధాన్యతలను మళ్లీ లోడ్ చేయడమే స్థితి స్క్రీన్‌లను సరైనవిగా చేస్తుంది. సిస్టమ్ కాన్ఫిగరేషన్‌ను మార్చినప్పుడు మేనేజర్ మీ వైపు కొత్త కాన్ఫిగరేషన్‌ను నెట్టదు.

నమ్మక పదార్థం ప్రొఫైల్ ద్వారా వస్తుంది, ఎప్పుడూ యాప్ కోడ్ నుండి కాదు

iOS నమ్మక నిల్వకు మూల ధృవపత్రాన్ని జోడించడానికి యాప్‌కు ఏ మద్దతు మార్గమూ లేదు, కాబట్టి Personal VPN కాన్ఫిగరేషన్ పరికరం ఇప్పటికే నమ్మే పదార్థాన్ని మాత్రమే సూచించగలదు: ఇన్‌స్టాల్ చేసిన ప్రొఫైల్, పరికర నిర్వహణ లేదా సిస్టమ్ ఇతర కారణాల వల్ల నమ్మే CA ఏర్పాటు చేసిన గొలుసు. మొదటి అమలులో తన సొంత CAని సృష్టించి సిస్టమ్ దాన్ని గుర్తిస్తుందని ఆశించే యాప్ ప్రొవైడర్ లోపలి ధ్రువీకరణలో విఫలమవుతుంది, అక్కడ యాప్ ఇంటర్‌ఫేస్ కారణాన్ని చూడలేదు.

ఆ హద్దును అది ఉన్నట్టుగానే డిజైన్ పరిమితిగా పరిగణించి, నమోదు ప్రొఫైల్‌తో పాటు నమ్మక యాంకర్‌ను పంపండి. VPN ప్రామాణీకరణను నమ్మక నిర్ణయం నుండి వేరుగా ఉంచండి, ఎందుకంటే అవి వేర్వేరు చోట్ల విఫలమవుతాయి, వేర్వేరు మనుషులు వాటిని డీబగ్ చేస్తారు.

కౌంటర్‌లు ఇంటర్‌ఫేస్ నుండి వస్తాయి, VPN API నుండి కాదు

మేనేజర్ స్థితి మరియు కాన్ఫిగరేషన్‌ను బయటపెడుతుంది, ప్రతి టన్నెల్‌కు బైట్లను లెక్కించేది ఏదీ లేదు. మీకు వినియోగ సంఖ్యలు కావాలంటే getifaddrs() పిలిచి సంబంధిత ఇంటర్‌ఫేస్ కోసం if_data చదవండి: Wi-Fi కోసం en0, సెల్యులార్ కోసం pdp_ip ఇంటర్‌ఫేస్‌లు, టన్నెల్ కోసం utun పరికరం. utun కౌంటర్‌లు అంతర్గత ట్రాఫిక్‌ను వివరిస్తాయి, ప్రోటోకాల్ ఓవర్‌హెడ్‌ను కూడా కలిగి ఉంటాయి.

ఈ సంఖ్యలు అంచనాలు, యాప్ వారీగా లెక్కింపు కాదు, మరియు ఇంటర్‌ఫేస్ మళ్లీ సృష్టించబడినప్పుడు అవి రీసెట్ అవుతాయి. ఇంటర్‌ఫేస్‌లో వాటిని అలాగే లేబుల్ చేయండి, లేకపోతే ఎవరో వాటిని కస్టమర్‌కు బిల్ చేయడానికి ఉపయోగిస్తారు. మీకు యాప్ వారీగా సంఖ్యలు కావాలంటే పూర్తిగా వేరే యంత్రాంగం కావాలి, ఈ ఫీల్డ్‌ల మెరుగైన పఠనం కాదు.

శుభ్రత stopVPNTunnel లో ఉంది, ముగింపులో కాదు

applicationWillTerminate సిస్టమ్ ప్రక్రియను చంపగలిగే ముందు మీకు కొన్ని సెకన్లు ఇస్తుంది, అది కనెక్షన్‌ను విడదీయడానికి నమ్మదగిన స్థలం కాదు. ఆపుడు stopVPNTunnel() కు పంపండి లేదా ప్రొవైడర్ ఆపు కాల్‌బ్యాక్‌లో నిర్వహించండి, మరియు మీరు ప్రారంభించిన మేనేజర్ లేదా కాన్ఫిగరేషన్ ఐడెంటిఫైయర్‌ను ఉంచండి, తద్వారా ఆపుడు పరికరంలోని ప్రతి కాన్ఫిగరేషన్‌ను కాకుండా ఆ కనెక్షన్‌ను లక్ష్యంగా చేసుకుంటుంది.

ఆ ఐడెంటిఫైయర్‌ను అది చెందిన ప్రొఫైల్ పక్కన నిల్వ చేయండి, ఎందుకంటే మేనేజర్ ఆబ్జెక్ట్ వినియోగదారు ఏ కాన్ఫిగరేషన్ ఎంచుకున్నారో నమోదు చేయదు. మరియు On Demand ఎత్తే కనెక్షన్ వెనుక ఎలాంటి యాప్ పిలుపూ ఉండదని గుర్తుంచుకోండి, కాబట్టి స్థితి స్క్రీన్ ఏదైనా గీయడానికి ముందు ఇంకా ప్రాధాన్యతలను లోడ్ చేయాలి.

సంబంధిత వ్యాసాలు