ටනලය ක්රියාත්මකයි, එසේනම් පෞද්ගලික නම තවමත් අසාර්ථක වන්නේ ඇයි?
ක්රියාත්මක වන ටනලයක් යනු සේවාදායකයා නිවැරදි විසදුම්කරුගෙන් ඇසුවා යන්න නොවේ. කවුද පිළිතුරු දුන්නේ දැයි පරීක්ෂා කර, පසුව සැබවින්ම අවශ්ය කලාපය පමණක් ඉදිරියට යවන්න.
සම්බන්ධතාවයේ සියල්ල නිවැරදි ලෙස පෙනේ: ටනලය ක්රියාත්මකයි, කොන්සෝලය පෞද්ගලික අන්ත ලක්ෂ්යය පෙන්වයි, නමුත් සෑම ඉල්ලීමක්ම නම් විභේදනයේදී අසාර්ථක වේ. ස්වාභාවික පියවර වන්නේ ටනලයට දොස් පැවරීමයි, එය සාමාන්යයෙන් නිර්දෝෂී බව පෙනේ. ඉල්ලීම පෞද්ගලික කලාපය ගැන කිසිවක් නොදන්නා සේවාදායකයකට යවනු ලැබේ. කිසිදු මාර්ගගත කිරීමේ වෙනසක් එම පිළිතුර වෙනස් නොකරයි, මන්ද ගැටලුව වන්නේ කාගෙන් ඇසුවා ද යන්නයි.
ඉල්ලීම කුමන විසදුම්කරු වෙත ළඟා වුණා ද?
ටනලය දෙස බැලීමට පෙර සෑම සබැඳියකට සම්බන්ධ විසදුම්කරු සොයන්න. Linux විසදුම්කරු තත්ත්ව විධානය මගින් සෑම සබැඳියකම සේවාදායක පෙන්වයි, macOS එහි DNS වින්යාස ඩම්පයේ විෂය පථ සහිත විසදුම්කරු පෙන්වයි. පිළිතුර තවමත් ගෘහ රවුටරයෙන් පැමිණේ නම්, ටනල සබැඳිය කිසි විටෙක උපදේශ නොකර ඇත.
resolvectl status
scutil --dns | head -40
dig +short internal.example.com
මෙහි අවස්ථා දෙකක් මිශ්ර වේ: විසදුම්කරු ලිපිනයක් තල්ලු කරන සේවාදායකය සහ එය ක්රියාකාරී සබැඳියේ ස්ථාපනය කරන සේවාදායකයා. පැතිකඩේ විකල්පය තිබිය හැක, ලොගය එය පැමිණෙන බව පෙන්විය හැක, නමුත් මෙහෙයුම් පද්ධතිය පැරණි සේවාදායකය දිගටම භාවිත කරයි. ලොගය සබැඳිය වාර්තා කරන දෙය සමඟ සසඳා, සබැඳිය විශ්වාස කරන්න.
ක්ලවුඩ් ජාලය සැබවින්ම පිළිතුරු දෙන ලිපිනයක් භාවිත කරන්න
ක්ලවුඩ් ජාල සාමාන්යයෙන් පෞද්ගලික නම්වලට පිළිතුරු දෙන්නේ පරාසයේ පාදමෙන් දෙකක් ඉදිරියේ ඇති වෙන් කළ ලිපිනයක් හරහා ය, එබැවින් 10.0.0.0 න් ආරම්භ වන ජාලය 10.0.0.2 හි පිළිතුරු දෙයි. සමහර සැපයුම්කරුවන් පරාසය නොදැන ක්රියා කරන සබැඳි-දේශීය විසදුම්කරුවෙකු ද ප්රකාශ කරයි, ජාලය වෙනත් අයෙකු ගොඩනගා ඇති විට එය උපකාරී වේ. අපේක්ෂක ලිපිනය කිසිවෙකුට යැවීමට පෙර සෘජුවම අසන්න. විසදුම්කරුවෙකු නොවන ලිපිනයක් ගිනිපවුරු බැහැර කිරීමක් මෙන්ම පෙනේ, මන්ද ඉල්ලීම කිසි විටෙක පිළිතුරක් නොලබයි.
සෘජු ඉල්ලීම ජාලය තුළින් පිළිතුරු දුන්නත් ටනලය හරහා නොදෙන්නේ නම්, විසදුම්කරු නිවැරදිය, ලක්ෂ්ය දෙක අතර මාර්ගය නොවේ. එම ප්රතිඵලය විමර්ශනය සේවාදායක පැතිකඩ වෙත නොව මාර්ග, යැවීම සහ ප්රවේශ නීති වෙත ගෙන යයි.
ටනලය නාම අවකාශය ගෙන යන්නේ නැත
පැකට් ගමන් කරයි; නම් ගමන් නොකරයි. සෑම පැත්තකටම කුමන නාම අවකාශය අනෙක් පැත්තට අයත් දැයි කිව යුතුය, එය කලාපය ඇති තැනැත්තා සතු වෙනම වස්තුවකි. සාමාන්ය ස්වරූපය වන්නේ එක් නාම අවකාශයක් සඳහා යැවීමක්, ටනලය හරහා ළඟා විය හැකි විසදුම්කරු වෙත යොමු කර ඇත.
ප්රායෝගිකව සෑම දිශාවකටම තමන්ගේම නීතියක් අවශ්ය වේ, මන්ද කලාපය ඇති පැත්ත ඉල්ලීම ඉදිරියට යැවිය යුතුය. දිශා දෙකටම ඉල්ලීමේ මූලාශ්රය මාර්ගගත කර අවසර දිය යුතුය, පිළිතුරු දෙන පැත්ත අන්තර්ජාලයට නොව ටනලය හරහා පිළිතුරු ආපසු යැවිය යුතුය. යැවීම පටුව තබන්න, පෞද්ගලික නාම අවකාශය පමණක් සබැඳිය මත රඳා පවතින පරිදි. සෑම ඉල්ලීමක්ම එය හරහා යැවීම කුඩා යැපීමක් ටනලය වැටෙන මොහොතේ සම්පූර්ණ බාධාවක් බවට පත් කරයි.
මායිම් පිළිවෙලින් තරණය කරන්න
ක්රියාකාරී සබැඳියේ ස්ථාපිත විසදුම්කරු, පසුව එම විසදුම්කරුට සෘජු ඉල්ලීමක්, පසුව එම ඉල්ලීමම දුර පැත්තෙන්, අවසානයේ එම නමම භාවිත කරන යෙදුම පරීක්ෂා කරන්න. සෑම පියවරක්ම එක් මායිමක් හුදකලා කරයි, එබැවින් අසාර්ථකත්වය විමර්ශනය නැවත ආරම්භ කරනවාට වඩා කොහේ බැලිය යුතු දැයි කියයි. යෙදුම අසාර්ථක වන අතර පිළිතුර ක්රියා කරන්නේ නම්, එය DNS නොව සහතික විශ්වාසය හෝ API ප්රතිපත්තිය පෙන්වයි. එම දෝෂ සැබෑ ය, කිසිදු විසදුම්කරු වෙනසක් ඒවා අලුත්වැඩියා නොකරයි.
කුමන පියවර අසාර්ථක වුණා ද යන්න ලියන්න. එම එකම පේළිය ඊළඟ පුද්ගලයාට අවශ්ය දෙයයි, එය සටහන් කිරීමට තත්පර දහයක් ගත වේ.
ඊළඟ පුද්ගලයාට සොයාගත හැකි තැන දාමය තබන්න
තල්ලු කළ විසදුම්කරු, යැවීමේ නීතිය, අවසර ලත් ඉල්ලීම් මූලාශ්රය සහ පිළිතුරු දෙන අන්ත ලක්ෂ්යය එකම තැනක සටහන් කරන්න. පෞද්ගලික නම නැවත අසාර්ථක වන විට, වාර්තාව පෙන්වන්නේ ටනලය ගියා ද, විසදුම්කරු ලිපිනය වෙනස් වුණා ද, නැතහොත් නීතියක් පටු වුණා ද යන්නයි. එය නොමැතිව සෑම සිදුවීමක්ම ශුන්යයෙන් ආරම්භ වී එම අනුමාන තුනෙන්ම අවසන් වේ.
වාර්තාව නිවැරදිව තබා ගැනීමට තරම් කෙටි කරන්න: පේළි හතරක්, දිනයක්, සහ එක් එක් කොටසේ හිමිකරුගේ නම. පැරණි වාර්තාවක් නොමැති වීමට වඩා නරකය, මන්ද එය වැරදි වුවත් අධිකාරී ලෙස පෙනේ.