Android DNS సరిగ్గా చదవండి: నెట్వర్క్ ప్రకారం, resolv.conf-లో కాదు

మీ Android యాప్ ప్రతి నెట్వర్క్ resolver ద్వారా పరిష్కరిస్తుంది, మీరు ఇప్పుడే చదివిన resolv.conf ద్వారా కాదు. మొదట LinkProperties, socket బైండింగ్లు మరియు Private DNS తనిఖీ చేయండి.

మీరు పరికరంలో shell తీసుకుంటారు, /etc/resolv.conf చదువుతారు లేదా పాత net.dns1 విలువను తవ్వి తీస్తారు, ఒక చిరునామా వస్తుంది. మీ ముందున్న యాప్ పూర్తిగా వేరే దాని ద్వారా పరిష్కరిస్తుంది. ప్రస్తుత Android విడుదలలో resolver నెట్వర్క్ ప్రకారం ఉంటుంది: సిస్టమ్ ప్రతి Network కోసం విధానాన్ని ఉంచి, అభ్యర్థన పంపిన socket-పై దాన్ని వర్తింపజేస్తుంది. ఫైల్ మరియు పాత లక్షణం మిగిలిన భాగాలు, వాటిలో ఏదీ మీ ప్రశ్న నిజంగా తీసుకున్న మార్గాన్ని వివరించదు.

ఈ అంతరం split-tunnel మరియు Private DNS ప్రవేశపెట్టేటప్పుడు కనిపిస్తుంది, ఇక్కడ ఒకే ఫోన్లోని రెండు యాప్లు చట్టబద్ధంగా వేర్వేరు సమాధానాలు చూడగలవు. ఈ మార్గదర్శిని తప్పు లేదా లేని పరిష్కారం నుంచి మొదలై, అది యాజమాన్యం ఉన్న కాన్ఫిగరేషన్ వైపు తిరిగి వెళ్తుంది.

resolver ఒక నెట్వర్క్కు చెందుతుంది, పరికరానికి కాదు

Android 9 మరియు ఆ తర్వాత పేర్ల పరిష్కారం socket కలిసిన Network ఆధారంగా ఉండే సిస్టమ్ resolver గుండా జరుగుతుంది. ప్రతి నెట్వర్క్ తన సొంత LinkProperties కలిగి ఉంటుంది, ఆ లక్షణాలు ఆ నెట్వర్క్ కోసం మాత్రమే DNS సర్వర్ జాబితా, శోధన డొమైన్లు మరియు Private DNS స్థితిని ఉంచుతాయి. ఆ నమూనాలో ఫైల్ నుంచి చదవగల ఒకే పరికర-వ్యాప్త జాబితాకు సరిపోయేది ఏదీ లేదు.

VPN ఈ విభజనను స్పష్టం చేస్తుంది. టన్నెల్ పైకి వచ్చినప్పుడు VPN యాప్ VPN యొక్క సొంత నెట్వర్క్లో నమోదైన DNS సర్వర్లను అందిస్తుంది, కాబట్టి దాని గుండా మార్గనిర్దేశం చేయబడిన యాప్లు ఆ సర్వర్లపై పరిష్కరిస్తాయి, మినహాయించిన యాప్లు కింది నెట్వర్క్ను ఉపయోగిస్తూనే ఉంటాయి. ఒక పరికరం, రెండు సమాధాన మార్గాలు, విరుద్ధత లేదు.

స్నాప్షాట్ను ప్రభావిత యాప్ లోపలి నుంచి చదవండి

యాప్నునే అడగండి. Context మరియు సాధారణ android.permission.ACCESS_NETWORK_STATE అనుమతి ఉన్న పద్ధతి సిస్టమ్ లక్షణాలను తాకకుండా స్నాప్షాట్ను చదవగలదు:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork మీ ప్రక్రియ యొక్క డిఫాల్ట్ నెట్వర్క్, పరికరంలోని ఏకైక నెట్వర్క్ కాదు, కాలర్కు ఉపయోగకరమైన డిఫాల్ట్ లేనప్పుడు null కావచ్చు. బ్లాక్ చేయబడిన డిఫాల్ట్ VPN సాధారణ కారణం. isPrivateDnsActive ఆ నెట్వర్క్ ప్రశ్నలు TLS ద్వారా పేరున్న resolverకు వెళ్తాయా అని చెబుతుంది, ఇది సాధారణ UDP 53 పరీక్ష ఏమి చూపుతుందో మారుస్తుంది. API ఉపరితలం LinkProperties కింద నమోదు చేయబడింది, అందులో ప్రతి విలువ కాన్ఫిగరేషన్ యొక్క స్నాప్షాట్, నిర్దిష్ట ప్రశ్న నిర్దిష్ట సర్వర్ను చేరిందని రుజువు కాదు.

డిఫాల్ట్ నెట్వర్క్ పని చేసే నెట్వర్క్ కానప్పుడు

స్నాప్షాట్ డిఫాల్ట్ కోసం మాత్రమే సమాధానం ఇస్తుంది. యాప్ తన ప్రక్రియను లేదా ఒక socketను మరో నెట్వర్క్కు కట్టవచ్చు, అప్పుడు పరిష్కారం ఆ ఎంపికను అనుసరిస్తుంది, మీ నిర్ధారణ ఇంకా డిఫాల్ట్ను నివేదిస్తుంది. తన సొంత DNS-over-HTTPS resolver తెచ్చుకునే బ్రౌజర్ సిస్టమ్ జాబితాను అసలు అడగదు, కాబట్టి దాని సమాధానాలు మిగిలిన పరికరం గురించి ఏమీ చెప్పవు. పని ప్రొఫైల్ యాప్ తన విధానంతో వేరే వినియోగదారు కింద నడుస్తుంది. సర్వర్లను నిందించే ముందు బైండింగ్ను తనిఖీ చేయండి.

VPN ఏకీకరణ రెండో సగం. dhcp-option DNS పంక్తిని OpenVPN ప్రొఫైల్లో స్వీకరించడం, ఆ చిరునామాను Android VPN నెట్వర్క్లో నమోదు చేయడం రెండు వేర్వేరు దశలు, సర్వర్కు దారి లేకపోవడం తప్పు చిరునామా లాగానే నిశ్శబ్దంగా విఫలమవుతుంది. అభివృద్ధి యంత్రం నుంచి adb shell dumpsys connectivity build అనుమతించినప్పుడు అదే లింక్ లక్షణాలను నెట్వర్క్ ప్రకారం ముద్రిస్తుంది, ఇది కోడ్ రాయకుండానే జాబితాను నిర్ధారిస్తుంది.

కాన్ఫిగరేషన్ను మీకు అనుమతి ఉన్న ఒక పరిష్కారంతో పోల్చండి

ప్రైవేట్ పేరు స్థలంలో పరిష్కరించబడాల్సిన పేరు మరియు ఒక పబ్లిక్ పేరు ఎంచుకోండి, రెండు ఫలితాలను స్నాప్షాట్ పక్కన రాయండి: నెట్వర్క్, కాన్ఫిగర్ చేసిన సర్వర్లు, Private DNS స్థితి మరియు లోపం యొక్క ఖచ్చితమైన పాఠ్యం. పేరున్న సర్వర్కు నేరుగా ప్రశ్న ఆ సర్వర్ మీకు సమాధానం ఇస్తుందని రుజువు చేస్తుంది; సాధారణ యాప్ పరిష్కారం దాన్ని ఎంచుకుందని రుజువు చేయదు. కాష్లోని సమాధానం తాజా పరీక్ష కాదు, కాబట్టి కాష్ను ఖాళీ చేయండి లేదా ఈరోజు ఎవరూ అడగని పేరును ఉపయోగించండి.

resolver నిర్దిష్ట యాక్సెస్ నెట్వర్క్ క్లయింట్లకు మాత్రమే సేవ చేస్తే, VPN నిష్క్రమణ తర్వాత అది చూసేది ఫలితాన్ని నిర్ణయించవచ్చు, ఇది దాన్ని నడిపేవారికి విధాన ప్రశ్న, ఆపరేటర్లు UDP 53ను బ్లాక్ చేస్తారని రుజువు కాదు. Private DNS యాక్టివ్గా ఉన్న చోట అసంపూర్ణ హోస్ట్ పేరు రూపకల్పన ప్రకారం తిరస్కరించబడవచ్చు, అదే సర్వర్ పబ్లిక్ పేర్లకు సాధారణంగా సమాధానం ఇస్తుంది. లక్షణాలను చదవడం ఏ మోడ్ అమలులో ఉందో చెబుతుంది, కాబట్టి మీరు ప్యాకెట్ ఫిల్టర్లను ఊహించడం మానేస్తారు.

ఈ అసంగతి ఏ పొరకు చెందుతుందో దాన్ని సరిచేయండి

గ్లోబల్ స్థితిని మార్చడం బదులు పైకి పని చేయండి. యాప్ తప్పు నెట్వర్క్కు కట్టబడి ఉంటే బైండింగ్ను సరిచేయండి. ప్రొఫైల్ తప్పు DNS ఎంపిక ఇస్తే ప్రొఫైల్ను సరిచేయండి. ఏ నెట్వర్క్ resolver మీ ప్రైవేట్ జోన్కు సేవ చేయలేదో అక్కడ Private DNS కఠినంగా ఉంటే, అది పరికర నిర్వహణ నిర్ణయం, ప్రతిచోటా ఫీచర్ను ఆపేయడానికి కారణం కాదు.

పబ్లిక్ resolverలను DHCP హుక్ లేదా సిస్టమ్ లక్షణంలోకి తోయడం నిరంతరం సంఘటనలు సృష్టించే మరమ్మత్తు: ప్రైవేట్ పేర్లు పరిష్కారం కావడం ఆగిపోతుంది, మార్పు VPN సెషన్ను దాటి నిలిచి ఉంటుంది, పరికరంలో తదుపరి వ్యక్తికి యజమాని లేని పాత చిరునామా కనిపిస్తుంది. మార్పును VPN, యాప్ లేదా ఈ అసంగతి యాజమాన్యం ఉన్న నిర్వహణ పొర లోపల ఉంచండి, తర్వాత స్నాప్షాట్ను మళ్లీ చదివి సర్వర్ జాబితా నిజంగా మారిందని నిర్ధారించండి.

చివరిలో మీకు ఒక నెట్వర్క్, resolver జాబితా మరియు Private DNS స్థితికి కట్టబడిన ఒక యాప్ అభ్యర్థన కావాలి. ఈ గొలుసును చూపగలిగినప్పుడు, ఫైల్లోని తెలిసిన చిరునామా ఏదానికీ రుజువు కాదు.

సంబంధిత వ్యాసాలు