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 tun0તમે tun ઇન્ટરફેસને 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 ક્લાયન્ટ DNS સેટિંગ્સમાં મળતા ડોમેન દ્વારા split 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 નું ઓવરરાઇડ રાખવું ન જોઈએ.
ફક્ત પહેલું નિષ્ફળ સ્તર સુધારો, પછી તે જ કમાન્ડ ફરી ચલાવો. એકસાથે બે બદલાવ તમને કહેવાથી રોકે છે કે કયો મહત્ત્વનો હતો, અને આગલી ખામી તપાસ શૂન્યથી શરૂ કરે છે.