హాట్‌స్పాట్ క్లయింట్‌ల కోసం విభజిత టన్నెలింగ్ ప్రతి యాప్ మినహాయింపు కాదు
యాప్‌ను VPN నుండి మినహాయించడం ఫోన్‌ను మాత్రమే మారుస్తుంది. కనెక్ట్ చేసిన ల్యాప్‌టాప్‌కు మూలం, గమ్యం మరియు NATపై సరిపోలే దాని సొంత ఫార్వార్డింగ్ నియమం అవసరం.
ఒకేలా వినిపించే రెండు అవసరాలు ఒకటి కావు: «ఈ యాప్‌ను VPN నుండి మినహాయించు» మరియు «ఈ ఒకే గమ్యాన్ని నా హాట్‌స్పాట్‌లోని ల్యాప్‌టాప్ కోసం VPN వెలుపలికి పంపు». మొదటిది ఫోన్‌లోని సాకెట్ నెట్‌వర్క్‌ను ఎలా ఎంచుకుంటుందో మారుస్తుంది. రెండవది ఫోన్ ఇప్పటికే అంగీకరించిన తర్వాత మరొక పరికరం నుండి వచ్చిన ప్యాకెట్ కోసం ఫార్వార్డింగ్ నిర్ణయాన్ని మార్చాలి. రెండింటినీ కలపడమే హాట్‌స్పాట్ క్లయింట్ ఎల్లప్పుడూ ఫోన్ సొంత బ్రౌజర్‌కు మాత్రమే వర్తించిన మినహాయింపుతో మిగిలిపోవడానికి కారణం.
రెండు ప్రశ్నల యజమానులు రెండు వేర్వేరు ఉపవ్యవస్థలు
Android యాప్ నెట్‌వర్కింగ్ మరియు టెథరింగ్‌ను వేరుగా ఉంచుతుంది. యాప్‌ల సాకెట్‌లను కనెక్టివిటీ స్టాక్ నెట్‌వర్క్‌కు కేటాయిస్తుంది, మరియు VPN యాప్ తన సొంత సాకెట్‌లలో ఏవి టన్నెల్‌లోకి వెళ్తాయో నిర్ణయిస్తుంది. కనెక్ట్ చేసిన క్లయింట్ నుండి ఫార్వార్డ్ చేసిన ప్యాకెట్‌లను టెథరింగ్ ఉపవ్యవస్థ నిర్వహిస్తుంది, అది netd నుండి మార్గాలు, విధాన నియమాలు మరియు దిగువ ఇంటర్‌ఫేస్‌పై అనువాదాన్ని అడుగుతుంది.
ప్రతి యాప్ మినహాయింపు యాప్ సాకెట్ తెరిచినప్పుడు మూల్యాంకనం చేయబడుతుంది. ఫార్వార్డ్ చేసిన ప్యాకెట్ ఆ తనిఖీకి ఎప్పటికీ చేరుకోదు, ఎందుకంటే అది ఈ పరికరంలోని యాప్ సాకెట్ నుండి పుట్టలేదు. రెండు సెట్టింగ్‌లు ఒకదానికొకటి ప్రత్యామ్నాయం కాలేకపోవడానికి ఇదే పూర్తి కారణం, మరియు ఇది రెండింటిలోనూ బగ్ కాదు.
ప్రతి యాప్ మినహాయింపు నిజంగా ఏమి మారుస్తుంది
VpnService బిల్డర్ addDisallowedApplication తో టన్నెల్ వెలుపల ఉండే ప్యాకేజీలను పేరు పెట్టవచ్చు, లేదా addAllowedApplication తో లోపల అనుమతించబడిన ఏకైక ప్యాకేజీలను పేరు పెట్టవచ్చు. ఆ యాప్‌లు అప్పుడు అంతర్లీన నెట్‌వర్క్‌లో సాకెట్‌లను తెరుస్తాయి, VPN మిగతా అన్నింటికీ డిఫాల్ట్ మార్గాన్ని కలిగి ఉంటుంది.
పరిధి ఖచ్చితమైనది: ప్యాకేజీ సొంత సాకెట్‌లు, ఈ పరికరంలో, టన్నెల్ పైన ఉన్నంత వరకు. ఇది ఫార్వార్డ్ చేసిన ట్రాఫిక్ గురించి ఏమీ చెప్పదు, రెండవ పరికరం గురించి ఏమీ లేదు, సిస్టమ్ టెథరింగ్ తరఫున పంపే ప్యాకెట్‌ల గురించి కూడా ఏమీ లేదు.
ఇది గమ్య నియంత్రణ కూడా కాదు. బ్రౌజర్‌ను మినహాయించడం ఆ బ్రౌజర్ చేరే ప్రతి చిరునామానూ మినహాయిస్తుంది, మీరు టన్నెల్ లోపల ఉంచాలనుకున్నది కూడా. అవసరం యాప్‌కు బదులుగా గమ్యాన్ని పేర్కొన్నప్పుడు, యాప్ ఎంపికదారు నిర్మాణం ప్రకారమే తప్పు సాధనం.
ఫోన్‌కు టెథర్ చేసిన ప్యాకెట్ ఎలా కనిపిస్తుంది
క్లయింట్ ప్యాకెట్ హాట్‌స్పాట్ ఇంటర్‌ఫేస్‌కు ఫోన్ కేటాయించిన ప్రైవేట్ మూల చిరునామాతో, చెప్పాలంటే 192.168.43.20, మరియు పబ్లిక్ గమ్యంతో వస్తుంది. దాన్ని ఫార్వార్డ్ చేయడానికి ఫోన్‌కు పై లింక్ వైపు మార్గం మరియు అనువాద నియమం అవసరం, లేకపోతే సమాధానాలు తిరిగి వచ్చే దారిని కనుగొనలేవు, ఎందుకంటే క్లయింట్ ప్రైవేట్ చిరునామా సెల్యులార్ నెట్‌వర్క్‌లో అర్థరహితం.
Android దీన్ని రూటింగ్ పట్టికను ఎంచుకునే విధాన నియమాల ద్వారా వ్యక్తపరుస్తుంది, నెట్‌వర్క్‌లు మరియు VPNలు మారినప్పుడు netd సంబంధిత పట్టికలు మరియు నియమాలను తిరిగి నిర్మిస్తుంది. ఫోరం పోస్ట్ నుండి లేదా అదే మోడల్ పాత విడుదల నుండి కాపీ చేసిన పట్టిక సంఖ్య, నియమ ప్రాధాన్యత లేదా ఇంటర్‌ఫేస్ పేరు శాశ్వత యాజమాన్యాన్ని స్థాపించవు. ఈ పునర్నిర్మాణమే చేతితో రాసిన నియమం ఒక గంట పని చేసి తర్వాతి పునఃకనెక్షన్ తర్వాత ఆగిపోవడానికి కారణం.
హాట్‌స్పాట్ మినహాయింపుకు నిజంగా ఏ విధానం అవసరం
యావదైన నియమాన్ని తాకే ముందు నిర్ణయాన్ని మూలం, గమ్యం మరియు ఉద్దేశించిన మార్గంగా రాయండి. ఒక ఆమోదించిన గమ్యానికి కనీస రూపం ఇలా ఉంటుంది:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
రెండు దిశలూ పూర్తిగా ఉండాలి. ప్రత్యక్ష శాఖకు ప్రస్తుతం ఉన్న సెల్యులార్ పై లింక్ ద్వారా ఉపయోగించగల మార్గం అవసరం; VPN శాఖకు టన్నెల్ మార్గం మరియు ఫార్వార్డ్ చేయడానికి అనుమతి అవసరం. ఏదైనా మూల అనువాదం మీరు ఎంచుకున్న నిర్గమనానికి సరిపోలాలి, ఎందుకంటే టన్నెల్ ఇంటర్‌ఫేస్‌పై వర్తించే NAT టన్నెల్ చిరునామాను చూపుతుంది, సెల్యులార్ చిరునామాను కాదు, అప్పుడు తిరిగి వచ్చే మార్గం వెళ్లే మార్గంతో సరిపోలదు.
సమాధానాలు ట్రాక్ చేసిన స్థితి లేదా స్పష్టమైన మార్గం ద్వారా అదే దిగువ క్లయింట్‌ను చేరాలి, మరియు బయటకు వెళ్లే ప్యాకెట్ కౌంటర్ అందులో ఏదీ నిరూపించదు. VPN యొక్క సొంత బాహ్య రవాణాను కూడా మినహాయింపు పరిధి వెలుపల ఉంచండి, లేకపోతే టన్నెల్ వాహక ప్యాకెట్‌లు క్లయింట్ వెబ్ అభ్యర్థన కోసం రాసిన విధానాన్ని వారసత్వంగా పొందుతాయి.
పట్టుబడిన ఒక చిరునామా గమ్యం కాదు
బ్రౌజర్ నుండి చదివిన ఒకే IPv4 చిరునామా ఒక క్షణ చిత్రం. పెద్ద సేవలు anycast నుండి లేదా తిరిగే అంచు చిరునామాల సమితి నుండి సమాధానమిస్తాయి, చాలా రెట్టింపు స్టాక్, మరియు లాగిన్ ప్రవాహం పేజీ ఎప్పటికీ చూపని ప్రామాణీకరణ మరియు టెలిమెట్రీ హోస్ట్‌లను తాకవచ్చు. మీరు యాదృచ్ఛికంగా చూసిన చిరునామా చుట్టూ నిర్మించిన మినహాయింపు తదుపరిసారి సేవ లోడ్‌ను తిరిగి సమతుల్యం చేసినప్పుడు విరిగిపోతుంది.
సేవ యజమాని డాక్యుమెంట్ చేసిన చిరునామాలను, లేదా అతను ప్రచురించే పరిధిని ఉపయోగించండి, మరియు రెండు చిరునామా కుటుంబాలను పరిగణించండి. అవసరాన్ని స్థిరమైన సమితిగా వ్యక్తపరచలేకపోతే, అది బహుశా సేవకు విధాన ప్రశ్న, ఫోన్‌లో రూటింగ్ ఉపాయం కాదు.
దిగువ వైపు నుండి ధృవీకరించండి
మూడు తనిఖీలు, ఈ క్రమంలో: ల్యాప్‌టాప్ నుండి ఎంచుకున్న సేవ, VPN లోపల ఉండాల్సిన సాధారణ గమ్యం, మరియు ప్రభావితం కాకూడని ఫోన్ యాప్. తర్వాత పునఃకనెక్షన్ తర్వాత మరియు పై లింక్ మారిన తర్వాత మళ్లీ చేయండి, ఎందుకంటే అప్పుడే విధాన పట్టికలు తిరిగి నిర్మించబడతాయి.
ఫోన్ షేరింగ్ అమలు పునఃకనెక్షన్ అంతటా ఆ ఒప్పందాన్ని నిలబెట్టుకోలేకపోతే, హ్యాండ్‌సెట్‌పై root నియమాలను కూడబెట్టడం బదులు ఎంపిక విధానాన్ని మద్దతు ఉన్న దిగువ రౌటర్‌కు తరలించండి. రౌటర్ స్థిర యజమానితో మూలం మరియు గమ్యం సరిపోలికను వ్యక్తపరచగలదు, మరియు టెథరింగ్ మాడ్యూల్ డాక్యుమెంటేషన్ ఫోన్ నిజంగా ఏమి చేస్తుందో దానికి సరైన సూచన.