VPN DNS ప్రతి లుకప్‌ను తీసుకుంటుంది: NetworkManager లో dns-priority సరిచేయండి

ఆఫీసు VPN కు కనెక్ట్ అవ్వండి, అకస్మాత్తుగా ప్రతి పేరు లుకప్ కార్పొరేట్ రిజాల్వర్‌కు వెళ్తుంది. పబ్లిక్ పేర్లు ఇప్పటికీ పరిష్కరించబడతాయి, కాబట్టి స్థానిక ప్రింటర్ పేరు విఫలమయ్యే వరకు లేదా split-horizon రికార్డ్ ఆఫీసు చిరునామాను తిరిగి ఇచ్చే వరకు ఏదీ పాడైనట్లు కనిపించదు. కొన్ని Fedora సెటప్‌లలో విరుద్ధంగా జరుగుతుంది: టన్నెల్ పైకి వచ్చిన తర్వాత కూడా ISP రిజాల్వర్ సమాధానం ఇస్తూనే ఉంటుంది. రెండూ ఒకే ప్రశ్న — ఈ క్వెరీ యజమాని ఏ రిజాల్వర్ — మరియు NetworkManager సిస్టమ్‌లలో సమాధానం ప్రతి కనెక్షన్ DNS లక్షణాలలో నివసిస్తుంది.

రెండు కనెక్షన్‌లు, ఒక గెలిచే రిజాల్వర్

ప్రతి కనెక్షన్ ఒక DNS ప్రాధాన్యతను ప్రకటిస్తుంది. సాధారణ కనెక్షన్‌లు డిఫాల్ట్‌గా 50, VPN కనెక్షన్‌లు 0, మరియు తక్కువ విలువ గెలుస్తుంది. ఈ డిఫాల్ట్ కారణంగానే VPN కనెక్షన్ తాను క్లెయిమ్ చేసే ప్రతి డొమైన్‌కు వైర్డ్ లింక్‌ను నిశ్శబ్దంగా మించిపోతుంది: ఎవరూ ఎంచుకోకుండానే సున్నా యాభైని ఓడిస్తుంది.

ప్రాధాన్యత అభ్యర్థులను క్రమబద్ధీకరిస్తుంది. విజేతను ఏమి అడగాలో ఇది పరిమితం చేయదు. సెర్చ్ డొమైన్ లేని VPN కనెక్షన్ అన్నింటినీ క్లెయిమ్ చేస్తుంది, కాబట్టి దానికి ప్రాధాన్యత ఇవ్వడం పబ్లిక్ క్వెరీలను కూడా టన్నెల్‌లోకి, స్ప్లిట్-టన్నెల్ డిజైన్‌లో కార్పొరేట్ రిజాల్వర్ ఫార్వర్డ్ చేసే చోటికీ పంపుతుంది.

ప్రాధాన్యత క్రమాన్ని నిర్ణయిస్తుంది, సెర్చ్ జాబితా యాజమాన్యాన్ని నిర్ణయిస్తుంది

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

సెర్చ్ జాబితా యాజమాన్య ప్రకటన. corp.example వంటి నగ్న డొమైన్ సెర్చ్ సఫిక్స్ మరియు రూటింగ్ డొమైన్ అవుతుంది. రూటింగ్‌కు మాత్రమే ఉన్న రూపం ~corp.example ఆ సఫిక్స్ కింద ఉన్న లుకప్‌లను డొమైన్‌ను చిన్న పేర్లకు జోడించకుండా ఈ కనెక్షన్‌కు పంపుతుంది. ఆ టిల్డానే «ఈ సర్వర్‌ను అడగండి» మరియు «ఈ సర్వర్‌ను అడిగి నా టైపింగ్ పూర్తి చేయండి» మధ్య తేడా.

వినియోగదారులు చిన్న హోస్ట్ పేర్లను టైప్ చేసినప్పుడు మరియు రికార్డులు పూర్తిగా అర్హత కలిగిన పేర్లతో కూడా చిరునామా చేయబడినప్పుడు రెండు రూపాలను ఉపయోగించండి. రిజాల్వర్ నగ్న పేరును ఎలా పూర్తి చేస్తుందో మార్చకుండా విభజన కావాలనుకున్నప్పుడు మాత్రమే రూటింగ్ రూపాన్ని ఉపయోగించండి.

తర్వాత ప్రాధాన్యతను స్పష్టం చేసి మళ్లీ సక్రియం చేయండి:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

రుణాత్మక ప్రాధాన్యత «ఈ కనెక్షన్‌కు ప్రాధాన్యత ఇవ్వు» అని చెప్పడానికి డాక్యుమెంట్ చేయబడిన మార్గం, మరియు రెండు చిరునామా కుటుంబాలను సెట్ చేయడం IPv6 కనెక్టివిటీ ఉన్న హోస్ట్‌లో ప్రవర్తనను స్థిరంగా ఉంచుతుంది. కనెక్షన్‌ను మళ్లీ సక్రియం చేయకుండా లక్షణాన్ని మార్చడం ఇప్పుడు నడుస్తున్న ఏదీ మార్చదు, అందుకే క్రమం స్పష్టమైన up తో ముగుస్తుంది.

విభజనను systemd-resolved ఉంచనివ్వండి

డిఫాల్ట్ dnsmasq ప్లగిన్ క్వెరీలను ఒక స్థానిక రిజాల్వర్‌లోకి కుమ్మరిస్తుంది, కాబట్టి లింక్ వారీగా వేర్పాటు ముతకగానే ఉంటుంది. systemd-resolved ప్రతి లింక్‌కు విభజనను చూపుతుంది, resolvectl query సమాధానం ఇచ్చిన లింక్‌ను పేర్కొంటుంది.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

ఆ తర్వాత కార్పొరేట్ లింక్ corp.example ను మోస్తుంది, పబ్లిక్ రిజాల్వర్ మిగిలినదానిని సేవిస్తుంది. క్వెరీ తప్పు లింక్‌ను చేరుకున్నప్పుడు, ఆదేశం దానికి సమాధానం ఇచ్చిన లింక్‌ను పేర్కొంటుంది, మరియు అది తెలుసుకోవడం చిరునామా మాత్రమే తెలుసుకోవడం కంటే మంచిది.

DNS డిజైన్‌ను టన్నెల్ రకానికి సరిపోల్చండి

అన్నింటినీ టన్నెల్ ద్వారా పంపే గోప్యతా డిజైన్‌లు విభజన జాబితాను కలిగి ఉండకూడదు, ఎందుకంటే అది పబ్లిక్ పేర్లను స్థానిక రిజాల్వర్‌కు తిరిగి ఇచ్చి ఉద్దేశాన్ని రద్దు చేస్తుంది. స్ప్లిట్-టన్నెల్ డిజైన్‌లకు ఒకటి అవసరం: అది లేకుండా కార్పొరేట్ రిజాల్వర్ ప్రతి పబ్లిక్ క్వెరీని చూస్తుంది, టన్నెల్ పడిన క్షణంలోనే సెటప్ విరిగిపోతుంది.

తర్వాత టన్నెల్ వెలుపల DNS ను నిరోధించే kill switch ఉంది. టన్నెల్ జోన్‌లకు పేర్లు పరిష్కరించబడతాయి, మిగిలిన ప్రతిచోటా విఫలమవుతాయి, కనెక్షన్ పూర్తిగా ఆరోగ్యంగా ఉన్నప్పుడే. పని చేసే సమాధానాలు LAN రిజాల్వర్‌కు స్పష్టమైన అనుమతి లేదా కార్పొరేట్ జోన్‌ను మాత్రమే ఫార్వర్డ్ చేసే స్థానిక కాష్, రెండూ టన్నెల్‌లో లోపం కాదు, యజమాని కలిగిన మినహాయింపు.

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

ప్రతి లింక్‌లో ధృవీకరించండి, ఆపై మళ్లీ కనెక్ట్ అయిన తర్వాత మళ్లీ

ఒక అంతర్గత మరియు ఒక పబ్లిక్ పేరును అడగండి, క్వెరీ నిజంగా ఎక్కడికి వెళ్తుందో చూడండి. లీక్ తనిఖీ పేజీ ఏ రిజాల్వర్ సమాధానం ఇచ్చిందో చెబుతుంది, సిస్టమ్ ఏ లింక్‌ను ఎంచుకుందో కాదు, కాబట్టి మీరు ఇప్పుడే కాన్ఫిగర్ చేసిన క్రమం గురించి అది ఏమీ చెప్పదు.

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