Android VpnService గురించి నాలుగు ఊహలు ఒకసారి నా వారంలో ఎక్కువ భాగాన్ని తీసుకున్నాయి, వాటిలో ఒక్కటి కూడా నెట్వర్క్ ప్రోటోకాల్ గురించి కాదు. యాప్ కనెక్ట్ అయిందని చెప్పింది, కీ చిహ్నం స్టేటస్ బార్లో కూర్చుంది, మరియు ట్రాఫిక్ ఇప్పటికీ సాధారణ మార్గం ద్వారానే బయటకు వెళ్తోంది. సొరంగాన్ని నేను ఆపే వరకు అది నాదేనని, నేను జోడించిన మార్గాలే నాకు లభించే మార్గాలని, మరియు stopSelf పిలిస్తే ఇంటర్ఫేస్ కూడా దానితో పాటు కిందకు దిగుతుందని నేను ఊహిస్తూనే ఉన్నాను. సేవ డాక్యుమెంట్ చేసినట్లుగానే ప్రవర్తిస్తోంది. విరిగిన భాగం నా మానసిక నమూనా.

అపోహ 1: మీరు ఆపే వరకు సొరంగం నిలబడి ఉంటుంది

Android ఒకేసారి ఒక VPN ఇంటర్ఫేస్ను ఉంచుతుంది. రెండవది ఏర్పాటు చేయండి మరియు ప్లాట్ఫారమ్ దాన్ని క్యూలో పెట్టదు: మీదాన్ని నిష్క్రియం చేసి మీ సేవకు onRevoke() పిలుపును పంపుతుంది. మీ కోడ్ బటన్ నొక్కినప్పుడు మాత్రమే అన్నీ విరిగితే, ఒక స్వాధీనం వెనుక ఒక డెస్క్రిప్టర్ మరియు ఒక రీడర్ థ్రెడ్ను వదిలివేస్తుంది, తదుపరి ప్రారంభం రెండింటినీ వారసత్వంగా పొందుతుంది.

VpnService సూచన స్పష్టంగా చెబుతుంది, యాప్కు ఇప్పటికే అంగీకారం ఉంటే prepare() null తిరిగి ఇస్తుంది, వినియోగదారు ఇంకా ఆమోదించాల్సి ఉంటే Intent ఇస్తుంది. ఆ అంగీకారం మీరు ఉద్దేశాన్ని startActivityForResult() ద్వారా అందించినప్పుడే వస్తుంది. ఈ అప్పగింతను దాటవేస్తే establish() null ఇస్తుంది, ఇది అనుమతి సమస్యగా కాకుండా నిశ్శబ్ద వైఫల్యంగా చదవబడుతుంది.

Always-on VPN మీరు నియంత్రించని యజమానిని జోడిస్తుంది. సిస్టమ్ బూట్ తర్వాత లేదా క్రాష్ తర్వాత సొరంగాన్ని తిరిగి తీసుకురాగలదు, మరియు వినియోగదారు చేతితో ప్రారంభించిన VPN యాప్ను దానికి ముందుగా జరుపుతుంది. onRevoke() మీ సాధారణ మూసివేత మాదిరిగా అదే వనరులను మూసివేసేలా నిర్మించండి, మరియు దాన్ని మూల కేసుగా కాకుండా ప్రధాన ఆపే మార్గంగా పరిగణించండి. వినియోగదారులు VPN యాప్లను మారుస్తారు; మీ కోడ్ దాన్ని తట్టుకోవాలి.

అపోహ 2: addRoute మీరు జాబితా చేసినదాన్ని సరిగ్గా పట్టుకుంటుంది

ఏ ప్యాకెట్లు మీ డెస్క్రిప్టర్ను చేరుతాయో మార్గాలు నిర్ణయిస్తాయి, పరిధి లోపం కొంత ట్రాఫిక్ సొరంగం గుండా వెళ్లి కొంత వెళ్లని చికాకు పెట్టే స్థితిని సృష్టిస్తుంది. addRoute("0.0.0.0", 0) మొత్తం IPv4ని తీసుకుంటుంది, అంటే ఇప్పుడు ప్రతి ప్యాకెట్ మీ వద్దకు వస్తుంది, దాన్ని ముందుకు పంపాలి లేదా వదిలేయాలి. ఒకే హోస్ట్ కోసం /32 దాదాపు ఏమీ తీసుకోదు, మిగతావన్నీ మీ VPN ఎప్పుడూ ఇన్స్టాల్ కానట్లే ప్రవర్తిస్తాయి.

కుటుంబాలు విడివిడిగా లెక్కించబడతాయి. IPv4 మాత్రమే ఉన్న మార్గం IPv6ని అంతర్లీన నెట్వర్క్లో వదిలివేస్తుంది, కాబట్టి ద్వి-స్టాక్ హోస్ట్ సొరంగం లోపల పూర్తిగా కనెక్ట్ అయినట్లు కనిపిస్తూనే బయట పేరును పరిష్కరించి కనెక్ట్ అవ్వగలదు.

DNS అదే తర్కాన్ని అనుసరిస్తుంది. addDnsServer() తో జోడించిన సర్వర్లు సొరంగం పరిష్కర్తను ఉపయోగించే యాప్లకు వెళ్తాయి, అయితే సొంత ఎన్క్రిప్టెడ్ DNS ఎండ్పాయింట్ లేదా హోస్ట్నామ్కు సెట్ చేసిన Private DNS ఉన్న యాప్ వాటిని పూర్తిగా పట్టించుకోదు. పేర్లు ఒక యాప్కు విఫలమై మరొక దానికి పనిచేసినప్పుడు, ఒక్క మార్గాన్ని కూడా తాకకముందే పరిష్కర్త మార్గాన్ని తనిఖీ చేయండి.

అపోహ 3: ప్రతి యాప్ నియమాలు రెండు వైపులా తిప్పగలిగే స్విచ్

addDisallowedApplication() మరియు addAllowedApplication() రెండు ఫిల్టర్లు కాదు, రెండు మోడ్లు. బిల్డర్ ఒక సొరంగానికి ఒక మోడల్ని మాత్రమే అంగీకరిస్తుంది, కాబట్టి మూడు ప్యాకేజీలు తప్ప అన్నీ కావాలనుకునే యాప్ నిషేధిత జాబితాను ఉపయోగించి అనుమతించిన జాబితాను ఖాళీగా వదిలివేస్తుంది. రెండూ ఒకదానికొకటి పరస్పర విరుద్ధం, మరియు సెట్టింగ్ల స్క్రీన్ ఇప్పటికే రెండు టోగుల్లను అందించిన తర్వాత ప్రజలు దీన్ని రన్టైమ్లో తెలుసుకుంటారు.

ప్యాకేజీ దృశ్యమానత కూడా కరుస్తుంది. Android 11 నుండి మీరు చూసే ప్యాకేజీలకు మాత్రమే పేరు పెట్టగలరు, కాబట్టి మీ యాప్ అమలు చేయడానికి అనుమతి లేని ప్రశ్న నుండి నిర్మించిన మినహాయింపు జాబితా నిశ్శబ్దంగా నమోదులను కోల్పోతుంది. జాబితాను నమ్మకముందు ప్యాకేజీ మేనేజర్ నిజంగా ఏమి తిరిగి ఇస్తుందో దానితో పోల్చండి.

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

అపోహ 4: stopSelf సొరంగాన్ని ముగిస్తుంది

లేదు. ఇంటర్ఫేస్ establish() తిరిగి ఇచ్చే డెస్క్రిప్టర్లో జీవిస్తుంది, ఆ డెస్క్రిప్టర్ తెరిచి ఉండగానే సేవా వస్తువు చనిపోవచ్చు. మొదట ParcelFileDescriptor మూసివేయండి, సూచనను వదలండి, రీడర్ మరియు రైటర్ థ్రెడ్లను కలపండి లేదా అంతరాయం కలిగించండి, ఆపై stopForeground(true) మరియు stopSelf() పిలుపులను ఆ క్రమంలో చేయండి.

మరచిపోయిన డెస్క్రిప్టర్ ఒక సేవ తన సొంత ఆపే అభ్యర్థన నుండి బయటపడినట్లు కనిపించడానికి సాధారణ కారణం, మరియు దాన్ని జోడించిన యాప్ కంటే ఎక్కువ కాలం జీవించే పాత మార్గాన్ని కూడా అది వివరిస్తుంది.

వ్యతిరేక లోపం కూడా అంతే సాధారణం: రీడర్ థ్రెడ్ చదువుతున్న మధ్యలో ఉండగానే డెస్క్రిప్టర్ను మూసివేయడం, ఆపై ఆ థ్రెడ్ను ఎవరూ కోడ్ రాయని మినహాయింపును నిర్వహించడానికి వదిలేయడం. మూసివేత క్రమాన్ని ఒకే చోట ఉంచండి, వినియోగదారు చర్య మరియు onRevoke() రెండూ అందులోకి పిలవనివ్వండి.

సొరంగం చనిపోయినట్లు కనిపించినప్పుడు ఏమి తనిఖీ చేయాలి

సొరంగం పైకి రాకముందే దీర్ఘ జీవిత సాకెట్లను protect() తో రక్షించండి. అది లేకుండా సొరంగం సొంత రవాణా మళ్లీ సొరంగంలోకి రూట్ అవుతుంది మరియు కనెక్షన్ సర్వర్ వైఫల్యంలా కనిపించే విధంగా ఆగిపోతుంది. దూర నెట్వర్క్ వెనుక మాత్రమే ఉన్న చిరునామాపై పరీక్షించండి, కాష్ నుండి లేదా అంతర్లీన మార్గం నుండి సమాధానం ఇచ్చే పబ్లిక్ సైట్పై కాదు.

establish() ఫలితం, మార్గాలు, మినహాయించిన ప్యాకేజీలు మరియు ఆపే కారణాన్ని లాగ్ చేయండి. ఆ నాలుగు పంక్తులు ప్యాకెట్ క్యాప్చర్ లేకుండా అంగీకార సమస్యను పరిధి సమస్య నుండి మరియు జీవిత చక్ర సమస్య నుండి వేరు చేస్తాయి.

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