Azure P2S VPN හි ආපසු ගමන් ට්‍රැෆික් ක්‍රියා කරන්නේ එක් දිශාවකට පමණි

ටනල නිරූපකය කොළ පැහැයයි, NSG අවසර දෙන ලෙස පෙනේ, ඵලදායී මාර්ග නිවැරදි ලෙස පෙනේ, නමුත් VM හට සම්බන්ධිත සේවාදායකයා වෙත ආපසු සම්බන්ධතාවයක් විවෘත කළ නොහැක. සාමාන්‍ය උපකල්පනය වන්නේ ක්‍රියාකාරී point-to-site ටනලයක් සමමිතික බවයි: සේවාදායකයා VM වෙත ළඟා වුවහොත් VM ද සේවාදායකයා වෙත ළඟා වේ. එම උපකල්පනය වින්‍යාසයේ නොව තර්කයේ දෝෂයයි. ටනලයකට ඉල්ලා නොසිටි ප්‍රවාහයේ එක් දිශාවක් ගෙන ගොස් අනෙක ඉවත් කළ හැක, සහ නිවැරදි කිරීම එය ඉවත් කරන ස්තරය මත රඳා පවතී.

මිථ්‍යාව: සම්බන්ධිත ටනලයක් ද්වි-දිශා ටනලයකි

VPN ටනලයක් යනු ප්‍රතිපත්ති මාර්ගයකි, වයරයක් නොවේ. සෑම දිශාවක්ම තේරීම්කරුවන්, මාර්ග සහ පෙරහන් සමඟ ගැලපේ, සහ ඒවායින් ඕනෑම එකකට එක් දිශාවකට අවසර දී අනෙක අවහිර කළ හැක.

ප්‍රායෝගිකව අසමමිතිය ඉතා සාමාන්‍ය බැවින් දිශාව අවසන් පරීක්ෂණයේ නොව පළමු පරීක්ෂණයේ තිබිය යුතුය. සේවාදායකයා ආරම්භ කරයි, ගේට්වේ ප්‍රවාහය නිරීක්ෂණය කරයි, සහ පිළිතුර සාදන ලද තත්ත්වය අනුගමනය කරයි. නව ප්‍රවාහයක් ආරම්භ කරන VM හට එවැනි තත්ත්වයක් නොමැත, එබැවින් එය ආපසු මාර්ගය පැහැදිලිව මාර්ගගත කළ හැකි සහ අවසර ලත් වීම මත රඳා පවතී. එම මාර්ගය නොමැති විට, කිසිදු යෙදුමකට එය දැකීමට පෙර සම්බන්ධතා උත්සාහය මිය යයි.

ළඟාවිය හැකි බව පරීක්ෂා කිරීමට පෙර දිශාව පරීක්ෂා කරන්න

එක් සේවාදායක ලිපිනයක්, එක් VM ලිපිනයක් සහ එක් ප්‍රොටෝකෝලයක් තෝරන්න. සේවාදායකයාගෙන් සම්බන්ධ වී ප්‍රතිඵලය සටහන් කරන්න; පසුව එම පරීක්ෂණයම VM වෙතින් ආරම්භ කර එයද සටහන් කරන්න. පළමු එක සාර්ථක වී දෙවැන්න අසාර්ථක වුවහොත්, සේවාදායක තටාකය, ගේට්වේ සම්බන්ධය සහ සේවාදායකයාගේ සිට VNet දක්වා මාර්ගය යන සියල්ලම ක්‍රියා කරයි.

ඊළඟ පියවර සාක්ෂි වේ, තවත් නීති නොවේ. VM උපජාලයේ NSG දෙපැත්තෙන්ම පරීක්ෂා කරන්න, VM හි NIC හි ඵලදායී මාර්ග කියවන්න, සහ සේවාදායකයා ට්‍රැෆික් යවන අතරතුර VM මත පැකට් ග්‍රහණය කරන්න. පිළිතුරක් නොමැතිව පැමිණෙන ඉල්ලීමක් පෙරහන් හෝ ආපසු මාර්ග ගැටලුවකි; කිසිදා නොපැමිණෙන ඉල්ලීමක් මාර්ග ගැටලුවකි. අසාර්ථක ping එකක් VM වෙත ළඟා විය නොහැකි බවට සාක්ෂියක් ලෙස නොසලකන්න, මන්ද TCP ක්‍රියා කරන අතරතුර ICMP ප්‍රතිපත්තියට පිළිතුර ඉවත් කළ හැක.

IKEv2 point-to-site ආපසු මාර්ගය සාමාන්‍ය සැකකරුය

මෙම ලිපියට පාදක වූ Azure වාර්තාවේ, සේවාදායකයාට IKEv2 හරහා VM වෙත ළඟා විය හැකි වූ නමුත්, ගේට්වේයේ ටනල් වර්ගය OpenVPN වෙත මාරු කරන තෙක් VM සිට සේවාදායකයා දක්වා එන ICMP අසාර්ථක විය. වාර්තාකරු පවසන්නේ IKEv2 point-to-site මාර්ගයේ සීමාවක් Microsoft තහවුරු කළ බවයි: සේවාදායකයා සැසිය ආරම්භ නොකළහොත් VM සිට සේවාදායකයා දක්වා ආපසු ට්‍රැෆික් සමමිතිකව මාර්ගගත නොවේ. IKEv2 ට්‍රැෆික් තේරීම්කරුවන් මත රඳා පවතී, සහ එම අවස්ථාවේදී ගේට්වේ ආපසු දිශාවට ගරු නොකළේය.

එය OpenVPN සාමාන්‍යයෙන් වඩා හොඳ ටනල් වර්ගයක් බවට පත් නොකරයි. එය මෙම කාර්ය භාරය සඳහා පරීක්ෂණ න්‍යාසයේ ටනල් වර්ගය විචල්‍යයක් බවට පත් කරයි.

ටනල් වර්ගය මාරු කිරීම සේවා වෙනසකි, ස්විචයක් නොවේ. සෑම සේවාදායකයකටම ගැළපෙන පැතිකඩක් අවශ්‍ය වන අතර, ගේට්වේයට වෙනත් සහතිකයක් හෝ සත්‍යාපන සැකසුමක් අවශ්‍ය විය හැක. එක් පරීක්ෂණ සේවාදායකයක් සහ එක් පරීක්ෂණ VM එකක් සමඟ ඒක දිශා හැසිරීම නැවත නිපදවන්න, අනුමත කාලසටහනකට අනුව වර්ගය වෙනස් කරන්න, පසුව එම දිශා පරීක්ෂණ නැවත කරන්න. වෙනසෙන් පසුවත් හැසිරීම රැඳී තිබේ නම්, ටනල් වර්ගය හේතුව නොවීය, සහ නිෂ්පාදනය ස්පර්ශ නොකර ගැටලුව පටු කළා.

මිථ්‍යාව: broadcast සොයාගැනීම VNet මායිම හරහා යයි

දෙවන උපකල්පනය සම්බන්ධ නොවන හේතුවකින් අසාර්ථක වේ. Azure අතථ්‍ය ජාලය broadcast ට්‍රැෆික් රැගෙන නොයන බැවින්, VM එකකට site-to-site හෝ point-to-site සම්බන්ධතාවයක් හරහා ඔන්-ප්‍රෙමයිස් ජාලයකින් broadcast රාමු ලබා ගත නොහැක. broadcast මගින් සහකරුවන් සොයා ගන්නා යෙදුම්, උදාහරණයක් ලෙස පැරණි ගොනු බ්‍රවුස් කිරීම හෝ සමහර උපාංග-සොයාගැනීමේ ප්‍රොටෝකෝල, මාර්ග කෙසේ ලියා තිබුණත් දුර පැත්ත කිසිදා නොදකිනු ඇත.

broadcast සොයාගැනීම DNS නාම, නාමාවලි සේවාවක් හෝ පැහැදිලි සහකරු ලැයිස්තුවක් සමඟ ප්‍රතිස්ථාපනය කරන්න. යෙදුමට unicast විකල්පයක් නොමැති නම්, නිර්මාණයට පුළුල් ටනලයක් නොව වෙනත් සොයාගැනීමේ යාන්ත්‍රණයක් අවශ්‍ය වේ.

කුමක් වෙනස් කළ යුතුද, එය ඔප්පු කරන්නේ කෙසේද

දිශා පරීක්ෂණය IKEv2 මත පමණක් අසාර්ථක වුවහොත්, ගේට්වේයේ ටනල් වර්ගය, සේවාදායක ලිපින තටාකය සහ නිශ්චිත ICMP හෝ TCP පරීක්ෂණය සටහන් කර, පසුව බලපෑමට ලක් වූ සේවාදායකයින් සඳහා අනුමත OpenVPN පැතිකඩක් ඇගයීමට ලක් කරන්න. සෑම ටනල් වර්ගයකම අසාර්ථක වුවහොත්, ආපසු මාර්ගය සමඟ වැඩ කරන්න: සේවාදායක ලිපිනය VM උපජාලයෙන් මාර්ගගත කළ හැකි විය යුතුය, පරිශීලක-නිර්වචිත ඕනෑම මාර්ගයක් වලංගු ඊළඟ හොප් වෙත යොමු විය යුතුය, සහ සේවාදායකයාගේ ෆයර්වෝලය එන ප්‍රවාහය පිළිගත යුතුය. NSG සහ මාර්ග සාක්ෂි ටිකට්ටුවට අමුණන්න.

ping සමඟ නොව යෙදුම සමඟ තහවුරු කරන්න. වෙනසකට පසු සාර්ථක ICMP හුවමාරුවක් සේවා වරාය, එහි සත්‍යාපනය හෝ නාම විභේදනය ගැන කිසිවක් නොකියයි. නැවත සම්බන්ධ වූ පසු පරීක්ෂණය නැවත කරන්න, මන්ද තටාකයෙන් වෙනත් ලිපිනයක් ලබන සේවාදායකයාට ප්‍රතිඵලය වෙනස් කළ හැක. පසුව සේවාදායකයා නිදා අවදි වූ පසු තවත් වරක් නැවත කරන්න, මන්ද නැවත ආරම්භ වූ සැසියේදී ඒක දිශා හැසිරීම බොහෝ විට නැවත දිස්වේ.