Android VPN రూటింగ్: main పట్టికకు ముందు విధాన నియమాలు
Android ఏదైనా గమ్య శోధనకు ముందు uid మరియు గుర్తు నియమాలతో రూటింగ్ పట్టికను ఎంచుకుంటుంది, కాబట్టి main కు జోడించిన మార్గం ఎప్పుడూ తనిఖీ చేయబడకపోవచ్చు.
Android లో main పట్టికకు జోడించిన మార్గం ప్రతి జాబితాలో సరిగ్గా కనిపిస్తుంది మరియు అయినప్పటికీ ట్రాఫిక్ను మోసుకెళ్లదు. కారణం ఏమిటంటే main పట్టిక అనేక ఎంపికలలో ఒకటి మాత్రమే, మరియు దానిని మొదట అడగరు. Android నెట్వర్కింగ్ సేవ గమ్య చిరునామాలో లేని సమాచారంతో రూటింగ్ పట్టికను ఎంచుకునే విధాన నియమాలను నిర్మిస్తుంది — యాప్ యొక్క uid, ప్యాకెట్పై ఉన్న గుర్తు, అది వచ్చిన ఇంటర్ఫేస్ — మరియు గమ్యం కోసం వెతకడం తర్వాత, ఆ నియమాలు ఎంచుకున్న పట్టిక లోపల జరుగుతుంది.
స్థిర క్రమంలో మూడు నిర్ణయాలు
బయటకు వెళ్లే ప్యాకెట్ మూడు వేర్వేరు నిర్ణయాలు తీసుకుంటుంది. మొదట, ఒక విధాన నియమం ఏ రూటింగ్ పట్టిక వర్తిస్తుందో నిర్ణయిస్తుంది. రెండవది, ఆ పట్టిక లోపలి మార్గం తదుపరి హాప్ మరియు బయటకు వెళ్లే ఇంటర్ఫేస్ను నిర్ణయిస్తుంది. మూడవది, netfilter హుక్లు ప్యాకెట్ నిలిచిపోతుందా, మారుతుందా లేదా మళ్లించబడుతుందా అని నిర్ణయిస్తాయి.
ప్రతి దశ తన ప్రశ్నకు మాత్రమే సమాధానం చెప్పగలదు కాబట్టి క్రమం ముఖ్యం. ప్యాకెట్ను అంగీకరించే ఫైర్వాల్ నియమం పట్టికను ఎంచుకోదు, ఏ నియమం ఎంచుకోని పట్టికకు జోడించిన మార్గం నిష్క్రియంగా ఉంటుంది. Android VPN ల గురించిన చాలా గందరగోళం మూడింటిలో ఒకదాన్ని సరిచేసి మార్పు కనిపించకపోవడం నుండి వస్తుంది, ఎందుకంటే లోపం మరొకదానిలో ఉంది.
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
గుర్తులు ప్యాక్ చేసిన క్షేత్రం, మీ సొంత లేబుల్ కాదు
Android అనేక వాస్తవాలను ఒకే గుర్తు విలువలో ప్యాక్ చేస్తుంది: ఏ నెట్వర్క్ ఎంపికైంది, యాప్ నెట్వర్క్ను స్పష్టంగా ఎంచుకుందా, సాకెట్ VPN నుండి రక్షించబడిందా, మరియు అనుమతులకు సంబంధించిన బిట్లు. AOSP యొక్క fwmark శీర్షిక ప్రస్తుత చెట్టుకు ఆ లేఅవుట్ను నిర్వచిస్తుంది, మరియు లేఅవుట్ విడుదలల మధ్య మారే ప్లాట్ఫారమ్ అంతర్గత వివరం.
అందుకే Android లో iptables -j MARK --set-mark తో పూర్తి గుర్తు విలువను రాయడం ప్రమాదకరం. ఇది ట్యాగ్ను జోడించదు; సిస్టమ్ ఇప్పటికే చేసిన నెట్వర్క్ ఎంపికను భర్తీ చేస్తుంది. అప్పుడు ప్యాకెట్ వేరే నియమాలతో సరిపోలుతుంది, ఇది ఏ బిట్లు తిరిగి రాయబడ్డాయో దాన్ని బట్టి VPN పని ప్రారంభించినట్లు లేదా సంబంధం లేని యాప్ కనెక్టివిటీ కోల్పోయినట్లు కనిపించవచ్చు.
గుర్తులను తాకాల్సి వస్తే, మొదట ప్రస్తుత విలువను చదివి, మీకు అర్థమయ్యే బిట్లు మాత్రమే మారేలా మాస్క్ ఉపయోగించండి:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11కనెక్షన్ గుర్తు ప్యాకెట్ గుర్తు నుండి వేరైన వస్తువు, రెండూ మార్గం కావు. ప్రతిస్పందన ప్యాకెట్లపై గుర్తును పునరుద్ధరించడం బయటకు వెళ్లేటప్పుడు పట్టికను ఎంచుకోవడం నుండి వేరైన దశ, అందుకే ఒక దిశ పరిష్కారాలు తెరిచి తర్వాత వేలాడే కనెక్షన్లను ఉత్పత్తి చేస్తాయి.
నియమాలు మరియు పట్టికల యజమాని ఎవరు
Android నెట్వర్క్ సేవ అయిన netd నియమాలను మరియు ప్రతి నెట్వర్క్ పట్టికలను సృష్టిస్తుంది. AOSP RouteController అనేది VPN, భౌతిక నెట్వర్క్లు మరియు uid పరిధుల కోసం ఆ నియమాలు జోడించబడే స్థలం, దాని జీవిత చక్రం కాన్ఫిగ్ ఫైల్తో కాకుండా నెట్వర్క్ సంఘటనలతో ముడిపడి ఉంది.
రెండు పరిణామాలు ఉన్నాయి. మొదట, ఒక పరికరంలో మీకు కనిపించే ప్రాధాన్యతలు మరియు పట్టిక సంఖ్యలు బిల్డ్ అంతర్గత వివరాలు, ఇంటర్ఫేస్ కాదు: మరో Android సంస్కరణలో ఒకేలా కనిపించే సంఖ్యలు పూర్తిగా వేరే అర్థాన్ని ఇవ్వవచ్చు. రెండవది, నెట్వర్క్లు మారినప్పుడు స్థితి తిరిగి నిర్మించబడుతుంది, కాబట్టి ఈరోజు root షెల్ నుండి చేర్చిన నియమం తదుపరి Wi-Fi మార్పు తర్వాత పోయి ఉండవచ్చు.
ఈ అదృశ్యం తరచుగా సిస్టమ్ మార్గాన్ని పట్టించుకోవడం లేదు అని నివేదించబడుతుంది. వాస్తవంగా జరిగింది ఏమిటంటే పట్టికను ఎంచుకున్న నియమం ఇక లేదు, మరియు పట్టిక లోపలి మార్గం ఇప్పుడు ప్యాకెట్ దృష్టికోణంలో చేరలేనిది. మళ్లీ కనెక్ట్ అయిన తర్వాత పని చేసిన కాన్ఫిగరేషన్ పని చేయడం ఆపినప్పుడు మార్గాల జాబితా కాదు, నియమాల జాబితా తనిఖీ చేయండి.
హుక్ క్రమం గురించిన ప్రశ్నలకు సార్వత్రిక సమాధానం లేదు
iptables VPN రూటింగ్కు ముందు నడుస్తుందా అనే ప్రశ్నకు ప్యాకెట్ మార్గాన్ని పేర్కొనకుండా సమాధానం చెప్పలేము. స్థానికంగా సృష్టించిన ప్యాకెట్ output హుక్ గుండా వెళుతుంది, అక్కడ గుర్తు మార్పు తిరిగి రూటింగ్ తనిఖీని ప్రేరేపిస్తుంది — ఇది రెండవ శోధన, మొదటి దాని వెనుకబడిన సవరణ కాదు. tether చేసిన క్లయింట్ నుండి వచ్చే ప్యాకెట్ prerouting మార్గం గుండా వెళ్లి బదులుగా ముందుకు పంపబడుతుంది, మరియు దాన్ని చూసే చైన్లు వేరు.
కాబట్టి అదే నియమం ఒక యాప్ ట్రాఫిక్కు ప్రభావవంతంగా మరియు tether ట్రాఫిక్కు కనిపించకుండా ఉండవచ్చు, సున్నా వద్ద ఉండే కౌంటర్ ప్యాకెట్ ఏ మార్గం తీసుకుందో చెబుతుంది, నియమం తప్పా కాదా అని కాదు. ఏదైనా సరిపోలిక షరతును మార్చే ముందు కౌంటర్లతో మార్గాన్ని నిర్ధారించండి.
విధాన రూటింగ్ లోపాన్ని చూడటం కష్టమయ్యే దశ కూడా ఇదే. ఉన్నా గమ్యాన్ని కలిగి లేని పట్టికకు రూటింగ్ చేయడం ఫైర్వాల్ డ్రాప్ లాగా కనిపించే నెట్వర్క్ చేరలేము ఉత్పత్తి చేస్తుంది, అయితే ఫైర్వాల్ డ్రాప్ రూటింగ్ బ్లాక్ హోల్ లాగా కనిపించే సమయ ముగింపును ఉత్పత్తి చేస్తుంది.
వ్యవస్థ లోపలే నిర్ధారణ చేయండి, లేదా దానిని వదిలేయండి
అధికారిక సమీక్ష కోసం, ఏదైనా తాకే ముందు నాలుగు వాస్తవాలను నిర్ధారించండి: యాప్ యొక్క uid మరియు ప్రొఫైల్, Android దాని కోసం ఎంచుకున్న నెట్వర్క్, VPN ఆ యాప్ను సమావేశపరుస్తుందా, మరియు సమస్య రెండు చిరునామా కుటుంబాలలో ఉందా. ప్రతి-యాప్ మినహాయింపు ఎలాంటి రూటింగ్ లోపం లేకుండా VPN పని చేయడం లేదు అనే చాలా నివేదికలను వివరిస్తుంది.
తర్వాత నిజంగా అమలులో ఉన్న నియమాలు, మాస్క్లు మరియు పట్టికలను చదవండి, మరియు పరిశీలన విండోలో నెట్వర్క్ మార్పును ఉంచండి. మళ్లీ కనెక్ట్ అవ్వడం వెంట ప్రవర్తన మారితే, మీరు నిర్వహించబడే జీవిత చక్రాన్ని చూస్తున్నారు, తప్పిపోయిన మార్గాన్ని కాదు.
సాధారణ అవసరాలకు మద్దతు ఉన్న నియంత్రణలను ఉపయోగించండి: ప్రతి-యాప్ చేర్పు మరియు మినహాయింపు VPN అప్లికేషన్లో, మరియు నిర్దిష్ట మార్గం అవసరమయ్యే ప్రతిదానికీ ప్లాట్ఫారమ్ యొక్క స్వంత నెట్వర్క్ ఎంపిక. ప్రత్యేక అధికారం ఉన్న ఇంటిగ్రేషన్ నిజంగా రూటింగ్ యంత్రంతో సహకరించాల్సి వస్తే, మీరు మద్దతు ఇచ్చే ఖచ్చితమైన Android సంస్కరణ అమలును లక్ష్యంగా పెట్టుకోండి మరియు దాని యజమాని అయిన భాగం ద్వారా దాని జీవిత చక్రాన్ని నిర్వహించండి. ప్లాట్ఫారమ్ చైన్లను ఫ్లష్ చేయడం లేదా అధిక ప్రాధాన్యత నియమాన్ని చేర్చడం నిర్ధారణను రెండవ నెట్వర్క్ మేనేజర్గా మారుస్తుంది, మరియు ఫోన్ దానికి అనుగుణంగా ప్రవర్తిస్తుంది.