VPN DNS పని చేస్తుంది, కానీ .local పేర్లు ఇంకా విఫలమవుతున్నాయి: వాటిని ఎవరు పరిష్కరిస్తారు?

ఒకే VPN లో రెండు యంత్రాలు, ఒకే హోస్ట్‌నేమ్, మరియు వాటిలో ఒకటి మాత్రమే దాన్ని పరిష్కరిస్తుంది: భేదం సాధారణంగా టన్నెల్ కాదు, ఏ రిజాల్వర్ సమాధానమిచ్చింది అనేది. Linux డెస్క్‌టాప్‌లో ఆ పేరు పేరు సేవా స్విచ్ ద్వారా, systemd-resolved యొక్క స్టబ్ ద్వారా, లేదా అప్లికేషన్ తనతో తెచ్చిన రిజాల్వర్ ద్వారా వెళ్లవచ్చు, మరియు వాటిలో ప్రతి ఒక్కటి అదే సఫిక్స్‌పై తన నియమాన్ని వర్తిస్తుంది. నియమాలు విడిపోయేది సఫిక్స్ వద్దనే, ఎందుకంటే .local తటస్థ లేబుల్ కాదు. ఏదైనా ఏ క్రమంలో నడుస్తుందో మార్చే ముందు విఫలమయ్యే ప్రోగ్రామ్ నిజంగా ఏ మార్గం తీసుకుంటుందో కనుగొనండి.

రెండు రిజాల్వర్లు, రెండు వేర్వేరు సమాధానాలు

సాంప్రదాయ glibc శోధన nsswitch.conf యొక్క hosts: లైన్ గుండా వెళ్లి ఒకటి సమాధానమిచ్చే వరకు ప్రతి మాడ్యూల్‌ను వంతుగా అడుగుతుంది. స్టబ్ శ్రోత ద్వారా systemd-resolved తో మాట్లాడే క్లయింట్ బదులుగా ఒకే ప్రక్రియను అడుగుతుంది, ఆ ప్రక్రియ ప్రతి లింక్‌కు విధానాన్ని మరియు తన ప్రత్యేక సందర్భాలను వర్తిస్తుంది. తన సొంత రిజాల్వర్‌ను తెచ్చే లేదా అలా చేసే లైబ్రరీని లింక్ చేసే అప్లికేషన్ రెండింటినీ దాటవేయగలదు. కాబట్టి ఒక హోస్ట్‌నేమ్‌కు ఒక యంత్రంలో ముగ్గురు యజమానులు ఉండవచ్చు, మరియు వాటిలో ఒకరికి మాత్రమే VPN ఏమి ఉద్దేశించిందో తెలుసు.

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

ఏ ఆదేశం నిజంగా మీ రిజాల్వర్‌ను అడిగింది

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

ఎందుకు .local మీ unicast జోన్‌ను దాటవేస్తుంది

systemd-resolved సూచన ప్రకారం .local తో ముగిసే బహు-లేబుల్ పేర్లు, mDNS ప్రారంభంలో ఉన్నప్పుడు సాధారణ unicast DNS కి బదులు సాధారణంగా multicast DNS కి వెళ్తాయి. RFC 6762 ఆ పేరు స్థలాన్ని link-local multicast కోసం కేటాయిస్తుంది, కాబట్టి ఒక కార్పొరేట్ జోన్ ఆ సఫిక్స్ కోసం ఎప్పుడూ అడగని సరైన రికార్డును కలిగి ఉండవచ్చు. టన్నెల్ రిజాల్వర్‌ను పరిపూర్ణంగా రూట్ చేసి కూడా పోటీలో ఓడిపోవచ్చు. కాష్ నుండి విజయవంతమైన ping ఇప్పుడే జరిగిన శోధన గురించి ఏమీ చెప్పదు.

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

సన్నని మినహాయింపు ప్రపంచ పునఃక్రమాన్ని ఓడిస్తుంది

మీరు పేరు మార్చలేని ఉన్న జోన్ కోసం, రిజాల్వర్ మరియు VPN యజమానులు ఆ డొమైన్‌ను దాన్ని మోసుకెళ్లే కనెక్షన్‌పై ప్రకటించేలా చేయండి. ఆ ఒక సఫిక్స్ కోసం రూటింగ్-డొమైన్ ఎంట్రీ మరియు ఉద్దేశించిన సర్వర్ చిరునామా పేరు పెట్టిన యజమానితో కూడిన చిన్న మార్పు, మరియు అది చేతితో సవరించిన ఫైల్‌లో కాదు, లింక్‌తో పాటు జీవిస్తుంది.

కనెక్షన్ తెగిన తర్వాత కూడా అది నిలిచి ఉంటుంది, ఎందుకంటే లింక్ తిరిగి వచ్చినప్పుడు లింక్ విధానం మళ్లీ వర్తించబడుతుంది. పంచుకున్న nsswitch.conf ను సవరించడం ఆకర్షణీయమైన మరియు ఖరీదైన ప్రత్యామ్నాయం, ఎందుకంటే అది యంత్రంలోని ప్రతి పేరుకు శోధన ప్రవర్తనను మారుస్తుంది, స్థానిక ఆవిష్కరణతో సహా. multicast డెమన్‌ను నిలిపివేయడం కూడా సమానం కాదు: అది స్థానిక ప్రవర్తనను తొలగిస్తుంది కానీ ఏ రిజాల్వర్‌కు కార్పొరేట్ జోన్ గురించి నేర్పదు. సేవ వారసత్వం కాకుండా కొత్తదైతే, దాన్ని మీ సంస్థ నియంత్రించే ఉప డొమైన్ కింద ఉంచి పోటీని పూర్తిగా దాటవేయండి. పేరు firmware లో స్థిరంగా లేదా లేబుల్‌పై ముద్రించబడి ఉంటే సన్నని మినహాయింపును ఎంచుకోండి, క్లయింట్‌ను ఇంకా నియంత్రిస్తుంటే కొత్త ఉప డొమైన్‌ను ఎంచుకోండి.

మార్పు తర్వాత ఏమి నిరూపించాలి

పరిష్కారాన్ని అప్లికేషన్ సొంత శోధనతో నిరూపించండి, పరీక్ష కోసం ఇన్‌స్టాల్ చేసిన సాధనంతో కాదు, దాని తరఫున సమాధానమివ్వగల ఏ కాష్‌నైనా ఖాళీ చేయండి. తర్వాత రిజాల్వర్ మార్గాన్ని మరియు సమాధానం ఇచ్చిన లింక్‌ను నిర్ధారించండి. చివరగా స్థానిక ఆవిష్కరణ మార్పు ముందులా ప్రవర్తిస్తుందా పరిశీలించండి, ఎందుకంటే కనిపించడం ఆపే ప్రింటర్ మనుషులు చివరగా గమనించే భాగం. ఈ మూడు ఆదేశాలు పేరు, మార్గం మరియు TLS గుర్తింపును అదే క్రమంలో పరిశీలిస్తాయి:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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