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 වෙත යයි, tun අතුරුමුහුණතට සම්බන්ධ මාර්ගගත කලාපය අනුව systemd-resolved සෑම සබැඳියකටම ඉහළ සේවාදායකයක් තෝරයි.
විධාන දෙකක් මෙම ස්තර අනුමාන නොකර වෙන් කරයි:
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 අභිබවා යාමක් තබා නොගත යුතුය.
අසාර්ථක වන පළමු ස්තරය පමණක් නිවැරදි කර, පසුව එම විධාන නැවත ධාවනය කරන්න. එකවර වෙනස්කම් දෙකක් කිරීමෙන් කුමක් වැදගත් වූයේදැයි පැවසීමට නොහැකි වේ, ඊළඟ බිඳවැටීම විමර්ශනය බිංදුවේ සිට ආරම්භ කරයි.