OpenVPN DNS සේවාදායකයක් යැවූ නමුත් Linux එය නොසලකා හරියි

යවන ලද DNS සේවාදායකය ලොගයේ ඇත, ටනලය ඉහළට ඇත, සහ අභ්‍යන්තර නම් තවමත් අසාර්ථක වේ. යැවීමේදීම කිසිවක් කැඩී නැත; සැකසුම පැමිණ එහිම නතර විය. යවන ලද DNS විකල්පය පාරිභෝගිකයාට යවන පණිවිඩයක් මිස මෙහෙයුම් පද්ධතියේ විසඳුම්කරුට දෙන උපදෙසක් නොවේ, සහ ඒ දෙක අතර මාරුවීම තමයි මෙවැනි අවස්ථා බොහොමයක් අවසන් වන තැන. පරීක්ෂණ පහක්, පිළිවෙලින්, නොසිදු වූ මාරුවීම සොයා ගනී.

පරීක්ෂණය එක: සම්බන්ධතාවය ආරම්භ වන ආකාරය

සම්බන්ධතාවයේ හිමිකරු තීරණය කරන්නේ විසඳුම්කරු සැකසුම් යෙදිය හැක්කේ කාටද යන්නයි. ෂෙලයකින් දෙන සෘජු openvpn විධානයට තමන්ගේ ක්‍රියාවලිය හැර වෙන කිසිවක් නැත, එහෙත් systemd ඒකකයකට, NetworkManager ට හෝ විකුණුම්කරුගේ පාරිභෝගිකයාට DNS ප්‍රකාශයට පත් කිරීමට තමන්ගේම ක්‍රමයක් ඇත. ඒවායින් එකක්වත් උපකල්පනය කිරීමට පෙර ක්‍රියාවලි ලැයිස්තුව සහ ඒකකයේ නම කියවන්න.

විධාන රේඛා ක්‍රියාවලියක් ස්වයංක්‍රීයව NetworkManager සම්බන්ධතාවයක් නොවේ, NetworkManager සම්බන්ධතාවයක් ස්වයංක්‍රීයව resolv.conf ලියූ දෙය නොවේ. ඒ උපකල්පන දෙක මෙම පරීක්ෂණයේ නාස්ති වූ බොහෝ පැය පැහැදිලි කරයි. ඔබ ඇත්තටම දකින අතුරුමුහුණත සඳහා කුමන සංරචකය DNS ප්‍රකාශයට පත් කරයිදැයි අසන්න.

ඉදිරියට යාමට පෙර හිමිකරු ලියා තබන්න. ඊළඟ සෑම පරීක්ෂණයක්ම ඒ මත රඳා පවතී.

පරීක්ෂණය දෙක: විසඳුම්කරුගේ සබැඳිය ඇත්තටම දරන්නේ කුමක්ද

systemd-resolved සත්කාරකයක, resolvectl status සෑම සබැඳියක්ම එහි DNS සේවාදායක සහ වසම් සමඟ ලැයිස්තුගත කරයි. ටනල සබැඳිය සොයා එහි ඇතුළත් කිරීම් කියවන්න, සහ අතුරුමුහුණතේ නම tun0 යැයි නොසිතන්න, මන්ද අංකනය සෑදීමේ අනුපිළිවෙල අනුගමනය කරයි. යවන ලද ලිපිනය සබැඳියේ නොමැති නම්, අසාර්ථක වූයේ විමසුම නොව මාරුවීමයි.

ලිපිනය තිබේ නම්, ඊළඟ ප්‍රශ්නය එම සබැඳිය කුමන වසම් ඉල්ලා සිටීද යන්නයි. වසම් ලැයිස්තුවක් නැති සබැඳියක් පිළිතුරු දෙන්නේ සෘජුව අසන නම්වලට පමණක් වන අතර split-DNS වින්‍යාසයකට එය අවශ්‍ය වන්නේ කලාතුරකිනි. ලිපිනය පමණක් අවශ්‍ය නමුත් ප්‍රමාණවත් නොවේ.

කිසියම් නිගමනයකට එළඹීමට පෙර විසඳුම්කරුගේ ප්‍රතිදානයේ සබැඳි නාමය VPN ලොගයේ අතුරුමුහුණත් නාමය සමඟ සසඳන්න. එහි ඇති නොගැලපීම සාමාන්‍යයෙන් අදහස් කරන්නේ ලොග පේළිය වෙනත් ක්‍රියාවලියකින් පැමිණි බවයි.

පරීක්ෂණය තුන: නාම අවකාශය එම සබැඳිය තෝරයිද

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

වසම් පැවරීම පරීක්ෂා කරන්න, සේවාදායක ලිපිනය පමණක් නොවේ. ~corp.example ලෙස ලියා ඇති වසමක් මාර්ගගත කිරීමේ වසමක් වන අතර ටිල්ඩා ලකුණ නාමය ගැලපෙන ආකාරය වෙනස් කරයි.

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

පරීක්ෂණය හතර: එක් හිමිකරුවෙක්, දෙදෙනෙක් නොවේ

NetworkManager දැනටමත් VPN සහ විසඳුම්කරු තත්ත්වය කළමනාකරණය කරන්නේ නම්, සම්බන්ධයක් නැති hook පිටපතක් එකතු කිරීම තරඟකාරී ලේඛකයන් නිර්මාණය කරයි. පැකේජය systemd-resolved සඳහා සපයන hook එක ආධාරක ඒකාබද්ධතාවයක් වන අතර එය නිශ්චිත ජීවන චක්‍රයක් අපේක්ෂා කරයි: script-security 2, up මාර්ගයක්, up-restart, down මාර්ගයක් සහ down-pre. ඒ විකල්ප නිසා ලියාපදිංචිය සහ ඉවත් කිරීම පළමු සම්බන්ධතාවයේදී පමණක් නොව නිවැරදි මොහොතේ සිදු වේ.

මාර්ගෝපදේශයකින් පිටපත් කළ උදාහරණයක් වෙනුවට පැකේජයෙන් ස්ථාපිත මාර්ගය භාවිතා කරන්න. අවසර ද වැදගත් වේ, මන්ද hook එක වරප්‍රසාද අඩු කිරීමෙන් පසු ක්‍රියා කරයි.

එහි ප්‍රතිදාන ඉලක්කය වෙනස් කිරීමට බෙදාහැරීමක විසඳුම්කරු පිටපතක් සංස්කරණය කිරීම එක් සත්කාරකයක විසඳුමක් සටහන් කරයි. එය සාමාන්‍ය අලුත්වැඩියාවක් නොවේ.

පරීක්ෂණය පහ: නැවත සම්බන්ධ වීමෙන් පසු එම ප්‍රතිඵලයම

නැවත සම්බන්ධ වී සබැඳිය නැවත කියවන්න. එක් වරක් පෙනී ඊළඟ සංක්‍රාන්තියේදී අතුරුදහන් වන ලියාපදිංචිය මෙම සම්පූර්ණ ලැයිස්තුව පවතින්නේ එය නිසාම වන අසාර්ථකත්වයයි. අත්හිටුවීමෙන් පසු, බලකාගත නැවත සම්බන්ධ වීමෙන් පසු සහ විසඳුම්කරු සේවාව නැවත ආරම්භ කිරීමෙන් පසු පරීක්ෂා කරන්න. සෑම සංක්‍රාන්තියක්ම වෙනස් අනුපිළිවෙල උපකල්පනයක් පරීක්ෂා කරයි.

නැවත සම්බන්ධ වීමේදී පරීක්ෂණ පහම සමත් වූ පසුව පමණක් යවන ලද සැකසුම් භාවිතයේ ඇතැයි පැවසිය හැක. ඊට පෙර සෑම දෙයක්ම වාසනාවන්ත මොහොතක ඡායාරූපයකි.