AWS Client VPN DNS: subnet නොව VPC resolver භාවිත කරන්න

endpoint පිහිටන්නේ 10.0.8.0/24 තුළයි, එබැවින් resolver 10.0.8.2 විය යුතුය. මෙය මා වැඩිපුරම අසන තර්කය වන අතර එය දෙවරක් වැරදිය. Route 53 Resolver ප්‍රාථමික VPC IPv4 පරාසයට දෙකක් එකතු කළ අගයට පිළිතුරු දෙයි, එය 10.0.0.0/16 VPC එකකට 10.0.0.2 වේ, endpoint භාවිත කරන subnet කුමක් වුවත්. දෙවන වැරැද්ද වඩාත් නිහඬය: endpoint තුළ නිවැරදි ලිපිනය තැබීමෙන් අදහස් වන්නේ client හි මෙහෙයුම් පද්ධතිය එයින් කිසිදාක යමක් අසනවා යන්න නොවේ. දෙකම එකම රෝග ලක්ෂණය ලබා දෙයි: නම් විභේදනය සමහර client වලට වැඩ කරන අතර අනෙක් ඒවාට අසාර්ථක වේ.

මිථ්‍යාව ආරම්භ වන්නේ subnet සම්බන්ධතාවයෙන්

සම්බන්ධතාවය යනු client සම්බන්ධතා සඳහා elastic network interfaces පිහිටන තැන ගැනය, කුමන resolver ලිපිනයක් පවතීද යන්න ගැන නොවේ. endpoint හි subnet client වලට VPC තුළ ලිපිනයක් ලබා දෙන අතර ඒවායින් එකක්වත් තමන්ගේම resolver එකක් දරන්නේ නැත.

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

ප්‍රාථමික VPC පරාසයෙන් ලිපිනය ගණනය කරන්න

VPC හි ප්‍රාථමික IPv4 CIDR ගෙන ජාල ලිපිනයට දෙකක් එකතු කරන්න. 10.0.0.0/16 10.0.0.2 ලබා දෙයි, 172.31.0.0/16 172.31.0.2 ලබා දෙයි, ද්විතීයික පරාසයක් ඇති VPC resolver ප්‍රාථමිකයේම තබා ගනී. එම VPC තුළ 10.0.8.0/24 subnet එය චලනය නොකරයි. endpoint ස්පර්ශ කිරීමට පෙර VPC ID අසල ලිපිනය ලියන්න, මන්ද එම සංඛ්‍යාව VPC හි ගුණාංගයක් මිස සම්බන්ධතාවයේ නොවේ.

VPC link-local ලිපිනය 169.254.169.253 මතද පිළිතුරු දෙයි. එම ලිපිනය VPC තුළින් ළඟා විය හැකි නමුත් උමගේ අනෙක් කෙළවරේ ඇති ලැප්ටොප් එකකට එය සාමාන්‍ය මාර්ගගත ගමනාන්තයක් නොවේ.

එබැවින් වලංගු resolver ලිපින දෙකක් ඇති අතර ඉන් එකක්වත් subnet සමඟ දෙක එකතු කළ අගය නොවේ.

endpoint සැකසුම කරන දේ සහ නොකරන දේ

Client VPN endpoint හි DNS සේවාදායක ක්ෂේත්‍ර ඇති අතර console VPC resolver විකල්පයක් ලබා දෙන තැන එම අදහසම පුරවයි. ඒවා සැකසීමෙන් සම්බන්ධතාවය ස්ථාපිත කරන විට සේවාව client වලට ලබා දෙන දේ වෙනස් වේ. එය කළමනාකරණය නොකළ OpenVPN client එකක් එම අගය සමඟ කරන දේ වෙනස් නොකරයි, මන්ද client එය මෙහෙයුම් පද්ධතියට යෙදිය යුතුය. «මගේ Mac එකේ වැඩ කරයි නමුත් Linux පෙට්ටියේ නොවේ» යන්න පැමිණෙන්නේ එම පරතරයෙනි.

Linux හි resolver ඒකාබද්ධතාවය සම්බන්ධතා කළමනාකරුට හිමිය, පරිශීලකයාට නොවේ. /etc/resolv.conf අතින් සංස්කරණය කිරීමෙන් ලිපිනය එක් සැසියකට වැඩ කරන බවත් පසුව නැවත සම්බන්ධ වීමේදී අතුරුදහන් වන බවත් ඔප්පු වේ — එබැවින් නිවැරදි කළ බොහෝ අවස්ථා ඊළඟ දින උදෑසන නැවත පැමිණේ.

සම්බන්ධ වූ පසු client හි සක්‍රීය resolver පරීක්ෂා කරන්න, endpoint හි වින්‍යාස පිටුව නොවේ.

split tunneling නිවැරදි resolver පරාජය කළ හැක

split tunneling සමඟ උමගට තල්ලු කළ මාර්ග පමණක් භාවිත වේ. resolver ලිපිනය කිසිදු මාර්ගයකින් ආවරණය නොවන්නේ නම්, විමසුම දේශීය අතුරුමුහුණත හරහා පිටව ගොස් ඔබේ ගෘහ රවුටරය පිළිතුරු දෙයි. endpoint හි ලිපිනය තවමත් නිවැරදි වන අතර සෙවීම තවමත් අසාර්ථක වේ. resolver සඳහා මාර්ගය එකතු කර නැවත පරීක්ෂා කරන්න.

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

Amazon DNS ලිපිනය සඳහා security groups විවෘත නොකරන්න

සෙවීම් කාලය ඉක්මවන විට ස්වාභාවික ප්‍රවණතාවය වන්නේ resolver ලිපිනයට UDP 53 ඉඩ දෙන නීතියක් එකතු කිරීමයි. security groups සහ network ACL Amazon DNS රහස්‍යතා තමන්ගේම DNS අවස්ථාවකට යන රහස්‍යතා මෙන් පෙරා නොගන්නා බව AWS ලේඛනගත කරයි. එම නීති විවෘත කිරීම VPC resolver සඳහා කිසිවක් වෙනස් නොකරන අතර හේතුවකින් තොරව මායිම පුළුල් කරයි. ඔබම පවත්වාගෙන යන resolver වෙනස් අවස්ථාවක් වන අතර එයට සැබවින්ම තමන්ගේම නීති අවශ්‍ය වේ.

ඔබේ නිර්මාණයේ දෙකම තිබේ නම්, කිසිදු නීතියක් සංස්කරණය කිරීමට පෙර client ඇත්ත වශයෙන්ම අඟවන්නේ කුමකටදැයි පරීක්ෂා කරන්න.

මාර්ගය තහවුරු කරන්න, පසුව වෙනත් දෙයක් මනින්න

පොදු නාමයක් විසඳන්න, VPC සමඟ සම්බන්ධිත පෞද්ගලික සත්කාරක කලාපයක ලියාපදිංචි පෞද්ගලික නාමයක් විසඳන්න, ඒ දෙක අතර client හි සක්‍රීය resolver කියවන්න. එම අනුපිළිවෙල «resolver ලිපිනය වැරදිය» යන්න «කලාපය සම්බන්ධ නැත» සහ «client සැකසුම නොසලකා හැරියා» යන්නෙන් වෙන් කරයි. එකකට වෙනස් නිවැරදි කිරීමක් ඇති අතර කිසිවක් throughput ගැටලුවක් නොවේ.

සාර්ථක සෙවීමක් තිරසාර මාරු කිරීමේ වේගය ගැන කිසිවක් නොකියයි, එබැවින් වාර්තා කරන විට මෙම කථා දෙක වෙන් කර තබන්න.