Android VpnService లో స్ప్లిట్ టన్నెలింగ్: నిజంగా ఏమి రూట్ చేయవచ్చు

VpnService యాప్‌లో స్ప్లిట్ టన్నెలింగ్ కొన్ని నిర్దిష్ట చోట్లలో విరిగిపోతుంది, ప్రతి దానికి మరమ్మత్తు వేరు. క్లయింట్ విఫలమైన ఒక గమ్యాన్ని మాత్రమే చూపుతుంది, కాబట్టి మొదటి పని మీరు ఏ సరిహద్దును తాకుతున్నారో కనుగొనడం: builder పొందిన మార్గాలు, మీరు ధృవీకరించలేని ప్రాక్సీ, మీరు ప్రకటించిన resolver మాత్రమే, లేదా ప్లాట్‌ఫారమ్ ప్రతి వినియోగదారుకు వర్తించే యాప్ జాబితా. అందుకే నేను నాలుగు దశల తనిఖీని ఉంచుతున్నాను. అది క్రింది క్రమంలో నడుస్తుంది మరియు మొదటి వైఫల్యం వద్ద ఆగిపోతుంది.

builder ప్లాట్‌ఫారమ్‌కు ఏమి ఇచ్చిందో నిర్ధారించండి

VpnService.Builder అనేది ప్రకటనల జాబితా. establish() వర్చువల్ ఇంటర్‌ఫేస్ కోసం ParcelFileDescriptor ను తిరిగి ఇస్తుంది, మరియు addAddress మరియు addRoute ప్రిఫిక్స్‌లకు సరిపోయే ట్రాఫిక్‌ను మాత్రమే ప్లాట్‌ఫారమ్ ఆ డిస్క్రిప్టర్‌కు పంపుతుంది; addDnsServer ఏ resolver ను అడగాలో క్లయింట్లకు చెబుతుంది. మీరు జోడించిన అన్ని ప్రిఫిక్స్‌లకు బయట ఉన్న గమ్యం, ఇంటర్‌ఫేస్ ఏమి వాగ్దానం చేసినా మీ యాప్‌కు చేరుకోదు. ఈ ఒక్క వాస్తవం కోడ్ మార్చకముందే విరిగిన స్ప్లిట్ టన్నెలింగ్ గురించిన చాలా నివేదికలను వివరిస్తుంది.

మీ builder సమకూర్చిన చిరునామా, మార్గం మరియు DNS జాబితాలను లాగ్ చేయండి, తర్వాత వాటిని విఫలమయ్యే గమ్యాలతో పోల్చండి. నిర్వాహక హోస్ట్ కోసం తప్పిపోయిన /32 విరిగిన టన్నెల్ కంటే చాలా సాధారణం. జాబితా సరిగ్గా ఉంటే ముందుకు సాగండి; తప్పు అయితే మిగిలిన తనిఖీ జాబితా వ్యర్థ శ్రమ.

excludeRoute API 33 నుండి మాత్రమే ఉంది

గమ్యం ఆధారిత మినహాయింపు చాలాసార్లు మద్దతు థ్రెడ్‌గా మారే అభ్యర్థన. builder.excludeRoute(IpPrefix) API 33 లో వచ్చింది; అంతకుముందు మద్దతు ఉన్న ఏకైక అంచనా మినహాయించిన ప్రిఫిక్స్ తప్ప మిగతా అన్నింటికీ మార్గాలు జోడించడం, అంటే పూరక ప్రిఫిక్స్‌లను మీరే లెక్కించాలి. రెండు కాల్స్ అద్దం ప్రతిబింబాలు కావు: ఒకటి ఇంటర్‌ఫేస్ మార్గ సముదాయం నుండి తీసివేస్తుంది, మరొకటి సముదాయాన్ని సున్నా నుండి నిర్మిస్తుంది, పాత పరికరం తెలియని కాల్‌ను విసురుతుంది లేదా నిశ్శబ్దంగా పట్టించుకోదు. Build.VERSION.SDK_INT ఆధారంగా శాఖపరచి రెండు మార్గాలను నిజమైన హార్డ్‌వేర్‌పై పరీక్షించండి.

పూరకాలను లెక్కించేటప్పుడు ప్రిఫిక్స్ సమలేఖనాన్ని గమనించండి. /16 మార్గం లోపల /24 మినహాయింపుకు మిగిలిన భాగాన్ని నిజంగా వివరించే కవరింగ్ ప్రిఫిక్స్‌లు అవసరం, ఒక వికృత /8 కాదు. తుది జాబితాను లాగ్ చేయండి మరియు మినహాయించిన హోస్ట్ ఇంకా టన్నెల్ బయటి మార్గం ద్వారా పరిష్కరించబడుతుందని నిర్ధారించండి.

ప్రాక్సీ ఆధారాలు వ్యక్తపరచలేము

setHttpProxy(ProxyInfo) ఇంటర్‌ఫేస్‌ను HTTP లేదా SOCKS ప్రాక్సీ వైపు మళ్లిస్తుంది, PAC URL ప్రతి గమ్యానికి వాటి మధ్య ఎంచుకోగలదు. ProxyInfo గానీ PAC ఆకృతి గానీ వినియోగదారు పేరు మరియు పాస్‌వర్డ్‌ను తీసుకెళ్లవు, కాబట్టి ప్రామాణీకరణ అవసరమయ్యే ప్రాక్సీ ప్లాట్‌ఫారమ్ API బయట ఉంటుంది. అది అవసరమయ్యే యాప్‌లు సాధారణంగా userspace స్టాక్, tun2socks లేదా అలాంటి ఇంజిన్‌ను చేర్చి 407 సవాలుకు తామే సమాధానం ఇస్తాయి.

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

ప్రతి-యాప్ జాబితాలు మరియు DNS కూడా ప్రకటనలే

Builder లో addAllowedApplication మరియు addDisallowedApplication రెండూ ఉన్నాయి, మరియు అవి పరస్పర విరుద్ధం: రెండింటిని పిలిస్తే మినహాయింపు విసురుతుంది. ఏదేమైనా జాబితా ఇంటర్‌ఫేస్ సెటప్‌లో ప్రతి వినియోగదారుకు వర్తిస్తుంది, కాబట్టి పని ప్రొఫైల్ యాప్ మీ టన్నెల్ ద్వారా కాదు, పని ప్రొఫైల్ టన్నెల్ ద్వారా నిర్వహించబడుతుంది. ఏ API ఇవ్వనిది మరొక యాప్ నిర్ణయంపై నియంత్రణ: బయట నుండి ప్యాకెట్‌ను మీ టన్నెల్‌లోకి నెట్టలేరు, ఇప్పటికే సక్రియంగా ఉన్న VPN ను మూసివేయలేరు లేదా పునఃకాన్ఫిగర్ చేయలేరు.

DNS కూడా అదే నమూనాను అనుసరిస్తుంది. addDnsServer resolver చిరునామాను ప్రకటిస్తుంది; అది మీ యాప్ ప్రశ్నలకు సమాధానం ఇవ్వడానికి అనుమతించదు. మీరే పేర్లను పరిష్కరించాలనుకుంటే resolver ను నడపండి మరియు దాని చిరునామాను టన్నెల్‌లోకి రూట్ చేయండి. స్థిర హోస్ట్ పేరుకు DoT లేదా DoH ఉపయోగించే యాప్‌లు మీరు ప్రకటించిన చిరునామాను దాటవేయగలవు, కాబట్టి ప్రశ్న మార్గాన్ని కూడా అడ్డుకోకపోతే పేరు పరిష్కారాన్ని ఉత్తమ ప్రయత్నంగా పరిగణించండి.

Manifest, always-on మరియు నాలుగు దశల పరీక్ష

అర్హత manifest లో ప్రకటించబడుతుంది: BIND_VPN_SERVICE, android.net.VpnService intent ఫిల్టర్, మరియు టన్నెల్ నేపథ్యంలో నిలవాలంటే foreground సేవ. Always-on VPN అదనంగా శుభ్రమైన onRevoke కోరుతుంది, ఎందుకంటే వినియోగదారు సెట్టింగ్‌లు మార్చినప్పుడు లేదా మరొక యాప్ నియంత్రణ తీసుకున్నప్పుడు సిస్టమ్ దాన్ని పిలుస్తుంది.

తనిఖీలను క్రమంగా నిర్వహించి మొదటి వైఫల్యం వద్ద ఆపండి. మొదట, builder కు ఇచ్చిన చిరునామా, మార్గం మరియు DNS జాబితాలను బయటకు తీయండి. రెండవది, establish() డిస్క్రిప్టర్‌ను తిరిగి ఇచ్చిందని మరియు రవాణా సాకెట్ రక్షించబడిందని నిర్ధారించండి. మూడవది, చేర్చిన ప్రిఫిక్స్ లోపల ఒక గమ్యాన్ని మరియు మినహాయించిన ప్రిఫిక్స్ లోపల ఒకదాన్ని కోరండి. నాల్గవది, మీ resolver మాత్రమే పరిష్కరించగల హోస్ట్ పేరును అడిగి ఏ resolver నిజంగా సమాధానం ఇచ్చిందో తనిఖీ చేయండి.

పూర్తయిన కరచాలనం తర్వాతి దశలలో ఏదీ నిరూపించదు. ప్రతి తనిఖీ ఒక పొరను వేరుచేస్తుంది, కాబట్టి రెండవ దశలో విజయం నాల్గవ దశ గురించి ఏమీ చెప్పదు.

VpnService.Builder సూచన builder యొక్క మొత్తం ఉపరితలాన్ని జాబితా చేస్తుంది. దానికి మించి అవసరమయ్యేది మరో API, మరో యాప్ లేదా మీ సొంత userspace స్టాక్, మరియు అది స్ప్లిట్-టన్నెల్ బగ్ కాదు, డిజైన్ నిర్ణయం.