පුද්ගලික DNS නාම VPN ක්ලායන්ට්‌වල අසාර්ථක වන්නේ ඇයි සහ කොහේද පරීක්ෂා කළ යුත්තේ

ඔබ හෝටල් කාමරයක ලැප්ටොප් විවෘත කර, ක්ලායන්ටය ආරම්භ කර, අභ්‍යන්තර ගොනු සේවාදායකයේ නාමය ටයිප් කරයි, කිසිවක් ආපසු නොඑයි. උමඟ සම්බන්ධ බව පවසයි, එම උපජාලයේ ලිපිනයකට ping තවමත් පිළිතුරු දෙයි, එබැවින් ප්‍රවාහනයම හොඳය. නාමය පමණක් අසාර්ථක වේ, එම පරතරය ගැටලුව ස්ථාන දෙකකට සීමා කරයි: ක්ලායන්ටය කුමන විසඳන්නාගෙන් ඇසුවාද සහ ලැබුණු පිළිතුර උමඟ හරහා ආපසු යා හැකිද. එකක් හරි කර අනෙක හැර දැමුවොත්, දෝෂය නිකම්ම ස්ථානය මාරු කරයි.

කිසියම් පැතිකඩක් සංස්කරණය කිරීමට පෙර ක්ලායන්ටය නාමය සමඟ කරන දේ තහවුරු කරන්න. Linux තුළ resolvectl query files.corp.example කුමන සබැඳිය සහ කුමන විසඳන්නා පිළිතුර සෑදුවාද යන්න පෙන්වයි. Windows තුළ Resolve-DnsName files.corp.example පිළිතුරු දුන් සේවාදායකය සහ එය ආපසු දුන් ලිපිනය පෙන්වයි.

කිසිවක් වෙනස් කිරීමට පෙර පිළිතුර කියවන්න

නාමය මිලිතත්පර කිහිපයකින් NXDOMAIN ලෙස ආපසු එන්නේ නම්, විමසුම ඔබේ කලාපයට කිසිදා නොපැමිණියේය, යම් පොදු හෝ හෝටල් විසඳන්නෙක් පිළිතුරු දුන්නේය. දිගු විරාමයකින් පසු ආපසු එන්නේ නම්, මාර්ගයේ යමක් UDP වරාය 53 හෙළනවා, ක්ලායන්ටය අවසානයේ විකල්පයට බැස්සා. නිවැරදි ලිපිනය සමඟ පිළිතුරු දෙන නමුත් සම්බන්ධතාවය තවමත් සිරවේ නම්, සෙවීම හොඳය, ඔබේ ගැටලුව මාර්ගකරණයේ හෝ සේවාවේම ය.

මෙම ත්‍රිවිධ බෙදීම පැයක අනුමානයක් ඉතිරි කරයි. VPN ස්පර්ශ කළ යුතුද නැද්ද යන්නද පවසයි: නිවැරදි පුද්ගලික ලිපිනයට විසඳෙන නාමයක් විසඳන්නාගේ මාර්ගය දැනටමත් ඔප්පු කර ඇත, එබැවින් ඉතිරි වැඩ දත්ත මාර්ගයේ ය.

විසඳන්නා උමඟ තුළින් බෙදාහරින්න

ක්ලායන්ට් දෙකක කණ්ඩායමකට කැඩේ. එකකට සේවාදායකය සම්බන්ධතාවය ගොඩනඟන විට විසඳන්නෙක් ලබා දිය හැක; අනෙක එම සැකසුම කිසිම ද්වාරයකට දුරස්ථව වෙනස් කළ නොහැකි දේශීය ගොනුවක තබා ගනී.

OpenVPN පළමු කණ්ඩායමේ ය. සේවාදායකයේ push "dhcp-option DNS 10.8.0.53" සහ push "dhcp-option DOMAIN corp.example" පාලන නාලිකාව හරහා පහළට යයි, නමුත් ක්ලායන්ට් වින්‍යාසයේ pull තවමත් සක්‍රීය නම් පමණි. අතින් සංස්කරණය කර pull-filter ignore "dhcp-option" දරන ක්ලායන්ට් ඒවා කිසිදා නොදකිනු ඇත, එම එකම පේළිය «සේවාදායකය එය තල්ලු කරයි නමුත් මගේ ලැප්ටොප් එකඟ නොවේ» වැනි පුදුම සහගත බොහෝ අවස්ථා පැහැදිලි කරයි.

WireGuard දෙවන කණ්ඩායමේ ය, මන්ද ප්‍රොටෝකෝලයේ විකල්ප සාකච්ඡාවක් නැත. විසඳන්නා සහ සෙවුම් වසම ක්ලායන්ට්ගේම [Interface] කොටසට DNS = 10.8.0.53, corp.example ලෙස යයි. wg-quick එය resolvconf හෝ systemd-resolved හරහා යොදයි, Windows තුළ නිල ක්ලායන්ට් උමඟ සිටින තාක් පමණක් පවතින NRPT නීති ස්ථාපනය කරයි: Get-DnsClientNrptPolicy ඒවා ලැයිස්තුගත කරයි, එය ක්ලායන්ට් ඔබේ ගොනුව කවදා හෝ යොදා ගත්තාද යන්න බැලීමට වේගවත් මාර්ගයක් කරයි.

IPsec/IKEv2 මැද ය. strongSwan හි attr ප්ලගිනය තටාකයෙන් ගත් DNS සේවාදායකයක් ආපසු දිය හැක, Windows ක්ලායන්ට් සාමාන්‍යයෙන් එය පිළිගනී, නමුත් තමන්ගේම නාම සේවාදායකය තද කරන පැතිකඩක් ද්වාරය දෙන සියල්ල ඉක්මවා යයි. Linux ක්ලායන්ට් තුළ සමාන අත් පියවර resolvectl dns wg0 10.8.0.53 සහ පසුව resolvectl domain wg0 '~corp.example'; දෙකම අතුරුමුහුණත සමඟම අතුරුදහන් වේ, එය උමඟට සීමිත සැකසුමකට ඔබට අවශ්‍ය දේ හරියටම එයයි.

සෑම විමසුමක්ම ගිල දැමීම වෙනුවට උපසර්ගය සීමා කරන්න

ක්ලායන්ට්ගේ මුළු විසඳන්නන් ලැයිස්තුවම ඔබේ අභ්‍යන්තර සේවාදායකයට හැරවීම පහසු ය, සාමාන්‍යයෙන් වැරදි ය. එවිට සෑම පොදු නාමයක්ම ඔබේ දත්ත මධ්‍යස්ථානයේ පිටවීම හරහා විසඳේ, CDN දුර ලිපින ආපසු දෙයි, විසඳන්නාගේ එක් බිඳවැටීමක් පරිශීලකයාගේ බ්‍රවුස් කිරීමද රැගෙන යයි.

ඇතුළට පුද්ගලික උපසර්ගය පමණක් යවන්න. systemd-resolved තුළ ~ සමඟ ආරම්භ වන වසම මාර්ගකරණයට පමණි, එබැවින් ~corp.example යනු එම උපසර්ගය යටතේ විමසුම් එම සබැඳියේ සේවාදායකවලට යන අතර අනෙක් සියල්ල භෞතික ජාලය භාවිත කරයි. Windows එම කාර්යයම නාම අවකාශයට සීමිත NRPT නීතිවලින් කරයි, macOS /etc/resolver/ යටතේ අමතර විසඳන්නා ගොනුවකින් කරයි.

මල්ටිකාස්ට් නාම තමන්ගේම පිළිතුරකට සුදුසු ය. .local නාම නිර්මාණයෙන් link-local (RFC 6762) වන අතර ලක්ෂ්‍යයෙන් ලක්ෂ්‍යයට tun අතුරුමුහුණත එම මල්ටිකාස්ට් සමූහය ගෙන යන්නේ නැත, එබැවින් පොදු විසඳන්නෙක් එකතු කිරීමෙන් ඒවා ප්‍රකාශයට පත් නොවේ, අභ්‍යන්තර unicast විසඳන්නාගෙන් ඒවා ගැන ඇසුවොත් NXDOMAIN ආපසු එයි. avahi වැනි පරාවර්තකයක් පරාවර්තන ආකාරයේදී කොටස් දෙකක් සම්බන්ධ කළ හැක, නමුත් එය සේවාදායක පැත්තේ තීරණයක්, කිසිම ක්ලායන්ට් කෙනෙකුට ඉල්ලිය නොහැක. මුද්‍රණ යන්ත්‍රයක් හෝ NAS එකක් නාමයෙන් ළඟා විය යුතු නම්, ඒ වෙනුවට ඔබේ කලාපයේ එයට A වාර්තාවක් දෙන්න.

පිළිතුර ආපසු යා හැකි බව ඔප්පු කරන්න

ළඟා විය නොහැකි ලිපිනයකට යොමු වන නිවැරදි පිළිතුරක් ඔබ මාර්ගය පරීක්ෂා කරන තාක් හරියටම විසඳන්නාගේ ගැටලුවක් මෙන් පෙනේ. පිළිතුර කොහේ යයිද කර්නලයෙන් අසන්න: ip route get 10.20.5.20 අතුරුමුහුණත සහ වඩාත් ප්‍රයෝජනවත් ලෙස එය භාවිත කරන මූලාශ්‍ර ලිපිනය නම් කරයි.

විසඳන්නාගේ ලිපිනයම නිරීක්ෂණය කරන්න. DNS = 10.8.0.53 සමඟ AllowedIPs = 10.20.0.0/16 ඇති ක්ලායන්ට් තම විමසුම් භෞතික NIC හරහා පිටතට යවයි, එහිදී ඒවා නිහඬව මිය යයි, මන්ද විසඳන්නා උමඟ ඉල්ලා සිටින කිසිම උපසර්ගයක් තුළ නැත. මෙම නොගැලපීම මෙම මුළු ක්ෂේත්‍රයේම වඩාත් පොදු තනි හේතු අසාර්ථකත්වයයි, DNS සැකසුම අනුමත උපසර්ග සමඟ පේළියෙන් පේළිය සසඳන තාක් එය නොපෙනේ.

අතිච්ඡාදනය වන පරාස ප්‍රතිවිරුද්ධ අසාර්ථකත්වය ඇති කරයි. පිළිතුර නිවැරදි ය, මාර්ගය පවතී, එය වැරදි සත්කාරකයට යොමු වේ, මන්ද නිවසේ 192.168.0.0/24 එම පරාසයට උමඟේ මාර්ගයට වඩා නිශ්චිත ය. එක් පැත්තක් නැවත අංකනය කරන්න හෝ පටු මාර්ගයක් තල්ලු කරන්න, පසුව සේවා සත්කාරකයේ ගිනිපවුර සහ ආපසු මාර්ගය තහවුරු කරන්න; strongSwan හි ඉදිරියට යැවීම පිළිබඳ සටහන් එම මාර්ගයේ sysctl පැත්ත ආවරණය කරයි.

සහතික යනු මිනිසුන් DNS මත පටවන වෙනම අනන්‍යතා පරීක්ෂාවකි. බ්‍රවුසරය විසඳුම් දෝෂයක් වෙනුවට නාම නොගැලපීමක් වාර්තා කරන්නේ නම්, සෙවීම දැනටමත් ක්‍රියා කර ඇත, සහතිකයේ SAN යනු නිවැරදි කළ යුතු දේ ය. HTTPS නාමයට එරෙහිව පරීක්ෂා කරන්න, කිසිදා නග්න IP එකට එරෙහිව නොවේ.

ද්වාරයෙන් නොව, ක්ලායන්ට්ගෙන් නැවත පරීක්ෂා කරන්න

පරිශීලකයා පැමිණිලි කරන යෙදුම තුළම පරීක්ෂා කරන්න, මන්ද විධාන රේඛා සෙවීම බ්‍රවුසරයද එම මාර්ගයම ගනී යැයි ඔප්පු නොකරයි. Chrome හි ආරක්ෂිත DNS සහ Firefox හි network.trr.mode පද්ධති විසඳන්නා සම්පූර්ණයෙන්ම මඟ හැරිය හැක, එසේ කරන විට පුද්ගලික නාමය එක්කෝ අසාර්ථක වේ නැතහොත් පොදු විසඳන්නෙකුට කාන්දු වේ. resolvectl query අතින් ධාවනය කළ dig @10.8.0.53 files.corp.example සමඟ සසඳීම දෙකෙන් කුමක් සිදු වුණාද පවසයි.

පසුව එය නිවැරදි කළ බව ප්‍රකාශ කිරීමට පෙර සම්බන්ධතාවය විසන්ධි කර නැවත සම්බන්ධ කරන්න. අතුරුමුහුණතට අතින් දැමූ සැකසුම් අතුරුමුහුණත සමඟම අතුරුදහන් වේ, අමතක වූ දේශීය වෙනසක් නිසා පමණක් නිවැරදි ලෙස පෙනුණු පැතිකඩ ඊළඟ වරට ධාවනයේදී අසාර්ථක වනු ඇත.

ඊළඟ යන්ත්‍රය සඳහා කෙටි ලැයිස්තුව: නාමය උමඟේ විසඳන්නා හරහා විසඳේ, උපසර්ගය සීමිත ය ගෝලීය නොවේ, විසඳන්නාගේ ලිපිනය අනුමත උපසර්ග තුළ ය, පිළිතුරේ සත්කාරකය සේවා වරායේ පිළිතුරු දෙයි, සහතිකය පරිශීලකයා ටයිප් කළ නාමය ආවරණය කරයි.