WireGuard DNS තල්ලු නොකරයි: පුද්ගලික BIND කලාපයක් සේවා කිරීම

හස්ත සම්ප්‍රේෂණය යතුරු සහ අවසර ලත් IP රැගෙන යයි, කිසිවිටෙක විසඳනයක් රැගෙන නොයයි. මෙහි සූදානම් පුද්ගලික BIND 9 කලාපයක් සහ එය විසඳීමට සලස්වන සබැඳිය අනුව ක්ලාන්ත ප්‍රතිපත්තිය ඇත.

ඔබ WireGuard එසවූවා, උමඟ රථවාහන ගමන් කරවයි, නමුත් අභ්‍යන්තර නාමය තවමත් විසඳෙන්නේ නැත. ඊළඟ පියවර සාමාන්‍යයෙන් WireGuard වින්‍යාසයේ DNS සැකසුමක් සෙවීමයි, අනෙක් සමහර VPN කරන පරිදි සහකරුවෙකුට විසඳනයක් තල්ලු කළ හැකි යැයි සිතා. එසේ කළ නොහැක. හස්ත සම්ප්‍රේෂණය යතුරු, අතුරුමුහුණත් ලිපින සහ අවසර ලත් IP රැගෙන යයි, DNS සේවාදායක හෝ සෙවුම් වසම් සඳහා ක්ෂේත්‍රයක් එහි නැත. විසඳන ප්‍රතිපත්තිය ක්ලාන්තයේ ජීවත් වේ, නිවැරදි කිරීමද එහිම ය.

උමඟ සහ විසඳනය වෙන වෙනම ගිවිසුම්

WireGuard හිතාමතාම කුඩාය. ඔබ ලැයිස්තුගත කරන ලිපින සඳහා පැකට් ගෙන යයි සහ සහකරුවන් සත්‍යාපනය කරයි; එම ස්ථරයට ඉහළින් සියල්ල ඔබේ නිර්මාණයයි. OpenVPN dhcp-option DNS තල්ලු කළ හැක්කේ එහි පාලන නාලිකාව වින්‍යාසය රැගෙන යන නිසාය, එම වෙනස දෙක අතර ගමන් කරන්නන් ගැටෙන්නට සලස්වයි.

එබැවින් ක්‍රියාකාරී උමඟක් නාම විසඳුම ගැන කිසිවක් නොකියයි. ක්ලාන්තයට 10.90.0.1 දක්වා පරිපූර්ණ මාර්ගයක් තිබිය හැකි අතර එසේ වුවද එහි ප්‍රශ්න පොදු විසඳනයකට යැවිය හැක, එබැවින් රෝග ලක්ෂණය “VPN DNS කැඩුවා” ලෙස පෙනේ, නමුත් DNS කිසිවිටෙක VPN දෙසට යොමු වී නොතිබුණි.

පුනරාවර්තී විසඳනයක් නොවී කලාපය සේවා කරන්න

සේවාදායක පැත්ත කුඩා අධිකාරී කලාපයකි, සාමාන්‍ය විසඳනයක් නොවේ. මෙම උදාහරණයේ ද්වාරය 10.90.0.1, ක්ලාන්ත 10.90.0.0/24, සහ ඔබට වැදගත් යෙදුම 10.60.0.20 ලෙස පිළිතුරු දෙයි.

දෙවන කොටසක් සෑදීම වෙනුවට මෙම සැකසුම් දැනට ඇති options කොටසට ඒකාබද්ධ කරන්න:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

පසුව කලාපය සහ එහි ගොනුව ප්‍රකාශ කරන්න:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

නැවත පූරණය කිරීමට පෙර තහවුරු කරන්න, මන්ද පූරණයේදී වාක්‍ය ඛණ්ඩන දෝෂයක් එය සේවා කරන සෑම කලාපයකටම මුළු සේවාදායකයම බිම හෙළයි:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP සහ TCP 53 VPN අතුරුමුහුණතේ පමණක් විවෘත කරන්න. පොදු අතුරුමුහුණතේ පුද්ගලික අධිකාරියක් ප්‍රකාශයට පත් කිරීම ප්‍රශ්න සහ ගණන් කිරීම යන දෙකම ඇරයුම් කරයි, සහ ද්විතීයිකයකට සැබවින්ම අවශ්‍ය නොවේ නම් allow-transfer වසා තැබිය යුතුය.

ක්ලාන්තය ඒ දෙසට හරවන්න, සෑම සබැඳියකටම

සම්බන්ධතාවය NetworkManager සතු යැයි සහ විසඳනය systemd-resolved යැයි උපකල්පනය කරන්න. පළමුව දැනට ඇති ප්‍රතිපත්තිය කියවන්න, විශේෂයෙන් ඕනෑම මූල මාර්ගගත කිරීමේ වසමක්, මන්ද ~. ප්‍රවේශය ඔබ එකතු කිරීමට යන දෙය ඉක්මවා යයි.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

ටිල්ඩ් යනු වැදගත් අක්ෂරයයි. එය වසම මාර්ගය-පමණක් ලෙස සලකුණු කරයි: corp.example යටතේ ඇති නාම මෙම සබැඳියේ DNS සේවාදායකයට යයි, සහ වසම කෙටි නාම සෙවුම් උපසර්ගයක් ලෙස එකතු නොවේ. එය නොමැතිව, portal ටයිප් කිරීම portal.corp.example විසඳීම ආරම්භ කරයි, එය ඔබට පහසු සහ අනෙක් සැමට පුදුමයකි. ටිල්ඩ් උද්ධෘත ලකුණු තුළ තබන්න, මන්ද උද්ධෘත නොමැති එකක් ඔබේ නිවස්න ඩිරෙක්ටරියට යොමු කිරීමට බලා සිටින ෂෙල් ප්‍රසාරණයකි.

අතුරුමුහුණත සතු කළමනාකරු හරහා වෙනස ක්‍රියාත්මක කරන්න, පසුව සම්බන්ධතාවය නැවත සම්බන්ධ කරන්න. එම අතුරුමුහුණතට දෙවන wg-quick අවස්ථාවක් ආරම්භ නොකරන්න; හිමිකරුවන් දෙදෙනෙක් මාර්ග ගැන ගැටෙනු ඇත, ඔවුන්ගෙන් එකෙක් නරකම මොහොතේ ජය ගනී.

නාමයට පෙර මාර්ගය තහවුරු කරන්න

ක්ලාන්තයෙන් නාමය විමසා, පිළිතුර සහ එය නිපදවූ සේවාදායකය යන දෙකම තහවුරු කරන්න:

resolvectl query portal.corp.example

එය 10.60.0.20 ලබා දෙන්නේ නම්, DNS ගිවිසුම ඉටු වී ඇත. කාලය ඉකුත් වුවහොත්, පළමුව 10.90.0.1 දක්වා මාර්ගය, පසුව ගිනි පවුරු රීතිය, පසුව සේවාදායකයේ allow-query පරීක්ෂා කරන්න. මෙම සැකසුමේ නාම විසඳුම් අසාර්ථකතා සෑම විටම පාහේ ළඟා වීමේ හැකියාව හෝ ACL මිස කලාප ගොනුව නොවේ. ක්ලාන්තයේ සිට පිටතට වැඩ කරන්න, මන්ද ප්‍රශ්නයක් කිසිවිටෙක නොපැමිණියේ ඇයි කියා සේවාදායකයට කිව නොහැක.

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

තවම ස්වයංක්‍රීය නොවන දේ

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

බලඇණි තම සැපයුම් පද්ධතිය හරහා මෙම ක්ලාන්ත ප්‍රතිපත්තිය ස්වයංක්‍රීය කළ හැක, නමුත් ප්‍රතිපත්තිය හිමිකරු සහිත වෙනම වස්තුවක් ලෙසම පවතී. BIND 9 යොමුව ඉහත භාවිත කළ ශ්‍රවණ සහ ප්‍රශ්න පාලන ආවරණය කරයි, ඔබ ස්ථාපනය කළ සංස්කරණය සඳහා හැසිරීම තහවුරු කිරීමට නිවැරදි ස්ථානය එයයි.

ඊළඟ පියවර: කලාපයේ අනුක්‍රමික අංක වැඩිවීම සහ පරීක්ෂණ විධාන ඔබේ වෙනස්කම් ක්‍රියාපටිපාටියට එකතු කරන්න, එවිට කිසිදු වාර්තා සංස්කරණයක් පරීක්ෂා නොකර නිෂ්පාදනයට නොපැමිණේ.

අදාළ ලිපි