AWS Site-to-Site VPN සිට NAT Gateway දක්වා: VGW vs Transit Gateway

පළමු වරට සියලු දෙනා එකම රූප සටහන අඳිති: VPC වෙත VPN, පසුව NAT gateway හරහා අන්තර්ජාලයට, අවසන්. නමුත් VPN virtual private gateway එකක් මත අවසන් වන විට AWS එම මාර්ගය අනුග්‍රහය නොදක්වයි, සහ අසාර්ථකත්වය කෙතරම් නිහඬ ද යත් කණ්ඩායම් එය එක් වරකට වඩා නැවත ගොඩනඟති. ක්‍රියා කරන නිර්මාණයට transit gateway අවශ්‍ය වන අතර එය දෙපසම gateway සහ route tables වෙනස් කරයි. යමක් ඇඳීමට පෙර ආකාර දෙක සසඳන්න.

පැහැදිලි ලෙස පෙනෙන නමුත් අනුග්‍රහය නොලබන ටොපොලොජිය

AWS හි NAT gateway ලේඛනය එක් VPC නිර්මාණ පමණක් ගොඩනැගූ සැමට පුදුමයට පත් කරන රේඛාවක් අඳියි: Site-to-Site VPN සම්බන්ධතාවයේ ට්‍රැෆික් virtual private gateway හරහා NAT gateway වෙත route කළ නොහැක. VPN අවසන් වන gateway වර්ගය මගින් පරිවර්තන මාර්ගයක් තිබේද යන්න තීරණය වේ. දෝෂය රැඳී තිබෙන්නේ ටනල් තත්ත්වය UP වීම සහ එම subnet හි EC2 instance එකක් ගැටලුවකින් තොරව අන්තර්ජාලයට ළඟා වීම නිසාය. එම නිරීක්ෂණ දෙකෙන් කිසිවක් කැඩුණු දිශාව පරීක්ෂා නොකරයි.

ප්‍රායෝගිකව පැකට්ටුව ප්‍රාදේශීය ජාලයේ මූලාශ්‍ර ලිපිනය සමඟ පැමිණ එය පරිවර්තනය කරන අනුග්‍රහය ලත් ඊළඟ hop එකක් සොයාගන්නේ නැත. වගු අනුව එය egress මායිමේදී ඉවතට දමනු ලැබේ, ටනලය UP ලෙස පවතින අතර එම subnet හි instance එකක් අන්තර්ජාලයට ළඟා වන බැවින් අසාර්ථකත්වය ප්‍රාදේශීය firewall ගැටලුවක් ලෙස වාර්තා වේ.

Virtual private gateway vs transit gateway

එක් virtual private gateway එකක් එක් VPC එකකට අයත් වේ. එය VPN අවසන් කරයි, එම VPC හි route tables වෙත routes ස්ථාපනය කරයි, එහි නතර වේ. එයට attachment ආකෘතියක් නැති බැවින් වෙනත් VPC එකකට හෝ හවුල් egress කොටසකට ට්‍රැෆික් භාර දිය නොහැක. මෙම තනි VPC පරාසය මුළු සීමාවයි, VPC තුළ එකතු කරන කිසිම route එකක් එය වෙනස් නොකරයි.

Transit gateway යනු කලාපීය කේන්ද්‍රස්ථානයකි; එහි VPN, සෑම spoke VPC සහ හවුල් සේවා VPC සියල්ලම attachments ලෙස දිස්වේ. එයට තමන්ගේම route tables ඇති අතර, දී ඇති prefix එකක් ලබා ගන්නේ කුමන attachment එකද යන්න ඒවා තෝරයි.

මෙම කේන්ද්‍රස්ථානය නිසාම කේන්ද්‍රීකෘත egress හැකි වේ: VPN එක් attachment එකක් ලෙස ගොඩබසියි, egress VPC තවත් එකක් ලෙස, සහ transit gateway route table අන්තර්ජාලය දෙසට වන prefixes පළමුවැන්නෙන් දෙවැන්නට යවයි. virtual private gateway සමඟ යැවීමට දෙවන attachment එකක් නොමැති බැවින් නිර්මාණය පසුව පැච් කර ගොඩනැගිය නොහැක.

අනුග්‍රහය ලත් egress මාර්ගය, පියවරෙන් පියවර

යොමු නිර්මාණයේ hops පහක් ඇති අතර සෑම ඊතලයක්ම ඔබ වින්‍යාස කළ යුතු route තීරණයකි. ට්‍රැෆික් ප්‍රාදේශීය ජාලයෙන් Site-to-Site VPN attachment වෙත යයි, transit gateway route table එය egress VPC attachment වෙත යවයි, එහිදී subnet වගුව එය පොදු NAT gateway වෙත යවයි. NAT gateway මූලාශ්‍රය පරිවර්තනය කරයි, internet gateway පැකට්ටුව පිටතට ගෙන යයි.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

අවසන් hops ක්‍රියා කරනවාද යන්න කරුණු දෙකක් තීරණය කරයි. NAT gateway පොදු විය යුතුය, elastic IP සහ internet gateway වෙත route සමඟ, මන්ද පෞද්ගලික NAT gateway ජාල අතර පරිවර්තනය කරන අතර කිසිදා අන්තර්ජාල පිටවීමක් නොවේ.

ඔබ සේවා දෙන සෑම Availability Zone එකකටම එක් NAT gateway එකක් සැලසුම් කරන්න, සෑම subnet වගුවක්ම ප්‍රාදේශීය එක දෙසට යොමු විය යුතුය. ඔබේ සටහන්වල transit gateway වගුව සහ VPC වගු වෙන් වෙන් වස්තු ලෙස තබා ගන්න, මන්ද එකක් attachment එකක්ද අනෙක VPC තුළ සම්පතක්ද තෝරයි. එකක් තුළ පමණක් default route තිබේ නම් මාර්ගයෙන් අඩක් නිර්වචනය නොවී රැඳී, හඳුනා ගැනීමට අතිශය අපහසු අර්ධ අසාර්ථකතා ඇති වේ.

මෙම නිර්මාණ අසාර්ථක වන්නේ ආපසු මාර්ගයේදීය

NAT gateway දැනටමත් දුටු flows සඳහා stateful වේ, එබැවින් පිටතට යන සම්බන්ධතාවයක පිළිතුරු නව inbound නියමයක් නොමැතිව ආපසු එයි. එම ගුණාංගය ප්‍රාදේශීය සේවාවක් අන්තර්ජාලයට ප්‍රකාශයට පත් නොකරයි, එසේ යැයි සලකන විට කණ්ඩායමක් කිසිදා ස්ථාපිත නොවන සම්බන්ධතාවයක් ඩීබග් කිරීමට දිනක් ගත කරයි. සේවාදායකයාගෙන් ආරම්භ වන ට්‍රැෆික් සඳහා routes හතරක් එකඟ විය යුතුය: ප්‍රාදේශීය ප්‍රතිපත්තිය, transit gateway වගුව, egress subnet වගුව සහ NAT subnet වගුව. අවසන් එක මග හැරුණොත් ඉල්ලීම ගොඩනැගිල්ලෙන් පිටවන අතර පිළිතුර AWS තුළම මිය යයි.

VPN පිටුපස සැබෑ සේවාදායකයෙකු සමඟ තහවුරු කර එය ඉදිරිපත් කරන පොදු මූලාශ්‍ර ලිපිනය බලන්න. එය NAT gateway හි elastic IP නම් පරිවර්තනය සිදු වෙමින් පවතී; වෙනත් යමක් නම් ඔබ වෙනත් egress එකක් මනිමින් සිටී.

මෙම අසාර්ථකත්වයේ අසමමිතික ස්වරූපය ඉක්මනින් හඳුනා ගැනීම වටී. එක් Availability Zone එකක NAT subnet වගුවේ සේවාදායක prefix වෙත ආපසු route එකක් ඇති අතර තවත් එකක නැති විට, නව සම්බන්ධතා flow එක වැටෙන කලාපය අනුව සාර්ථක හෝ අසාර්ථක වේ, සහ මෙම රටාව වැරදි ලෙස අස්ථිර අන්තර්ජාලයක් ලෙස කියවනු ලැබේ. ටිකට් එක විවෘත වූ කලාපය නිවැරදි කිරීම වෙනුවට ඔබ සේවා දෙන සෑම කලාපයකම subnet වගු සසඳන්න, මන්ද නැති route එකම මුළු දෝෂය වන අතර අනෙක් පස කිසිවක් වෙනස් කිරීමට අවශ්‍ය නැත.

කවදාද පැහැදිලි proxy වඩා හොඳ නිර්මාණය වන්නේ

egress VPC හි instance එකක HTTP proxy යනු වලංගු විකල්පයක් වන අතර බොහෝ විට ලාභදායී වේ. සේවාදායක proxy භාවිතා කිරීමට වින්‍යාස කරනු ලැබේ, proxy තමන්ගේම සම්බන්ධතාවය පිටතට විවෘත කරයි, සහ ආපසු මාර්ගය සමමිතික routing ප්‍රහේලිකාවක් නොව proxy හි ගැටලුවක් බවට පත් වේ. ටිකක් යෙදුම් සඳහා මෙය transit gateway කාර්යයේ වැඩි කොටසක් ඉවත් කරයි. NAT gateway නිපදවිය නොහැකි පරිශීලක-මට්ටමේ ලොග්කිරීමද එය ලබා දෙයි.

කෙසේ වෙතත් එය විනිවිද පෙනෙන එකක් නොවේ. proxy සැකසීම් නොසලකා හරින ඕනෑම දෙයක් සහ HTTP නොවන සෑම ප්‍රොටෝකෝලයක්ම එම මාර්ගය අනුගමනය නොකරයි.

තේරීම රඳා පවතින්නේ ඔබේ යෙදුම් ඇත්තටම කතා කරන්නේ කුමක්ද සහ ලොග්වල කොපමණ අනන්‍යතාවයක් අවශ්‍යද යන්න මතය. ඒවා HTTP කතා කරන තැන proxy එහි ස්ථානය දිනා ගනී; අත්තනෝමතික ප්‍රොටෝකෝල සඳහා සාමාන්‍ය egress අවශ්‍ය තැන AWS අනුග්‍රහය දෙන නිර්මාණය transit gateway වේ. මෙය කල්තියා තීරණය කිරීම route tables ගොඩනැගීමෙන් පසු සොයා ගැනීමට වඩා ලාභදායීය.