Android always-on VPN: ఎండ్పాయింట్ పేరు మొదట ఎలా పరిష్కరించబడుతుంది
టన్నెల్ ఉనికిలోకి రాకముందే Android ట్రాఫిక్ను నిరోధిస్తుంది, అయినా క్లయింట్ తన ఎండ్పాయింట్ను పరిష్కరించాలి. ఇదిగో క్రమం మరియు చిక్కుకునే చోటు.
ఫోన్ రీబూట్ అవుతుంది, always-on సక్రియంగా ఉంది, «VPN లేకుండా కనెక్షన్లను నిరోధించు» ఆన్లో ఉంది, కానీ టన్నెల్ ఎప్పటికీ రాదు. ఏదీ తప్పుగా కాన్ఫిగర్ చేయబడలేదు: నిరోధం తన పని చేస్తోంది, క్లయింట్ స్వయంగా తన ఎండ్పాయింట్ను చేరుకోవాలని ప్రయత్నించడం కూడా దానికి లోబడి ఉంటుంది. ఎండ్పాయింట్ పేరు టన్నెల్ ఉనికిలోకి రాకముందే పరిష్కరించబడాలి, మిగిలిన అన్ని యాప్లకు అనుమతి లేనప్పుడు నెట్వర్క్తో మాట్లాడే అనుమతి ఉన్న క్లయింట్ ద్వారా. ఏ భాగం ఇలా చేస్తుంది, ఏ క్రమంలో అనేది అర్థం చేసుకోవడమే ఈ రహస్యాన్ని కాన్ఫిగరేషన్ ప్రశ్నగా మారుస్తుంది.
VPN బిల్డర్ నిజంగా ఏమి అడుగుతుంది
Android VPN యాప్ ప్లాట్ఫారమ్కు సర్వర్ చిరునామాను ఇవ్వదు. అది స్థానిక ఇంటర్ఫేస్ను నిర్మిస్తుంది: టన్నెల్ కోసం చిరునామాలు మరియు మార్గాలు, దాని లోపల యాప్లు ఉపయోగించాల్సిన రిజాల్వర్లు, ఆ తర్వాత establish() ఫైల్ డిస్క్రిప్టర్ను తిరిగి ఇస్తుంది, దాన్ని యాప్ ముడి IP ప్యాకెట్లుగా చదువుతుంది మరియు రాస్తుంది. రిమోట్ ఎండ్పాయింట్ ఆ బిల్డర్లో అసలు కనిపించదు.
ఇదే ప్రధాన నిర్మాణ వాస్తవం. ప్లాట్ఫారమ్ tun ఇంటర్ఫేస్ను సృష్టించి దానిపై విధానాన్ని అమలు చేస్తుంది; యాప్ వినియోగదారు స్థలంలో రవాణాను అమలు చేస్తుంది, అంటే ఎండ్పాయింట్ పేరును పరిష్కరించడం మరియు గుప్తీకరించిన కనెక్షన్ను తెరవడం యాప్ స్వయంగా చేస్తుంది. అందువల్ల హోస్ట్ పేరు రూపంలో ఎండ్పాయింట్ సాధ్యం — ప్లాట్ఫారమ్ పేర్లకు మద్దతు ఇస్తుందని కాదు, ప్లాట్ఫారమ్ ఎండ్పాయింట్ను ఎప్పటికీ చూడదని.
బిల్డర్లోని ఒక ఫీల్డ్ మాత్రం చిరునామాలను తీసుకుంటుంది: DNS సర్వర్లు. అవి సంఖ్యాత్మక రిజాల్వర్ చిరునామాలు ఉండాలి, సాధారణంగా ఆపరేటర్ టన్నెల్ ద్వారా అడగాలనుకునేవి. ఆ ఫీల్డ్ టన్నెల్ వచ్చిన తర్వాత యాప్లు క్వెరీలను ఎక్కడికి పంపుతాయో వివరిస్తుంది. క్లయింట్ ఎండ్పాయింట్ను ఎలా కనుగొంటుందో ఏమీ చెప్పదు, ఈ రెండింటినీ ఒకే సెట్టింగ్గా పరిగణించడం నుంచే గందరగోళం మొదలవుతుంది.
ఒకటి కాదు, రెండు DNS ప్రశ్నలు
మొదటి ప్రశ్న: టన్నెల్ వచ్చిన తర్వాత యాప్లు క్వెరీలను ఎక్కడికి పంపుతాయి? సమాధానం టన్నెల్ లోపలి రిజాల్వర్ చిరునామా, tun ఇంటర్ఫేస్ ద్వారా చేరుకోగలిగేది, మరియు నిర్మాణం ప్రకారం సంఖ్యాత్మకం.
రెండవ ప్రశ్న: ఆ టన్నెల్ ఉనికిలోకి రాకముందు క్లయింట్ తన సొంత ఎండ్పాయింట్ను ఎలా కనుగొంటుంది? ఆ అన్వేషణ టన్నెల్ వెలుపల, అంతర్లీన నెట్వర్క్లో, క్లయింట్ ప్రాసెస్లో జరుగుతుంది. అది పేరును ఉపయోగించవచ్చు, మరియు VPN లేకుండా పరికరం చేరుకోగల రిజాల్వర్ను ఉపయోగించాలి.
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
మూడు దశలు, మూడు వేర్వేరు లక్షణాలు. «కనెక్ట్ చేయలేము» అనే ఒకే లోప సందేశం వాటిని ఒకటిగా కలిపేస్తుంది, అందుకే ఆ ఫీల్డ్ చదవడానికి ముందే జరిగే సమస్యను సరిచేయడానికి ప్రజలు DNS సర్వర్ ఫీల్డ్ను సవరించడం మొదలుపెడతారు.
bootstrap ఎందుకు చిక్కుకోవచ్చు
always-on లో నిరోధం ఆన్లో ఉంటే VPN లోపల లేని ట్రాఫిక్ విస్మరించబడుతుంది, VPN ఉన్న యాప్ ట్రాఫిక్ కూడా. బయటకు వెళ్లే మార్గం స్పష్టంగా ఉంది: యాప్ ఒక సాకెట్పై protect() పిలుస్తుంది, అది దాన్ని అంతర్లీన నెట్వర్క్కు కట్టివేస్తుంది, తద్వారా అది టన్నెల్ను దాటవేసి బయటకు వెళ్లడానికి అనుమతి పొందుతుంది. ప్రతి VPN క్లయింట్ తన రవాణా కోసం ఇలా చేయాలి, లేకపోతే సర్వర్ను ఎప్పటికీ చేరుకోదు.
ఇప్పుడు ఎండ్పాయింట్ పేరు తెలిసిన ఏకైక రిజాల్వర్ స్వయంగా టన్నెల్ లోపల ఉన్న అమరికను పరిశీలించండి. పేరును పరిష్కరించడానికి క్లయింట్కు టన్నెల్ కావాలి, టన్నెల్ నిర్మించడానికి పేరు కావాలి. ఇది నిజమైన చక్రీయ ఆధారత, ఏ క్లయింట్ కాన్ఫిగరేషన్ దీన్ని పరిష్కరించదు. ఇది డిజైన్ లోపం, బగ్ కాదు.
సమయం అదే ఆధారతను మృదువైన రూపాల్లో వెల్లడిస్తుంది. బూట్ సమయంలో, మొదటి అన్లాక్కు ముందు, పరికరానికి ఇంకా ఉపయోగపడే నెట్వర్క్ ఉండకపోవచ్చు; captive portal లో నెట్వర్క్ ఉంది కానీ పోర్టల్ తప్ప మిగతావన్నీ నిరోధిస్తుంది; Wi-Fi నుంచి మొబైల్కు మారేటప్పుడు రక్షిత సాకెట్ అంతర్లీన నెట్వర్క్ మారుతుంది, క్లయింట్ దాన్ని గమనించి మళ్లీ పరిష్కరించాలి. వీటిలో ప్రతిదీ bootstrap సంఘటన, ప్రతిదీ రాత్రి 3 గంటలకు కనుగొనడం కంటే ఉద్దేశపూర్వకంగా పరీక్షించదగినది.
సమాధానాన్ని స్థిరపరచడం ఎందుకు పరిష్కారం కాదు
ఆకర్షణీయమైన దారి పేరును ఒకసారి పరిష్కరించి వచ్చిన చిరునామాను సంఖ్యా ఫీల్డ్లో అతికించడం, లేదా అనుకూల బిల్డ్లో హార్డ్కోడ్ చేయడం. అది పనిచేస్తున్నట్టు కనిపిస్తుంది, పేరును ఫోటోగా మారుస్తుంది. ఆపరేటర్ ఎండ్పాయింట్ను తరలించినప్పుడు — స్థానభ్రంశం, anycast మార్పు, కొత్త ప్రాంతీయ చిరునామా — క్లయింట్ పాతదాన్నే కాల్ చేస్తూనే ఉంటుంది, UI లో ఎక్కడా కారణం వివరించబడదు.
DNS రికార్డులకు జీవితకాలం ఉండటం సమాధానాలు మారగలవు అనే కారణం కోసమే; కాషింగ్ ఆ కాలవ్యవధి ఆధారంగా నిర్వచించబడుతుంది, శాశ్వతంగా కాదు. సమాధానాన్ని స్థిరపరచడం పేరును చిరునామా కంటే మెరుగ్గా చేసే యంత్రాంగాన్ని పారేస్తుంది, అదే సమయంలో పేరును ఉపయోగించిన నిర్వహణ వ్యయాన్ని నిలుపుకుంటుంది.
స్థిరపరచడం సాధారణంగా రెండవ చెడు అలవాటుతో కలిసి వస్తుంది: కనెక్షన్ ఇప్పుడు వేరే విధంగా విఫలమవుతున్నందున గుర్తింపు తనిఖీలను సడలించడం. సర్వర్ గుర్తింపు ధృవీకరణ bootstrap సమస్యలో భాగం కాదు, దాన్ని బలహీనపరచడం DNS ఇబ్బందిని అడ్డగింపు ప్రమాదంతో మారుస్తుంది.
పునఃప్రారంభాన్ని తట్టుకునే డిజైన్లు
నిలకడైన ఏర్పాటు ఆకర్షణీయంగా ఉండదు. రక్షిత సాకెట్లను సరిగ్గా అమలు చేసి తన ఎండ్పాయింట్ను అంతర్లీన నెట్వర్క్లో పరిష్కరించే క్లయింట్ను ఉపయోగించండి, మరియు దానికి బహిరంగంగా లేదా టన్నెల్ ముందు చేరుకోగల రిజాల్వర్ ద్వారా పరిష్కరించబడే ఎండ్పాయింట్ పేరును ఇవ్వండి. నిరోధాన్ని ఆన్లో ఉంచండి; DNS పనిచేయడానికి దాన్ని పూర్తిగా ఆఫ్ చేయడం ఆ అమరిక ఉనికికి కారణమైన లక్షణాన్ని తొలగిస్తుంది.
ఎండ్పాయింట్ ప్రైవేట్గా ఉండాల్సిన చోట, ప్లాట్ఫారమ్ ఉపయోగించగల స్పష్టమైన bootstrap మార్గాన్ని ఇవ్వండి — టన్నెల్ లేకుండా చేరుకోగల రిజాల్వర్, లేదా ఆపరేటర్ నిర్వహించే నిర్వహణ కనెక్షన్ — మరియు ఆ మినహాయింపును ఇరుకుగా ఉంచి, వినియోగదారు టోగుల్కు కాకుండా విధానానికి చెందినదిగా చేయండి. Android VpnService పత్రాలు రక్షణ మరియు జీవిత చక్రం గురించి ప్లాట్ఫారమ్ ఏమి హామీ ఇస్తుందో తెలిపే సూచన, మరియు VpnService.Builder సూచన DNS ఫీల్డ్ సంఖ్యాత్మక చిరునామాలను తీసుకుంటుందని నిర్ధారిస్తుంది.
తర్వాత పునఃప్రారంభం తర్వాత కొత్త కనెక్షన్పై మూడు దశలను క్రమంగా ధృవీకరించండి: ఎండ్పాయింట్ పేరు పరిష్కరించబడుతుంది, టన్నెల్ ఏర్పడి సహచరుడు ప్రామాణీకరించబడతాడు, మరియు ప్రైవేట్ పేరు టన్నెల్ రిజాల్వర్ ద్వారా పరిష్కరించబడుతుంది. మొదటి దశ విఫలమైతే తర్వాత ఏదీ పనిచేయదు, మరియు సరిదిద్దడం bootstrap మార్గానికి చెందుతుంది — ఎప్పటికీ రిజాల్వర్ ఫీల్డ్కు కాదు.
- ఎండ్పాయింట్ పరిష్కరణ యాప్ లోపల, టన్నెల్ వెలుపల, రక్షిత సాకెట్పై జరుగుతుంది.
- బిల్డర్లోని DNS ఫీల్డ్ టన్నెల్ లోపలి యాప్ల కోసం, క్లయింట్ సొంత ఎండ్పాయింట్ కోసం కాదు.
- టన్నెల్ ద్వారా మాత్రమే చేరుకోగల రిజాల్వర్ అనేది చిక్కు, నెమ్మదైన ప్రారంభం కాదు.
- పునఃప్రారంభం తర్వాత ఎండ్పాయింట్, ప్రామాణీకరణ, ప్రైవేట్ శోధనలను విడివిడిగా పరీక్షించండి.