VPN ආරම්භ වූ පසු Azure VM IMDS හෝ WireServer වෙත ළඟා නොවේ

VM ක්‍රියාත්මකයි, VPN සේවාලාභියා සම්බන්ධ වී ඇතැයි කියයි, මිනිත්තු කිහිපයකට පසු Azure නියෝජිතයා අසුබ ස්ථාවරය වාර්තා කිරීම ආරම්භ කරයි. සමහර විට SSH නොනැසී පවතී, පෝටලයේ Run Command නොපවතී, එය මිනිසුන් රූට් වගුව වෙනුවට නියෝජිතයා දෙසට යොමු කරයි. උමඟ ඉහළ ආ විට අමුත්තාගේම යැවීමේ තීරණ වෙනස් විය, සාමාන්‍යයෙන් වේදිකා ලිපින දෙකක් පළමු ගොදුරු වේ. මම මෙය නියෝජිත දෝෂයක් ලෙස සැලකීමට පෙර රූටින් රෝග ලක්ෂණයක් ලෙස සලකමි.

රෝග ලක්ෂණය කැඩුණු නියෝජිතයෙකු මෙන් පෙනේ

පහත ලිපින දෙකම විසඳුමක් ලෙස යෝජනා කෙරේ, නමුත් ඒවා එකම සේවාව නොවේ. එකකට /32 පිටපත් කිරීම අනෙකට වැඩ කළ නිසා—එලෙසම තාවකාලික විසඳුමක් කිසිවෙකු ඉවත් කිරීමට බිය වන ස්ථිර වින්‍යාසයක් බවට පත්වේ.

වැඩ කරන අනුපිළිවෙල නම්: පළමුව අසාර්ථක ඇමතුම ඇත්තෙන්ම කුමන ලිපිනය ඉලක්ක කරන්නේ දැයි තහවුරු කරන්න, පසුව අමුත්තා එය විසඳන ආකාරය කියවන්න. අනෙක් සියල්ල අමතර පියවර සහිත අනුමානයක් සහ දිගු වෙනස්කම් කවුළුවක් වේ.

168.63.129.16 පොදු ගමනාන්තයක් නොවේ

168.63.129.16 යනු Azure හි විශේෂ අතථ්‍ය වේදිකා ලිපිනය වන අතර, එහි එක් භූමිකාවක් වන්නේ WireServer, එය VM නියෝජිතයා ෆැබ්‍රික් සමඟ කතා කිරීමට භාවිත කරයි. Microsoft ලේඛනගත කරන්නේ TCP 80 සහ 32526 වරාය වෙත නියෝජිත ගමන් විදුලිය ලබා ගත හැකි ලෙස පවතින්නට ඕනෑ බවයි. මෙය සාමාන්‍ය අන්තර්ජාල සත්කාරකයක් නොවන අතර, සම්පූර්ණ උමං VPN එකක් එය දුරස්ථ පිටවීමකට ගෙන යා නොයුතුය. ඒ නිසා සුවපත් ලෙස පෙනෙන උමඟකට පවා නියෝජිතයා බඩගින්නේ තැබිය හැක.

වේදිකා ලිපින ලේඛනය ද කියන්නේ මෙම ලිපිනය පරිශීලක-නිර්වචිත මාර්ගවලට යටත් නොවන බවයි, එය Azure ෆැබ්‍රික්හි ගුණාංගයක් මිස ඔබේ අමුත්තා ගැන පොරොන්දුවක් නොවේ. ස්ථානීය ෆයර්වෝල් නියමයක් හෝ VPN සේවාලාභියාගේම රූටින් ප්‍රතිපත්තියක් තවමත් මාර්ගය කැඩිය හැක, ඒවායින් කිසිවක් VNet හි රූට් වගුවේ ජීවත් නොවේ.

ගැටලුව වාර්තා කරන්නේ නියෝජිතයා නම්, යමක් නැවත ස්ථාපනය කිරීමට පෙර සේවා තත්ත්වය සහ එම ලිපිනයට යන මාර්ගය පරීක්ෂා කරන්න.

169.254.169.254 ට තමන්ගේම නීති ඇත

169.254.169.254 යනු Azure Instance Metadata Service සඳහා link-local ලිපිනයයි. එයට යන ඉල්ලීම්වලට තමන්ගේම කොන්දේසි ඇත: ප්‍රාථමික NIC සහ ප්‍රාථමික IP, ලිපිනයට සහාය දෙන DHCP වින්‍යාසය, සහ ඕනෑම HTTP ප්‍රොක්සියක් මගහැරීම. ඒවා දුරස්ථ VPN පිටවීමක් හෝ අත්තනෝමතික අන්තර්ජාල ද්වාරයක් හරහා යැවීම Microsoft විස්තර කරන ප්‍රවේශ ආකෘතිය නොවේ.

එම ප්‍රොක්සි වගන්තිය මාර්ගය අලුත්වැඩියා කර තවමත් අසාර්ථකකම් දකින අය අල්ලා ගනී. අමුත්තාගේ HTTP ප්‍රොක්සියකට IMDS කැඩිය හැකි අතර ip route get ඔබ බලාපොරොත්තු වන අතුරුමුහුණත හරියටම ලබා දෙයි, එබැවින් මාර්ග සමඟ ප්‍රොක්සි ව්‍යතිරේක ද පරීක්ෂා කරන්න.

මෙය නිදොස් කරන අතරතුර මෙටාදත්ත ප්‍රතිචාර සහාය ටිකට්පතක අලවන්න එපා. ඒවා සිද්ධියට වඩා දිගු කල් පවතින අක්තපත්‍ර සහ අවස්ථා විස්තර ගෙන යා හැක.

අමුත්තාගේ ප්‍රතිපත්ති රූටින් කියවන්න, ප්‍රධාන වගුව පමණක් නොව

Linux අමුත්තෙකුගේ, කියවීම-පමණක් විධාන තුනක් ස්ථර වෙන් කරයි: ප්‍රතිපත්ති නීති සඳහා ip -4 rule show, පසුව කර්නලය ඇත්තෙන්ම ගන්නා තීරණ සඳහා ip -4 route get 168.63.129.16 සහ ip -4 route get 169.254.169.254. VPN සම්බන්ධ වීමට පෙර සහ පසුව ඒවා ධාවනය කරන්න. එම ප්‍රතිදාන දෙක අතර වෙනස ඔබේ වෙනස්කම් කුලකයයි, සහ සේවාලාභියා කළ දේ ගැන ඕනෑම අනුමානයකට වඩා එය ප්‍රයෝජනවත් වේ.

ප්‍රතිපත්ති නීති ස්ථාපනය කරන VPN සේවාලාභියෙකුට ප්‍රධාන වගුව ස්පර්ශ නොකර තබා එම සෙවීම් හරවා යැවිය හැක. ඒ නිසා ප්‍රධාන වගුව පමණක් අලුත්වැඩියා කරන විසඳුම එක් සත්කාරකයක වැඩ කරන ලෙස පෙනී ඊළඟ එකේ කිසිවක් නොකරයි. බහු NIC සහිත අමුත්තන් එම ගැටලුවම අනෙක් පැත්තෙන් එකතු කරයි, මන්ද පිළිතුර රීතිය කුමන NIC සහ මූල ලිපිනය තෝරා ගන්නේ ද යන්න මත රඳා පවතී.

පැරණි ද්වාරය හරහා /32 මාර්ග දෙකම එකතු කරන වට්ටෝරුවට විරුද්ධ වන්න. link-local වේදිකා මාර්ගය සහ සාමාන්‍ය WAN ඊළඟ පිම්ම විවිධ වස්තූන් වන අතර, සර්වව්‍යාපී ව්‍යතිරේකය සැබෑ ප්‍රතිපත්ති ගැටුම සඟවයි.

පරිපාලනය සහ ප්‍රතිසාධනය වෙන් කර තබන්න

ඔබේ SSH හෝ RDP ප්‍රතිචාරය ද සම්පූර්ණ උමං පෙරනිමියෙන් අල්ලා ගත හැක, නමුත් එය වේදිකා අන්ත ලක්ෂ්‍යයක් නොව පරිපාලකගේ නිරීක්ෂිත ලිපිනය ඉලක්ක කරයි. එය එහිම ඉල්ලීම්-ප්‍රතිචාර යුගලයෙන් විනිශ්චය කරන්න, VPN ප්‍රතිපත්තිය වෙනස් කිරීමට පෙර අනුක්‍රමික කොන්සෝලය වැනි ස්වාධීන ප්‍රතිසාධන නාලිකාවක් තබා ගන්න. යෙදවුමක් VM නැවත ආරම්භ කර නියෝජිතයා අසුබ බව වාර්තා කරන්නේ නම්, මාර්ග වෙනස නැවත ආරම්භයට හේතු වියැයි උපකල්පනය කරනවාට වඩා වාර්තාගත ක්‍රියාව සහ වගකිවයුතු සේවාව පරීක්ෂා කරන්න.

පසුව ප්‍රවාහ තුන වෙන් වෙන් වශයෙන් සත්‍යාපනය කරන්න: ඔබට ඇත්තෙන්ම අවශ්‍ය වූ පෞද්ගලික සම්පත, සහාය දෙන නියෝජිත සහ වේදිකා සන්නිවේදනය, සහ පරිපාලන මාර්ගය. එකක් ප්‍රතිසාධනය කිරීම අනෙක් දෙක නොනැසී රැඳී ඇති බවට සාක්ෂියක් නොවේ.

අනුමත ව්‍යතිරේකය අමුත්තාගේ ජාලය සහ VPN වින්‍යාසය හිමිකරු යටතේ ලියන්න, නැවත සම්බන්ධ වීමේදී සහ නැවත ආරම්භයේදී කුමක් සිදු වේ ද යන්න ද ඇතුළත් කරන්න. Azure UDR යනු අමුත්තාගේ රූට් වගුව නොවන අතර, ඒවා සංස්කරණය කිරීම ස්ථානීය ප්‍රතිපත්ති නියමයක් අලුත්වැඩියා නොකරයි.