resolv.conf మీ VPN DNS ను చూపుతుంది కానీ శోధనలు దాన్ని విస్మరించడం ఎందుకు

లాగ్లలో ఏదీ తప్పుగా కనిపించడం లేదు: ఇంటర్ఫేస్ నడుస్తోంది, రిజాల్వర్ VPN యొక్క DNS సర్వర్ను నివేదిస్తోంది, డిస్క్లోని ఫైల్ దాన్ని జాబితా చేస్తోంది. అయినప్పటికీ అంతర్గత హోస్ట్ పేరు ఇప్పటికీ స్థానిక రౌటర్ ద్వారా పరిష్కరించబడుతోంది. ఈ మూడు ప్రకటనలు ఒకదానికొకటి విరుద్ధం కావు, ఎందుకంటే ఫైల్, ప్రతి లింక్ స్థితి మరియు శోధన మార్గం యాదృచ్ఛికంగా ఒకే పేరును పంచుకునే వేర్వేరు వస్తువులు. క్రింద systemd-resolved ఉన్న హోస్ట్లో క్వెరీ నిజంగా నడిచే మార్గం వివరించబడింది.

resolv.conf అనే మూడు వస్తువులు

resolved ఉన్న హోస్ట్లో /etc/resolv.conf సాధారణంగా /run/systemd/resolve/stub-resolv.conf కు సింబాలిక్ లింక్. ఆ లక్ష్యంలో స్థానిక stub శ్రోత యొక్క చిరునామా, 127.0.0.53, మరియు resolved లెక్కించిన శోధన డొమైన్లు ఉంటాయి. ఇది స్థితి యొక్క దృశ్యం, స్థితి కాదు.

స్థితి resolved యొక్క ప్రతి లింక్ కాన్ఫిగరేషన్లో నివసిస్తుంది, అందుకే resolvectl status ఫైల్తో విభేదించినా సరైనదిగా ఉండగలదు. ప్రతి లింక్ తన సొంత సర్వర్లను, తన సొంత రౌటింగ్ డొమైన్లను మోసుకెళుతుంది, క్వెరీ వచ్చినప్పుడు stub ఆ డేటాను సంప్రదిస్తుంది. systemd-resolved మాన్యువల్ సృష్టించిన ఫైల్లను, ప్రతి లింక్ నమూనాను వివరిస్తుంది; దృశ్యం మరియు స్థితి మధ్య విభజన గుర్తుంచుకోదగిన భాగం. సింబాలిక్ లింక్ లక్ష్యాన్ని మార్చడం సాంప్రదాయ క్లయింట్లు చదివేదాన్ని మారుస్తుంది, రిజాల్వర్కు తెలిసినదాన్ని కాదు.

మూడవ వస్తువు, /run/systemd/resolve/resolv.conf, ప్రతి లింక్ను ఒకే సర్వర్ జాబితాగా చదును చేస్తుంది. ఆ ఫైల్ వైపు చూపిన ప్రోగ్రామ్ క్వెరీలను నేరుగా జాబితా చేసిన సర్వర్లకు పంపి stub ను దాటవేస్తుంది, కాబట్టి ప్రతి లింక్ విధానం ఇక దానికి వర్తించదు. అందువల్ల ఒకే యంత్రంలోని రెండు ప్రోగ్రామ్లు ఒకే పేరుకు వేర్వేరుగా సమాధానం ఇవ్వగలవు, ఏదీ పాడైనది కాదు.

NSS ద్వారా ఒక శోధనను అనుసరించండి

పేరుకు ఎవరు సమాధానం ఇస్తారో నిర్ణయించడానికి glibc /etc/nsswitch.conf చదువుతుంది. resolve ఉన్న hosts పంక్తి ప్రశ్నను nss-resolve కు పంపుతుంది, అది D-Bus ద్వారా resolved ను అడిగి ప్రతి లింక్ సమాధానాన్ని పొందుతుంది. files dns మాత్రమే ఉన్న పంక్తి క్వెరీని /etc/resolv.conf కలిగి ఉన్న చిరునామాకు పంపుతుంది.

ఆ ఒకే పంక్తి బ్రౌజర్ మరియు dig మధ్య చాలా విభేదాలను వివరిస్తుంది. dig నేరుగా resolv.conf చదువుతుంది మరియు NSS ను ఎప్పుడూ తాకదు, కాబట్టి అప్లికేషన్ ఉపయోగించే మార్గానికి బదులుగా stub లేదా పై సర్వర్ను పరీక్షిస్తుంది. getent hosts internal.example NSS గుండా వెళుతుంది, దాని సమాధానాన్ని dig సమాధానంతో పోల్చడం మొదటి ఉపయోగకరమైన కొలత.

తమ సొంత రిజాల్వర్ను తెచ్చుకునే లేదా స్థిర ఎండ్పాయింట్కు HTTPS పై DNS మాట్లాడే అప్లికేషన్లు రెండు మార్గాలను దాటవేస్తాయి. resolv.conf లో లేదా resolved స్థితిలో ఏదీ వాటిని పరిమితం చేయదు.

ఫైల్ ఎవరిది మరియు ఎటువైపు చూపుతుందో తనిఖీ చేయండి

ఏదైనా మార్చే ముందు లింక్ గొలుసును చదవండి, ఎందుకంటే ఏ ఫైల్ అధికారికమో యాజమాన్యం నిర్ణయిస్తుంది. క్రింది ప్రతి ఆదేశం స్థితిని మాత్రమే చదువుతుంది.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

మొదటి పంక్తి లింక్ మరియు దాని లక్ష్యాన్ని కలిసి ముద్రిస్తుంది, VPN స్క్రిప్ట్ యాజమాన్యంలోని సాధారణ ఫైల్ అంటే రిజాల్వర్ ఆ రాతను ఎప్పుడూ ఇన్పుట్గా పరిగణించదు. స్థితి అవుట్పుట్ ప్రతి లింక్ సర్వర్లను మరియు ప్రతి క్వెరీ ఎక్కడికి వెళుతుందో నిర్ణయించే రౌటింగ్ డొమైన్లను జాబితా చేస్తుంది. nsswitch పంక్తి stub ను అసలు సంప్రదిస్తారా అని చెబుతుంది, కాబట్టి ఫైల్లో stub చిరునామా ఉన్నా అక్కడ resolve లేకపోతే క్వెరీలు స్థానిక శ్రోతను చేరుతాయి కానీ విభజనను ఏదీ నిర్వహించదు. ఆ చివరి జాబితా కూడా ముఖ్యం, ఎందుకంటే stub-resolv.conf లేని హోస్ట్ ఇక్కడ వివరించిన ఏర్పాటును నడపదు.

గొలుసు మరొక ప్యాకేజీ నిర్వహించే ఫైల్లో ముగిస్తే, VPN క్లయింట్ మరియు ఆ ప్యాకేజీ సమన్వయం చేయాల్సిన ఇద్దరు యజమానులు. లింక్ను భర్తీ చేయడం ఒక యజమాని పనిని పారేసి మరొకరి పనిని దాని స్థానంలో వదిలిస్తుంది.

లింక్ యజమాని వద్ద సరిచేయండి

VPN కనెక్షన్ తన సర్వర్లను, డొమైన్లను తన లింక్పై నమోదు చేసి, తర్వాత డిస్కనెక్ట్ అయినప్పుడు వాటిని ఉపసంహరించుకోవాలి. NetworkManager యొక్క resolved ఇంటిగ్రేషన్ మరియు క్లయింట్ సొంత సహాయకుడు రెండూ అలాగే పని చేస్తాయి; resolv.conf ను మాత్రమే తిరిగి రాసే స్క్రిప్ట్ అలా చేయదు.

ఇప్పటికే ఉన్న లింక్పై, రన్టైమ్ సెట్టింగ్లు యంత్రాంగాన్ని చూపుతాయి. resolvectl dns tun0 10.40.0.53 ఒక సర్వర్ను జోడిస్తుంది, resolvectl domain tun0 '~corp.example' ఒక రౌటింగ్ డొమైన్ను జోడిస్తుంది. టిల్డా (~) భారం మోసే అక్షరం: అది ఆ ప్రత్యయం క్వెరీలను ఈ లింక్కు పరిమితం చేసి మిగతావన్నీ ప్రశాంతంగా వదిలిస్తుంది, అది లేకుండా అదే విలువ శోధన డొమైన్ అయి విభజన ఆవిరైపోతుంది. ఆ చిరునామాలు ల్యాబ్ ఉదాహరణలు, శాశ్వత కాన్ఫిగరేషన్ కాదు. resolvectl query host.corp.example తో ధృవీకరించి ఏ లింక్ సమాధానం ఇచ్చిందో చదవండి.

నమోదైన సర్వర్కు ఇప్పటికీ మార్గం కావాలి. క్వెరీ సరైన లింక్ను చేరి సమయం ముగిస్తే, లోపం రిజాల్వర్ యాజమాన్యంలో కాదు, సొరంగం ద్వారా చేరుకోవడంలో ఉంది.

పని చేసే స్థితి ఎలా ఉంటుంది

ఆరోగ్యకరమైన ఫలితం మూడు దృశ్యాలలో సుసంగతంగా ఉంటుంది: ప్రతి లింక్ సర్వర్లు VPN ఇచ్చిన వాటితో సరిపోతాయి, రౌటింగ్ డొమైన్లు అంతర్గత ప్రత్యయాలను మాత్రమే కవర్ చేస్తాయి, ముఖ్యమైన అప్లికేషన్ అంతర్గత పేరును పరిష్కరిస్తుంది అదే సమయంలో పబ్లిక్ పేరు ఇప్పటికీ స్థానిక మార్గాన్ని అనుసరిస్తుంది. ఒక విజయవంతమైన క్వెరీ ఆ ఏకీభావం కంటే తక్కువ నిరూపిస్తుంది.

తర్వాత డిస్కనెక్ట్ చేసి రెండు క్వెరీలను పునరావృతం చేయండి. తీసివేత తర్వాత తన డొమైన్లను నమోదైనవిగా వదిలే క్లయింట్ కొన్ని గంటల తర్వాత అంతర్గత శోధనలలో విఫలమయ్యే యంత్రాన్ని సృష్టిస్తుంది, తెరిచిన సొరంగం మరియు స్పష్టమైన కారణం లేకుండా.