ඔබේ ලැප්ටොප් intranet.corp ටනලය හරහා විසඳන අතර gitlab.com සේවා සපයන්නාගේ විසඳන්නා වෙතම යයි, මෙය නිර්මාණයට අනුව ක්‍රියා කරන වින්‍යාසයයි. වෙන වෙනම ගත් තීරණ දෙකක් මෙය සෑදීය: නම ගැළපීමේ නීතිය විසඳන්නා තෝරාගත් අතර මාර්ගයක් පිළිතුර ආපසු ගෙන ආවේය. ඕනෑම එකක් කැඩුවොත් බ්‍රවුසරය පිටතින් එකම ලෙස පෙනෙන අසාර්ථකත්වයක් පෙන්වයි. වෙන් කළ DNS පිළිබඳ බොහෝ වාර්තා දෙවන අසාර්ථකත්වය විස්තර කරමින් පළමු ගැන සාක්ෂි උපුටා දක්වයි.

අර්ධ දෙක ජීවත් වන්නේ විවිධ තැන්වල සහ සාමාන්‍යයෙන් සංස්කරණය කරන්නේ විවිධ පුද්ගලයන්ය. එකක් VPN පැතිකඩට සම්බන්ධ DNS ප්‍රතිපත්තියක් වන අතර අනෙක ටනලය ස්ථාපනය කරන හෝ රඳවා තබන මාර්ගයකි. කුමන අර්ධය සැබවින්ම චලනය වුණාදැයි කිසිවෙක් තීරණය නොකළ විට නිදොස් කිරීම නතර වේ.

එක් ඉල්ලීමක සැඟවුණු තීරණ දෙකක්

නමේ අර්ධය ප්‍රතිපත්ති වස්තුවක් මිස මාර්ගයක් නොවේ. Windows හි එය VPN පැතිකඩේ නම-විසඳුම් ප්‍රතිපත්තියයි; Apple වේදිකාවල DNS සැකසුම් වස්තුවක ගැළපෙන වසම් කට්ටලයයි; Linux හි එය මාර්ගකරණ වසමක්, වෙන් කළ විසඳන්නා පේළියක් හෝ නම් සේවා ස්විචයේ අනුපිළිවෙලයි. මාර්ගයේ අර්ධය සාමාන්‍ය මාර්ගකරණයක් වන අතර ටනලය හෝ අතින් ස්ථාපනය කරයි, එයට සත්කාරක නාමයක් යනු කුමක්දැයි නොදනී. උපසර්ගයක් ඉඩ දෙන පැතිකඩක් තීරණය කරන්නේ කවුරුන් පිළිතුරු දෙන්නේද යන්න පමණි; එය කිසි විටෙක පිළිතුර ළඟා විය හැකි එකක් නොකරයි.

ඉක්මන් රෝග ලක්ෂණ පරීක්ෂාවක් ඒවා වෙන් කරයි: නම වෙනුවට ලිපිනයක් දමන්න. ලිපිනය ක්‍රියා කරන්නේ නම් මාර්ගය හරි සහ නීතිය වැරදිය. ලිපිනයත් අසාර්ථක නම් නීතිය හරි විය හැකි අතර මාර්ගය නැති විය හැක.

සෑම වේදිකාවක්ම එකම නම් නීතිය ප්‍රකාශ කරන ආකාරය

අභිප්‍රාය සමාන වන අතර ක්ෂේත්‍ර නාම නොවේ. එක් සේවාදායකයකින් තවත් එකකට පිටපත් කළ උදාහරණයක් පිරිසිදුව විග්‍රහ වන අතර කිසි විටෙක නොගැළපේ. ආකෘති තුන මෙසේ පෙනේ:

PlatformWhere the rule livesWhat usually breaks
Windowsname-resolution policy on the VPN profileprecedence against the interface suffix list
Apple platformsmatch domains on the DNS settings objectdomains attached to the wrong extension
Linuxrouting domain, split resolver, nsswitch orderthe suffix written the wrong way round

ගැළපුම් හෝ මාර්ගකරණ වසමක් යනු උපසර්ග පරීක්ෂාවකි, එබැවින් intranet.corp git.intranet.corp ආවරණය කරන අතර corp.intranet ආවරණය නොකරයි, එය පෙරළීම මුළු වින්‍යාසයේම වඩාත් පොදු වැරැද්දයි. Windows සිතියම පැතිකඩට සම්බන්ධ නම-විසඳුම් ප්‍රතිපත්තියක් ලෙස රැගෙන යන අතර, අතුරුමුහුණතට දැනටමත් තිබූ ඕනෑම උපසර්ග ලැයිස්තුවකට එරෙහිව තමන්ගේම ප්‍රමුඛතා අනුපිළිවෙලක් ඇත. Apple වේදිකා ගැළපෙන වසම් ජාල දිගුවේ DNS සැකසුම් වස්තුවට සම්බන්ධ කරන අතර පද්ධතිය ඒවා සෑම සීමිත විසඳන්නෙකුටම යොදයි. මෙම ආකෘති කිසිවක් මාර්ගයක් නොවන අතර කිසිවකට ළඟා විය නොහැකි ලිපිනයක් ළඟා විය හැකි එකක් කළ නොහැක. Windows නම-විසඳුම් ප්‍රතිපත්තිය යොමුව එම වේදිකාවේ ක්ෂේත්‍ර නාම සහ ප්‍රමුඛතා නීති ලැයිස්තුගත කරන අතර ඒවා Apple හෝ systemd ලේඛන භාවිතා කරන නීති නොවේ.

නිවැරදි පිළිතුරකට තවමත් මාර්ගයක් අවශ්‍යයි

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

කිසිදු අර්ධයක් ආවරණය නොකරන තුන්වන දොරටුවක්ද ඇත. ගේට්වේව්හි ACL එකක්, ෆයර්වෝල් නීතියක් හෝ සේවාදායක පැත්තේ ප්‍රතිපත්තියක් තීරණ දෙකම නිවැරදි වූ පසු සම්බන්ධතාව ඉවත දැමිය හැක. නාමය විසඳා, මාර්ගය තිබී, සම්බන්ධතාව තවමත් කාලය ඉක්මවා ගියොත් DNS පරීක්ෂාව නවත්වන්න.

නිශ්චිත අනුපිළිවෙලකින් නාම සහ මාර්ග පරීක්ෂා කිරීම

අනුපිළිවෙලක් තෝරා එය රඳවා ගන්න, නැතිනම් අවසානයේ අසාර්ථක වූ පියවර පසුපස දුවන්නට සිදුවේ. ලේඛනගත සම්පූර්ණ අභ්‍යන්තර නාමය විසඳන්න, පිළිතුර මාර්ග වගුවට ගෙන යා හැකි ලිපිනයක් බව තහවුරු කරන්න, පසුව පොදු නාමයක් සමඟ පුනරාවර්තනය කර ටනලය සියල්ල අල්ලා නොගත් බව ඔප්පු කරන්න. systemd සත්කාරකයක විමසුම සහ විසඳන්නාගේ මාර්ගකරණ වසම එක් විධානයක දුරින්:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows සේවාදායකයා එම ප්‍රශ්න දෙකම වෙනත් cmdlet සමඟ අසයි. දෙවැන්න පද්ධතිය සැබවින්ම භාවිතා කරන අතුරුමුහුණත වාර්තා කරයි:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

සෙවීම ලිපිනයක් ලබා දෙන අතර මාර්ග පරීක්ෂාව භෞතික අතුරුමුහුණත නම් කරන්නේ නම්, නම් නීතිය ක්‍රියා කළ අතර මාර්ගය ක්‍රියා නොකළේය. කෙටි නාමය අසාර්ථක වන අතර සම්පූර්ණ නාමය විසඳෙන්නේ නම්, වැරැද්ද උපසර්ග ලැයිස්තුවේ මිස විසඳන්නාගේ නොවේ.

සංසන්දනය සාමාන්‍යයෙන් වැරදෙන තැන

පළමු වැරැද්ද නම් සම්බන්ධයක් නැති පොදු විසඳන්නෙකුගෙන් පෞද්ගලික නාමයක් ගැන ඇසීම සහ ප්‍රතික්ෂේපය VPN ගැන සාක්ෂියක් ලෙස කියවීමය. දෙවැන්න නම් ක්‍රියා කරන පොදු සෙවීමක් ටනලයේ විසඳන්නා මාර්ගය ඔප්පු කරන බව උපකල්පනය කිරීමය. තුන්වැන්න නම් වෙන් කළ ටනල්කරණය සහ වෙන් කළ DNS එකම නිර්මාණ තීරණයක් ලෙස සැලකීමය, එක් එකක යෙදවීමක් නිවැරදි විය හැකි අතර අනෙකේ කැඩී තිබිය හැක. සෑම වැරැද්දක්ම චෝදනා ලැබූ කොටස කිසි විටෙක පුහුණු නොකළ පරීක්ෂාවකින් විශ්වාසදායක නිගමන ලබා දෙයි.

තමන්ගේම ආරක්ෂිත DNS ඇති බ්‍රවුසරයකටද පද්ධති නීතිය මඟ හැරිය හැක, එබැවින් එක් බ්‍රවුසරයක් අසාර්ථක වන අතර තවත් එකක් සාර්ථක වීම පරස්පරයක් නොවේ. පිළිතුරු දුන් විසඳන්නා සංසන්දනය කරන්න, පැමිණිලි කළ බ්‍රවුසරය නොව.

අර්ධ දෙකම දෘශ්‍යමාන වූ පසු ඉතිරි ප්‍රශ්නය තාක්ෂණික නොව ප්‍රතිපත්තිමය ප්‍රශ්නයකි: කුමන නාම අවකාශ සංවිධානයට අයත්ද, සෑම පිළිතුරකම හිමිකරු කවුද, ඒවායින් කුමක් යන්ත්‍රයෙන් පිටවිය යුතුද. එය පැතිකඩ අසල ලියන්න, මන්ද නීතිය ස්පර්ශ කරන ඊළඟ පුද්ගලයාට එය අවශ්‍ය වනු ඇත.

අදාළ ලිපි