మీ /etc/hosts నమోదు VPN యొక్క DNS ను ఎందుకు చేరుకోదు

మీరు /etc/hosts కు ఒక పేరును జోడించారు, VPN కు కనెక్ట్ అయ్యారు మరియు రికార్డ్ అందరికీ కనిపిస్తుందని ఆశించారు. అలా జరగదు, మరియు ఆశ్చర్యం సాధారణంగా రెండవ లక్షణంతో వస్తుంది: పేరు మీ మెషీన్‌లో పరిష్కరించబడుతుంది మరియు సహోద్యోగి మెషీన్‌లో విఫలమవుతుంది, ఇది పాడైన VPN DNS సేవలా కనిపిస్తుంది మరియు వాస్తవానికి hosts ఫైల్ తన కోసం రూపొందించిన పనిని ఖచ్చితంగా చేస్తోంది. hosts ఫైల్ స్థానిక పేరు-పరిష్కార కాన్ఫిగరేషన్, జోన్ అప్‌డేట్ కాదు, మరియు సాధారణ VPN కనెక్షన్‌లో ఏదీ దాన్ని అప్‌లోడ్ చేయదు.

Hosts స్థానిక ఓవర్‌రైడ్, జోన్ అప్‌డేట్ కాదు

ఫైల్ అనేది DNS సర్వర్‌ను అడిగే ముందు లేదా దానికి బదులుగా పేరు సేవా లైబ్రరీలు చూసే మ్యాపింగ్‌ల జాబితా. 10.40.0.20 build.corp.example లాంటి పంక్తి ఆ ఒకే మెషీన్‌లోని అప్లికేషన్లు ఏ ముగింపుకు వస్తాయో మారుస్తుంది. ఇది రికార్డును సృష్టించదు, టన్నెల్ గుండా ప్రయాణించదు, మరియు టన్నెల్ సూచించే DNS సర్వర్‌కు ఇది ఉన్నట్లు తెలియదు.

అందుకే వైఫల్యం అసమానంగా ఉంటుంది. మీ క్లయింట్ ఫైల్ నుండి సమాధానం పొందుతుంది. మరో క్లయింట్ VPN యొక్క DNS సర్వర్‌ను అడుగుతుంది, అది ఏమీ తిరిగి ఇవ్వదు, మరియు అప్లికేషన్ పేరు లేదని నివేదిస్తుంది. రెండు మెషీన్లు సరిగ్గా ప్రవర్తిస్తున్నాయి; ఒకదానికి మాత్రమే మరొకటి ఎప్పుడూ చూడని ఓవర్‌రైడ్ ఉంది.

రెండు ఆదేశాలు, రెండు వేర్వేరు భాగాలు

ఈ చర్చను ఆపడానికి వేగవంతమైన మార్గం, భేదాన్ని రెండు ఆదేశాలలో కనిపించేలా చేయడం, రెండూ hosts నమోదు ఉన్న క్లయింట్‌పై అమలు చేయబడతాయి:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

మొదటిది సిస్టమ్ యొక్క స్వంత లుకప్ మార్గాన్ని అడుగుతుంది, ఇది సాధారణ glibc సిస్టమ్‌లో DNS కంటే ముందు స్థానిక ఫైళ్లను చదువుతుంది. రెండవది ఆ చిరునామాలోని సర్వర్‌కు నేరుగా DNS క్వెరీని పంపుతుంది మరియు స్థానిక ఫైళ్లను అసలు చూడదు. మొదటిది మీ నమోదును తిరిగి ఇచ్చినప్పుడు రెండవది NXDOMAIN ఇచ్చినప్పుడు, రికార్డ్ DNS లో లేదని మరియు మీ మెషీన్ స్థానిక ఓవర్‌రైడ్ నుండి సమాధానమిస్తోందని మీరు నిరూపించారు.

క్రమాన్ని కాన్ఫిగర్ చేయవచ్చు, మరియు నిర్దిష్ట పంపిణీ గురించి ఏదైనా నిర్ణయించే ముందు దాన్ని తనిఖీ చేయడం విలువైనది. /etc/nsswitch.conf లోని hosts: పంక్తిని చూడండి; hosts: files dns మొదట ఫైళ్లను చూస్తుంది. క్రమాన్ని మార్చడానికి మాత్రమే ఆ ఉదాహరణను పని చేస్తున్న కాన్ఫిగరేషన్‌పై కాపీ చేయవద్దు, ఎందుకంటే నిజమైన సిస్టమ్‌లు ఉదాహరణలో లేని అదనపు మూలాలు మరియు షరతులతో కూడిన సేవా నమోదులను తరచుగా జాబితా చేస్తాయి.

systemd-resolved పరీక్షను మసకబార్చుతుంది

systemd-resolved ఉపయోగించే సిస్టమ్‌లో స్థానిక స్టబ్ hosts డేటాబేస్ నుండి కూడా పేర్లను అందిస్తుంది. కాబట్టి 127.0.0.53 కు క్వెరీ చేయడం రిమోట్ సర్వర్ యొక్క స్వతంత్ర పరీక్ష కాదు, అది DNS క్వెరీలా కనిపించి అలాగే ప్రవర్తించినప్పటికీ. రిజాల్వర్ ఏమి తెలుసు మరియు ఏ సర్వర్లను అడుగుతుందో మీరు దీనితో నిర్ధారించవచ్చు:

resolvectl query build.corp.example
resolvectl status

status అవుట్‌పుట్ ప్రతి లింక్‌కు DNS సర్వర్లను పేర్కొంటుంది, అలా VPN లింక్‌కు రిజాల్వర్ లభించిందో లేదో తెలుస్తుంది. ఆ ప్రశ్న hosts నమోదు నుండి వేరు, ప్రైవేట్ పేరు ఒకరికి కాకుండా ప్రతి వినియోగదారుకు విఫలమైనప్పుడు అడగదగిన ప్రశ్న అదే.

అప్లికేషన్లు మరో పొరను జోడించవచ్చు. తన సొంత DNS-over-HTTPS సెట్టింగ్ ఉన్న బ్రౌజర్, తన సొంత రిజాల్వర్ కాన్ఫిగరేషన్ ఉన్న కంటైనర్, లేదా ప్రాసెస్ మొత్తం జీవితకాలంలో లుకప్‌లను కాష్ చేసే రన్‌టైమ్ ప్రతి ఒక్కటి సిస్టమ్ నుండి భిన్నంగా సమాధానమివ్వగలవు. ఒక ఆదేశం మెషీన్‌లోని ప్రతి ప్రోగ్రామును వివరిస్తుందని ఊహించడం బదులు మీకు ముఖ్యమైన అప్లికేషన్‌ను పరీక్షించండి.

VPN అంతటా పేరును నిజంగా ఏది పంచుకుంటుంది

ప్రైవేట్ పేరు అందరికీ పని చేయాలంటే, అందరి రిజాల్వర్ చేరుకోగల యజమాని అవసరం. స్పష్టమైన సమాధానం, రికార్డును నిర్వహిత జోన్‌లో ప్రచురించి ఆ జోన్‌ను VPN యొక్క ఉద్దేశిత DNS మార్గం ద్వారా పరిష్కరించగలిగేలా చేయడం. అప్పుడు రికార్డుకు ఒకే సత్య మూలం, ఆడిట్ ట్రైల్ మరియు జీవిత చక్రం ఉంటాయి, ఏ ల్యాప్‌టాప్‌లో స్థానిక ఓవర్‌రైడ్ ఉందో ఎవరూ గుర్తుంచుకోవాల్సిన అవసరం లేదు.

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

డైనమిక్ DNS నమోదు మూడవ యంత్రాంగం, దాని స్వంత అనుమతులు, అప్‌డేట్ ప్రామాణీకరణ మరియు రికార్డు జీవితకాలం ఉన్నాయి. ఇది hosts నమోదు నుండి రాదు, మరియు క్లయింట్ కేవలం కనెక్ట్ అవ్వడం నుండి కూడా రాదు, సర్వర్ మరియు క్లయింట్ రెండూ దాని కోసం కాన్ఫిగర్ చేయబడకపోతే. తనంతట తానుగా కనిపించే రికార్డు, ఎవరో సురక్షిత అప్‌డేట్‌లను ప్రారంభించారని మరియు క్లయింట్ తనను తాను నమోదు చేసుకుంటోందని సంకేతం, ఆ కాన్ఫిగరేషన్ ట్రబుల్‌షూటింగ్ థ్రెడ్‌లో కాదు, డిజైన్ రికార్డులో ఉండాలి. ఆ సెట్టింగ్ యజమాని ఎవరో ఎవరూ చెప్పలేకపోతే, స్వయంచాలక రికార్డును ధృవీకరించబడనిదిగా పరిగణించి నిర్వహిత జోన్‌ను సత్య మూలంగా ఉంచండి.

పరిష్కరించబడిన పేరు మార్గం కాదు

పేరు పరిష్కారం మరియు చేరుకోగల సామర్థ్యం వేర్వేరు, మరియు కాలం చెల్లిన స్థానిక మ్యాపింగ్ వాటిని గందరగోళపరచడానికి క్లాసిక్ మార్గం. మారిన చిరునామాను సూచించే hosts నమోదు DNS సరిదిద్దిన చాలా కాలం తర్వాత కూడా పాత హోస్ట్‌ను ఎంచుకుంటూనే ఉంటుంది, మరియు లక్షణం బాగా పరిష్కరించబడే పేరుపై రౌటింగ్ వైఫల్యంలా కనిపిస్తుంది.

కాబట్టి నివేదిక “పేరు పరిష్కరించబడుతుంది కానీ సేవ చేరుకోలేము” అని ఉన్నప్పుడు, సిస్టమ్ లుకప్‌ను VPN యొక్క DNS సర్వర్‌కు స్పష్టమైన క్వెరీతో పోల్చి, తర్వాత మీరు పొందిన చిరునామాను సేవ నిజంగా ఉపయోగించే చిరునామాతో తనిఖీ చేయండి. systemd-resolved సూచన అది చూసే స్థానిక మూలాలను డాక్యుమెంట్ చేస్తుంది, ఆ పోలికకు అవసరమైన మ్యాప్ అదే.

తర్వాత ఓవర్‌రైడ్‌ను దాని యజమాని ద్వారా సరిచేయండి. మీ సొంత hosts ఫైల్ నుండి ఒక పంక్తిని తీసేయడం, మోహరింపు స్క్రిప్ట్ నుండి అదే పంక్తిని పొందిన ఆ పన్నెండు ల్యాప్‌టాప్‌లకు ఏమీ చేయదు, మరియు ప్రజలు నిజంగా ఎదుర్కొనే ఈ సమస్య యొక్క సంస్కరణ అదే.