/etc/resolv.conf కోసం పోటీపడుతున్న రెండు Linux సేవలను ఆపండి

DNS పదే పదే పాత స్థితికి తిరిగి వస్తుంది, VPN తిరిగి కనెక్ట్ అవ్వడం మీ సవరణను రద్దు చేస్తుంది, చివరికి జట్టులో ఎవరో ఫైల్‌ను లాక్ చేయాలని సూచిస్తారు. ఆ క్రమం లక్షణం, పరిష్కారం కాదు: రెండు భాగాలు /etc/resolv.conf తమదే అని భావిస్తాయి, చివరగా రాసేదే గెలుస్తుంది. ఫైల్‌ను లాక్ చేయడం యాజమాన్య ఘర్షణను పరిష్కరించదు, దాన్ని దాచి అదే సమయంలో మీరు నిజంగా కోరుకున్న భాగాన్ని పాడు చేస్తుంది. క్రింది నాలుగు తనిఖీలను క్రమంగా చేయండి, ఫైల్‌పై కాకుండా దానిని కలిగి ఉన్న స్థాయిలో ఏర్పాటును సరిచేయండి.

తనిఖీ 1: ఇది సింబాలిక్ లింకా, ఎక్కడికి

ఫైల్ నుండే ప్రారంభించండి, ఎందుకంటే మీరు సవరిస్తున్న మార్గం ఫైల్ కాకపోవచ్చు. రిజాల్వర్ యొక్క రన్‌టైమ్ డైరెక్టరీకి వెళ్లే సింబాలిక్ లింక్, క్లయింట్ స్క్రిప్ట్ తిరిగి రాసే సాధారణ ఫైల్ కంటే పూర్తిగా భిన్నంగా ప్రవర్తిస్తుంది:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved యొక్క stub మార్గానికి లింక్ అంటే ఫైల్ కంటెంట్ ఉత్పత్తి అవుతుంది, మరియు చేతితో సవరణ తదుపరి సంఘటనలో పైన రాయబడుతుంది. nameserver పంక్తులున్న సాధారణ ఫైల్‌ను సాధారణంగా కనెక్ట్ అయ్యేటప్పుడు నడిచే క్లయింట్ లేదా DHCP హుక్ రాస్తుంది. రెండూ చెల్లుబాటు; ముఖ్యమైనది ఏదైనా మార్చే ముందు మీ వద్ద ఏది ఉందో తెలుసుకోవడం.

తనిఖీ 2: ఏ డీమన్ నడుస్తోంది

ఏది ఇన్‌స్టాల్ అయిందో కాదు, ఏది నిజంగా యాక్టివ్‌గా ఉందో కనుక్కోండి. ఆధునిక పంపిణీలో అనేక రిజాల్వర్‌లు ఉండవచ్చు, loopback ఇంటర్‌ఫేస్‌లో పోర్ట్ 53 ఉంచుకున్నదే సమాధానం ఇస్తుంది:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

స్థితి అవుట్‌పుట్ ప్రతి లింక్ DNS సర్వర్‌లను మరియు రూటింగ్ డొమైన్‌లను పేర్కొంటుంది, అదే split DNS కోసం మీకు అవసరమైన మ్యాప్. అంతర్గత పేర్లు అంతర్గత సర్వర్‌కు, మిగతావన్నీ పబ్లిక్ సర్వర్‌కు వెళ్లాలంటే, ఆ విధానం ప్రతి లింక్ డొమైన్‌లలో నివసిస్తుంది, దాన్ని ఫైల్‌లోని స్థిర nameserver జాబితాగా చదును చేయడం ఆ భేదాన్ని నిశ్శబ్దంగా కోల్పోతుంది.

NetworkManager యొక్క స్వంత కాన్ఫిగరేషన్ ఈ backend‌లలో ఏది ఉపయోగించాలో నిర్ణయిస్తుంది. ప్రధాన కాన్ఫిగరేషన్ ఫైల్‌లోని దాని dns= సెట్టింగ్ దాని అంతర్గత రిజాల్వర్, dnsmasq, systemd-resolved మరియు none మధ్య ఎంపిక చేస్తుంది, పంపిణీ మీ తరఫున ఎంచుకుని ఉండవచ్చు. ఈ హోస్ట్‌లో “DNS సరిచేయడం” అంటే ఏమిటో నిర్ణయించే ముందు ఆ సెట్టింగ్ చదవండి.

తనిఖీ 3: VPN క్లయింట్ ఏమి రాయడానికి అనుమతి ఉంది

ఘర్షణ సాధారణంగా ఇక్కడే నివసిస్తుంది. రిజాల్వర్ ఫైల్‌ను నేరుగా తిరిగి రాసే VPN క్లయింట్ దాన్ని కూడా నిర్వహించే ఏ సేవతో అయినా పోరాడుతుంది, ఓడిపోయేది మొదట నడిచేది. ఇటీవలి OpenVPN విడుదలలు ఫైల్‌ను తిరిగి రాయడం బదులు DNS సెట్టింగ్‌లను systemd-resolved కు అప్పగించగలవు, అదే మీరు కోరుకునే సహకార ప్రవర్తన; పాత స్క్రిప్ట్‌లు మరియు చేతితో రాసిన హుక్‌లు తరచుగా పాత సహాయక సాధనాన్ని పిలుస్తాయి లేదా ఫైల్‌పై నేరుగా రాస్తాయి.

WireGuard పరిస్థితి ఆకారంలో సమానం: ఇంటర్‌ఫేస్ కాన్ఫిగరేషన్ స్వయంగా DNS నిర్వహించదు, చుట్టూ ఉన్న సాధనాలు రిజాల్వర్ సహాయకుడు లేదా resolved ఇంటిగ్రేషన్ ద్వారా నిర్వహిస్తాయి. అలాంటి రెండు సహాయకులు ఇన్‌స్టాల్ అయి ఉంటే, రెండూ కనెక్ట్ అయ్యేటప్పుడు తమ ప్రపంచ దృష్టిని అమలు చేయడానికి ప్రయత్నిస్తాయి.

ఊహించడం బదులు క్లయింట్ యొక్క up మరియు down హుక్‌లను చదవండి. /etc/openvpn/up.sh లేదా సమానమైన డైరెక్టరీలోని కొన్ని shell పంక్తులు, లేకపోతే యాదృచ్ఛికంగా కనిపించే ప్రవర్తనను వివరిస్తాయి, క్లయింట్‌ను పోటీపడే బదులు సహకరించేలా చేసే స్థలం కూడా అదే.

తనిఖీ 4: యజమాని వద్ద సరిచేయండి, ఫైల్‌లో కాదు

యజమాని ఎవరో తెలిసిన తర్వాత, ఆ యజమాని మద్దతు ఇచ్చే ఇంటర్‌ఫేస్ ద్వారా DNS ను కాన్ఫిగర్ చేయండి. systemd-resolved కోసం ఇది స్థిర ఫైల్ బదులు ప్రతి లింక్ సెట్టింగ్‌లు మరియు రూటింగ్ డొమైన్‌లు; NetworkManager కోసం కనెక్షన్ ప్రొఫైల్ DNS సెట్టింగ్‌లు మరియు ఎంచుకున్న backend; resolvconf ఇంటిగ్రేషన్ ఉపయోగించే పంపిణీకి ఆ సహాయకుడి ద్వారా రాయడం.

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

రెండు భాగాలు నిజంగా కలిసి ఉండాల్సిన చోట, వాటికి వేర్వేరు పనులు ఇవ్వండి. నెట్‌వర్క్ మేనేజర్ ఇంటర్‌ఫేస్ స్థాయి కాన్ఫిగరేషన్ కలిగి ఉండనివ్వండి, VPN క్లయింట్ అదే ఇంటిగ్రేషన్ ద్వారా ప్రతి లింక్ DNS మరియు డొమైన్‌లను అందించనివ్వండి, ఫైల్‌ను నేరుగా రాసే మూడవ స్క్రిప్ట్‌ను తీసివేయండి. systemd-resolved డాక్యుమెంటేషన్ అది మద్దతు ఇచ్చే మోడ్‌లను మరియు ప్రతి ఒక్కటి /etc/resolv.conf లో ఏమి చూపుతుందో వివరిస్తుంది. మీరు ఉంచుకోవాల్సిన విధాన పరిమాణానికి సరిపోయే మోడ్‌ను ఎంచుకోండి. split DNS ముఖ్యమైతే, ప్రతి లింక్ డొమైన్‌లతో కూడిన stub ఏర్పాటు దాన్ని కాపాడుతుంది, upstream సర్వర్‌లను ఫైల్‌లోకి కాపీ చేసే మోడ్ దాన్ని నిశ్శబ్దంగా చదును చేస్తుంది.

తిరిగి కనెక్ట్ అయిన తర్వాత ధృవీకరించండి, సవరణ తర్వాత కాదు

మీ మార్పు తర్వాత వెంటనే సరిగ్గా కనిపించే ఫైల్ ఏమీ నిరూపించదు, ఎందుకంటే తదుపరి సంఘటన ఇంకా జరగలేదు. మునుపు దాన్ని పాడు చేసిన క్రమాన్ని ప్రేరేపించండి: టన్నెల్ దించి మళ్లీ ఎత్తండి, DHCP లీజ్ పునరుద్ధరించండి లేదా ఇంటర్‌ఫేస్ మార్చండి, ఆపై అదే విలువలను మళ్లీ చదవండి.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

తర్వాత ముఖ్యమైన భేదాన్ని నిర్ధారించండి: అంతర్గత పేరు అంతర్గత సర్వర్ ద్వారా పరిష్కరించబడుతుంది, పబ్లిక్ పేరు ఇంకా పని చేస్తుంది. అన్నింటినీ అంతర్గత సర్వర్‌కు పంపే కాన్ఫిగరేషన్, ఎవరైనా టన్నెల్ ద్వారా ఇంటర్నెట్‌ను చేరుకోవడానికి ప్రయత్నించే వరకు బాగానే కనిపిస్తుంది, అన్నింటినీ పబ్లిక్‌కు పంపే కాన్ఫిగరేషన్ అంతర్గత పేర్లను లీక్ చేస్తుంది.

డిప్లాయ్‌మెంట్ నోట్స్‌లో యజమాని, backend మరియు సింబాలిక్ లింక్ మోడ్‌ను నమోదు చేయండి. ఆ ఒకే పేరా భవిష్యత్ ప్యాకేజీ అప్‌గ్రేడ్‌ను సంఘటన నుండి సమీక్ష అంశంగా మారుస్తుంది, తదుపరి వ్యక్తి chattr ఆదేశంతో అదే ఘర్షణను మళ్లీ కనుగొనకుండా నిరోధిస్తుంది.