VPN లో అంతర్గత హోస్ట్‌నేమ్‌లు dig లో ఎందుకు పరిష్కరించబడతాయి కానీ curl లో విఫలమవుతాయి
dig సమాధానమిస్తుంది, కానీ curl హోస్ట్‌ను పరిష్కరించలేకపోతున్నట్లు నివేదిస్తుంది. రెండు శోధన గొలుసులను పోల్చి, తర్వాత nsswitch, లింక్ వారీగా DNS లేదా తప్పు శోధన సఫిక్స్‌ను సరిచేయండి.
మీ ల్యాప్‌టాప్ VPN లో ఉంది, dig service.internal.example 10.x చిరునామాతో సమాధానమిస్తుంది, curl ఇంకా Could not resolve host తో బయటకు వస్తుంది. టన్నెల్ సమస్య కాదు: అది dig ప్రశ్నను ఫిర్యాదు లేకుండా తీసుకువెళ్ళింది. భేదం ప్రశ్న ఎవరు అడుగుతున్నారన్నది. dig మీరు పేరు పెట్టిన ఒక సర్వర్‌కు ఒక ప్రశ్న పంపుతుంది, అయితే curl ఆపరేటింగ్ సిస్టమ్ శోధన గొలుసు గుండా వెళుతుంది, ఆ గొలుసుకు ఏ సర్వర్‌ను అడగాలనే దానిపై దాని సొంత నియమాలు ఉన్నాయి.
ఒకే పేరుకు రెండు శోధనలు
dig దాని సొంత stub resolver. అది /etc/resolv.conf చదువుతుంది, నేమ్ సర్వర్‌ను ఎంచుకుంటుంది, ఒకే A లేదా AAAA ప్రశ్న పంపి సమాధానాన్ని ముద్రిస్తుంది. అది nsswitch ను పూర్తిగా దాటవేస్తుంది, systemd-resolved లేదా NetworkManager ఆ ఫైల్ వెలుపల ఉంచే లింక్ వారీగా స్థితి గురించి ఏమీ తెలియదు, అందుకే dig సమాధానం సరైనది కావచ్చు, అయినా మీ అప్లికేషన్ ఏమి చూస్తుందనే దానిపై ఏమీ చెప్పలేదు.
అప్లికేషన్లు getaddrinfo ను పిలుస్తాయి, getaddrinfo పొడవైన గొలుసు గుండా వెళుతుంది: nsswitch మాడ్యూళ్ల క్రమం, తర్వాత పేరును నిర్వహించే మాడ్యూల్, చివరగా ప్రస్తుత లింక్ కాన్ఫిగరేషన్ నుండి నిర్మించిన resolver. systemd మెషీన్‌లో ప్రశ్న 127.0.0.53 కు వెళుతుంది, systemd-resolved tun ఇంటర్‌ఫేస్‌కు జోడించిన రూటింగ్ డొమైన్ ఆధారంగా ప్రతి లింక్‌కు ఎగువ సర్వర్‌ను ఎంచుకుంటుంది.
రెండు ఆదేశాలు ఈ పొరలను ఊహించకుండా వేరు చేస్తాయి:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent curl తీసుకునే అదే మార్గాన్ని తీసుకుంటుంది, కాబట్టి పనిచేస్తున్న dig పక్కన getent వైఫల్యం లోపాన్ని ప్యాకెట్ రూటింగ్‌లో కాకుండా శోధన విధానంలో గుర్తిస్తుంది. resolvectl query సమాధానమిచ్చిన ఇంటర్‌ఫేస్ మరియు ఎగువ సర్వర్‌ను కూడా ముద్రిస్తుంది, ఇది టన్నెల్ లింక్ గెలిచిందా లేదా భౌతిక లింక్ గెలిచిందా చూపుతుంది.
అప్లికేషన్ నిజంగా ఉపయోగించే resolver ను చదవండి
/etc/resolv.conf చాలా డెస్క్‌టాప్‌లలో ఉత్పత్తి అవుతుంది, VPN క్లయింట్‌కు దాన్ని నిర్వహించడానికి మూడు మార్గాలున్నాయి: నేమ్ సర్వర్‌ను ముందు చేర్చడం, ఫైల్‌ను పైన రాయడం, లేదా తన సర్వర్లను NetworkManager కు అప్పగించి డీమన్ దాన్ని తిరిగి రాయనివ్వడం. మూడవ నమూనా మాత్రమే లింక్ వారీగా DNS ను కాపాడుతుంది, ఎందుకంటే సర్వర్లు ఒక ప్రపంచ జాబితాలో చదును కాకుండా ఇంటర్‌ఫేస్‌కు జోడించబడి ఉంటాయి.
NetworkManager సిస్టమ్‌లలో ఫలితం /etc/NetworkManager/NetworkManager.conf లోని backend పై ఆధారపడుతుంది:
[main]
dns=systemd-resolveddns=default తో క్లయింట్ సర్వర్లు గెలిచే క్రమంలో resolv.conf లో విలీనమవుతాయి, ప్రైవేట్ ప్రశ్న ఇంకా పబ్లిక్ resolver కు వెళ్ళవచ్చు. లింకులను అర్థం చేసుకునే backend తో, systemd-resolved లేదా dnsmasq, టన్నెల్ సర్వర్లు టన్నెల్‌కే పరిమితమవుతాయి, దాని రూటింగ్ డొమైన్‌కు సరిపోయే పేర్లు మాత్రమే అక్కడికి వెళ్తాయి. ఈ పరిమితే ఆచరణలో split DNS అర్థం, క్లయింట్ దాన్ని మద్దతిస్తున్నట్లు చెప్పుకున్నప్పుడు ఎక్కువగా మిస్ అయ్యే భాగం ఇదే.
ఏదైనా మార్చే ముందు స్థితిని చదవండి:
resolvectl status
resolvectl dns tun0tun ఇంటర్‌ఫేస్ DNS సర్వర్ మరియు ప్రైవేట్ సఫిక్స్ కోసం రూటింగ్ డొమైన్‌తో జాబితా చేయబడి, ~internal.example గా చూపబడాలని మీరు కోరుకుంటారు. లింక్‌పై సర్వర్ లేకపోవడం క్లయింట్ ఏమీ పంపలేదని అర్థం. డొమైన్ లేని సర్వర్ అంటే ప్రశ్నలు అన్నీ అక్కడికి వెళ్తాయి లేదా ఏవీ వెళ్ళవు, క్లయింట్‌ను బట్టి, రెండూ split DNS కావు.
nsswitch శోధనను ముందుగానే ముగించే చోటు
డెస్క్‌టాప్ సాధారణ లైన్ ఇలా కనిపిస్తుంది:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal మల్టీకాస్ట్ DNS ను నిర్వహిస్తుంది, .local తో ముగిసే ప్రతి పేరుపై హక్కు చెప్పుకుంటుంది. api.infra.svc.cluster.local వంటి Kubernetes సేవ కూడా .local తో ముగుస్తుంది. mDNS మాడ్యూల్ NOTFOUND నివేదించినప్పుడు, [NOTFOUND=return] చర్య dns మాడ్యూల్ వైపు కొనసాగడానికి బదులు మొత్తం శోధనను ముగిస్తుంది, కాబట్టి పేరు ఎప్పుడూ VPN resolver కు పంపబడదు. dig ఫైల్‌ను పూర్తిగా దాటవేస్తుంది, అందుకే రెండు సాధనాలు ఏకీభవించవు.
ఇది ఈ సమస్యలో అత్యంత తీవ్రమైన విరుద్ధత, అది మీ VPN కంటే పాత కాన్ఫిగరేషన్ ఫైల్‌లోని ఒక పదంపై నిలిచి ఉంది. చర్యను [NOTFOUND=continue] కు మార్చితే ప్రింటర్లు మరియు స్థానిక పరికరాలకు mDNS ఉంటుంది, DNS పేరును చూడగలదు. లైన్‌ను hosts: files dns తో భర్తీ చేయడం కూడా పనిచేస్తుంది, మరింత మొరటుగా ఉంటుంది: మీరు నిజంగా ఉపయోగించే ప్రింటర్ కోసం .local పరిష్కారాన్ని వదిలేస్తుంది.
సరిగ్గా ఒకే నెట్‌వర్క్‌లో జీవించే పేర్లు
ప్రైవేట్ జోన్లు సరిగ్గా ఒకే చోట అధికారం కలిగి ఉంటాయి. ip-10-0-4-31.eu-west-1.compute.internal వంటి AWS పేరు ఆ ప్రాంతపు VPC resolver ద్వారా సమాధానమిస్తుంది, మీ VPN ఎండ్‌పాయింట్ వనరు ఉన్న ప్రాంతంలో ఉన్నంత వరకే. ఫ్రాంక్‌ఫర్ట్ ఎండ్‌పాయింట్‌కు కనెక్ట్ అయి, ఐర్లాండ్ compute.internal పేరును అడిగితే, ఏ స్థానిక సెట్టింగ్ సహాయం చేయదు: రికార్డును ఉంచే జోన్ అక్కడి నుండి చేరుకోలేనిది.
శోధన డొమైన్లు వ్యతిరేక చిత్రాన్ని ఉత్పత్తి చేస్తాయి. బేర్ service resolver వర్తించదగినదిగా భావించే సఫిక్స్‌తో పూర్తవుతుంది, VPN లింక్‌తో స్థానిక డొమైన్ కార్పొరేట్ డొమైన్‌ను ఓడించవచ్చు. ఊహను తొలగించడానికి చివరలో బిందువుతో అడగండి, getent ahosts service.internal.example., అది పనిచేసి చిన్న పేరు విఫలమైతే, సరిచేయడం టన్నెల్‌పై శోధన డొమైన్, సర్వర్ చిరునామా కాదు.
నిర్వహిత క్లయింట్లు సిస్టమ్ resolver పై మూడవ పొరను జోడిస్తాయి. Windows VPN ప్రొఫైల్ తన సొంత పేరు పరిష్కార విధానాన్ని, ప్రతి యాప్ నియమాలను మరియు టన్నెల్ ఆఫ్‌లో ఉన్నప్పటికీ వర్తించే NRPT పట్టికను తీసుకురాగలదు. సొంత DNS కాష్ ఉన్న అప్లికేషన్లు, .NET మరియు Java రన్‌టైమ్‌లలో సాధారణం, గొలుసు సరిచేసిన తర్వాత కూడా పాత వైఫల్యాన్ని దీర్ఘకాలం ఉంచుతాయి. Apple క్లయింట్లు split DNS ను DNS సెట్టింగ్‌లలోని సరిపోలే డొమైన్ల ద్వారా సెట్ చేస్తాయి, resolv.conf ద్వారా కాదు, Chromium లేదా Firefox సురక్షిత DNS మోడ్‌లో పబ్లిక్ పేర్ల కోసం సిస్టమ్ resolver ను దాటవేయగలవు. VPN పేరు పరిష్కారంపై Microsoft సూచన ఆ విధాన పొర యొక్క Windows వైపును వివరిస్తుంది.
ఏ పొరను సరిచేయాలో నిర్ణయించండి
సరిచేయడాలను వరుసగా ప్రయత్నించడానికి బదులు లక్షణం నుండి పొర వైపు వెళ్ళండి:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
రెండు వరుసలు ఎక్కువ బరువు మోస్తాయి. టైమ్‌అవుట్ చేరుకోగల సమస్య: ప్రైవేట్ resolver టన్నెల్ ద్వారా సమాధానం ఇవ్వడం లేదు, కాబట్టి దాని చిరునామాకు మార్గాన్ని, లింక్‌పై DNS సర్వర్ మీరు అనుకున్నదేనా అని తనిఖీ చేయండి. NXDOMAIN అధికార సమస్య: ఏదో సమాధానమిచ్చింది, అది పేరును తెలియదు, ఇది జోన్, ప్రాంతం లేదా ఈ ప్రశ్నను ఎప్పుడూ పొందకూడని resolver వైపు సూచిస్తుంది.
చివరి వరుసను ప్రజలు దాటవేస్తారు, ఎందుకంటే రెండు భాగాలు విజయంలా కనిపిస్తాయి. FQDN నుండి భిన్నంగా పరిష్కరించబడే చిన్న పేరు సఫిక్స్ అసమన్వయం, టన్నెల్‌ను తిరిగి కనెక్ట్ చేయడం క్లయింట్ ఏ సఫిక్స్ పంపుతుందో మార్చదు.
కాన్ఫిగరేషన్ ఫైల్‌ను సవరించే ముందు స్థితిని రికార్డ్ చేయండి, సవరణ ఏదైనా చేసిందా చెప్పగలరు:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtతనిఖీలను ఈ క్రమంలో అమలు చేసి మొదటి వైఫల్యం వద్ద ఆగండి. getent మరియు resolvectl query సరిపోలాలి; getent విఫలమై dig సమాధానమిస్తుంటే, శోధన గొలుసులోనే ఉండండి, రూటింగ్‌ను తాకకండి. resolvectl status tun ఇంటర్‌ఫేస్‌పై DNS సర్వర్ మరియు రూటింగ్ డొమైన్ చూపాలి. nsswitch పరీక్షిస్తున్న సఫిక్స్ కోసం NOTFOUND తో ముందుగానే తిరిగి రాకూడదు. పేరు మీ ఎండ్‌పాయింట్ కనెక్ట్ అయిన నెట్‌వర్క్‌లో అధికారం కలిగి ఉండాలి, చివరలో బిందువుతో పరీక్షించబడాలి. అప్లికేషన్ తన సొంత కాష్ లేదా సురక్షిత DNS ఓవర్‌రైడ్ ఉంచకూడదు.
విఫలమయ్యే మొదటి పొరను మాత్రమే సరిచేసి, తర్వాత అదే ఆదేశాలను మళ్లీ అమలు చేయండి. ఒకేసారి రెండు మార్పులు ఏది ముఖ్యమైందో చెప్పనివ్వవు, తదుపరి పనిచెడుదల దర్యాప్తును సున్నా నుండి ప్రారంభిస్తుంది.