Android VPN: VpnService డిస్క్రిప్టర్ మరియు root tun పరికరం

రెండు మార్గాలు Android యాప్ ముందు IP ఇంటర్ఫేస్ పెట్టగలవు, రెండూ చాలా భిన్నమైన యజమానులతో ఒకే రకమైన ఫైల్ డిస్క్రిప్టర్ వద్ద ముగుస్తాయి. ఒకటి VpnService మరియు దాని builder ద్వారా వెళ్తుంది, మరొకటి root shell మరియు /dev/net/tun ద్వారా. ఆ డిస్క్రిప్టర్‌పై ప్రతి పఠనం బయటకు వెళ్లే ప్యాకెట్, ప్రతి రచన లోపలికి వచ్చే ప్యాకెట్. మార్గాలను వేరు చేసేది విధానం ఎవరి చేతిలో ఉంది, OS అప్‌గ్రేడ్‌ను ఎవరు తట్టుకుంటారు, మరియు రూటింగ్ పట్టికలో ఎంతవరకు మీరు తాకగలరు అనేది.

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

ప్లాట్‌ఫారమ్ మార్గంలో మీరు ఆదేశాలకు బదులు ఉద్దేశాన్ని ప్రకటిస్తారు. కనీసం ఒక చిరునామా, కావలసిన రూట్లు, DNS సర్వర్లు మరియు ఐచ్ఛిక యాప్ జాబితాను ఇస్తారు, తర్వాత Android సిస్టమ్ సేవ తన స్వంత గుర్తింపుతో ప్రత్యేక అధికారాల సెటప్ చేస్తుంది. ఇంటర్ఫేస్ పేరు మీకు ముందే తెలియదు, దానిని సృష్టించే ioctl ఎప్పుడూ జారీ చేయరు, అదే ముఖ్యాంశం.

IP ఇంటర్ఫేస్ పొందే రెండు మార్గాలు

root మార్గం పాత వంటకం. మీరు /dev/net/tun తెరుస్తారు, IFF_TUN తో TUNSETIFF పిలుస్తారు, ip link తో ఇంటర్ఫేస్ పైకి లేపుతారు, మరియు చిరునామాలు, రూట్లను చేతితో కలుపుతారు. ప్రతి అడుగును మీరే సరిగ్గా చేయాలి, ఫ్రేమ్‌వర్క్ నిశ్శబ్దంగా నిర్వహించేవి కూడా. ఒక రూట్ తప్పిపోతే వినియోగదారుకు చనిపోయిన సర్వర్ లాంటి నివేదిక వస్తుంది.

డీబగ్గింగ్ సెటప్ అంతే భిన్నంగా ఉంటుంది. root మార్గంలో ఇంటర్ఫేస్ ఉంది లేదా మీ ioctl నేరుగా చదవగలిగే లోపాన్ని తిరిగి ఇచ్చింది. ప్లాట్‌ఫారమ్ మార్గంలో establish() విజయవంతమైన తర్వాతే ఇంటర్ఫేస్ ఉంటుంది, కాబట్టి వైఫల్యం పరికర నోడ్‌కు బదులు మినహాయింపు లేదా null డిస్క్రిప్టర్‌గా వస్తుంది, దానిని మీరు తొక్కిచూడవచ్చు.

establish() నిజంగా ఏమి తిరిగి ఇస్తుంది

Builder.establish() కు మూడు ఫలితాలు ఉన్నాయి, వాటికి మూడు వేర్వేరు ప్రతిస్పందనలు కావాలి. డిస్క్రిప్టర్ అంటే ఇంటర్ఫేస్ కాన్ఫిగర్ అయింది మరియు వాడటానికి మీది, null అంటే అభ్యర్థన దాటలేదు, మరియు విసిరిన మినహాయింపు అంటే సిస్టమ్ సేవ దానిని తిరస్కరించింది. null మరియు విజయాన్ని ఒకే boolean లో కలపడం ప్యాకెట్ ఎప్పుడూ మోయని పనిచేస్తున్న సొరంగాన్ని యాప్ నివేదించే అత్యంత సాధారణ మార్గం. Builder సూచన చిరునామా అవసరాన్ని తెలియజేస్తుంది, సర్వర్‌ను నిందించే ముందు దాన్ని చదవడం విలువైనది.

దిశలను డిస్క్రిప్టర్ నిర్ణయిస్తుంది, మీ ప్రోటోకాల్ కాదు. పఠనాలు ఇప్పటికే VPN కోసం ఎంపిక చేయబడిన బయటకు వెళ్లే ప్యాకెట్లను ఇస్తాయి, రచనలు లోపలికి వచ్చే ప్యాకెట్లను తిరిగి ఇంటర్ఫేస్‌లోకి చొప్పిస్తాయి. ఆ ప్యాకెట్లను ఎన్‌క్రిప్ట్ చేయడం, ప్రామాణీకరించడం మరియు ఫ్రేమ్ చేయడం మీ స్వంత రవాణా పని, ఎందుకంటే ప్లాట్‌ఫారమ్ ప్యాకెట్ సరిహద్దులో ఆగుతుంది.

Binder ఒక అడుగు, JNI మరో అక్షం

builder అభ్యర్థన Binder ద్వారా సిస్టమ్‌లోకి ప్రవేశిస్తుంది, దాని కింద ఎక్కడో ప్లాట్‌ఫారమ్ పరికరాన్ని కాన్ఫిగర్ చేయడానికి native కోడ్‌ను పిలుస్తుంది. ఇవి ఒకే పిలుపులో పోగుచేసిన రెండు వేర్వేరు విధానాలు. Binder మీ యాప్ మరియు సిస్టమ్ సేవ మధ్య ప్రక్రియల మధ్య సంవహనం, అయితే JNI ప్రక్రియ లోపల Java నుండి native కు వంతెన. Android 9 AOSP చెట్టును చదవడం స్టాక్‌ను అక్షరార్థంగా చూపిస్తుంది, అంతర్గత తరగతి పేర్లు మరియు ఫైల్ మార్గాలు విడుదలల మధ్య మారుతాయని గుర్తుంచుకోవాలి.

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

TUN IP ను మోస్తుంది, TAP Ethernet

TUN ఒక IP ఇంటర్ఫేస్. TAP ఒక Ethernet ఇంటర్ఫేస్, ఆ భేదమే వంతెన సాధ్యమా కాదా అని నిర్ణయిస్తుంది. TUN పరికరానికి MAC చిరునామా లేదు మరియు పంపడానికి Ethernet శీర్షిక లేదు, కాబట్టి TUN క్లయింట్ రూట్లు ఎలా రాసినా పొర 2 వంతెనలో చేరలేదు.

VpnService మీకు IP రకాన్ని ఇస్తుంది, అదే యాప్ స్థాయి VPN కు కావాల్సినది మరియు ముడి Ethernet స్టాక్ లేకుండా మద్దతు ఇవ్వగలిగేది. మీ రూపకల్పనకు వంతెన అవసరమైతే, ప్లాట్‌ఫారమ్ మార్గం మిమ్మల్ని అక్కడికి తీసుకెళ్లదు, కర్నెల్ మరియు పరికర అనుమతులు సహకరిస్తే మాత్రమే root మార్గం తీసుకెళ్తుంది.

root మార్గం ఇంకా గెలిచే చోటు

మూడు పనులు ప్రజలను ప్లాట్‌ఫారమ్ మార్గం నుండి దూరం నెడతాయి. పొర 2 వంతెనకు TAP కావాలి. మీ VPN పరిధి వెలుపలి యాప్‌ల ట్రాఫిక్‌ను పట్టుకోవడానికి ఫ్రేమ్‌వర్క్ ఇవ్వని దృశ్యమానత కావాలి. builder ఎప్పుడూ బహిర్గతం చేయని విధాన రూటింగ్, ఉదాహరణకు ఒక గమ్యానికి ప్రత్యేక పట్టిక, మీరే ఇన్‌స్టాల్ చేసే నియమాలను కోరుతుంది.

ఖర్చులు తర్వాత వస్తాయి: అన్‌లాక్ చేసిన bootloader లేదా root చేసిన ఇమేజ్, మీ కాళ్ల కింద కదిలే SELinux విధానం, మరియు OTA తర్వాత సరిగ్గా ప్రవర్తించడం ఆపే పరికరం. root చేసిన వంటకాన్ని సాధారణ యాప్ పంపిణీ ద్వారా పంపలేము, కాబట్టి చాలా బృందాలు దాన్ని ఉత్పత్తికి బదులు అంతర్గత నిర్ధారణ మార్గంగా ఉంచుతాయి.

రెండింటి మధ్య ఎంపిక

మీ వద్ద ఉన్న కోడ్ నుండి కాదు, మీకు కావలసిన ఇంటర్ఫేస్ నుండి ప్రారంభించండి. సమాధానం యాప్-పరిమిత రూట్లతో TUN పరికరం అయితే, ప్లాట్‌ఫారమ్ మార్గం చిన్నది మరియు అప్‌గ్రేడ్‌లను తట్టుకుంటుంది. సమాధానంలో Ethernet ఫ్రేమ్‌లు, ఇతర యాప్‌ల క్యాప్చర్, లేదా builder తిరస్కరించే రూటింగ్ నియమాలు ఉంటే, మీరు root ప్రాంతంలో ఉన్నారు మరియు దాన్ని నిర్వహణ ఖర్చుగా బడ్జెట్ చేయాలి.

చాలా చర్చలను పరిష్కరించే ఒక తనిఖీ: మొదట ప్లాట్‌ఫారమ్ మార్గాన్ని నిర్మించండి, establish() ఫలితాన్ని దూర సెషన్ స్థితి నుండి వేరుగా నమోదు చేయండి, మరియు ప్రతి దిశలో ఒక ప్యాకెట్‌ను నిర్ధారించండి. ఆ తర్వాతే లేని సామర్థ్యం మద్దతు ఉన్న మార్గాన్ని వదలడాన్ని సమర్థిస్తుందా అని నిర్ణయించండి.