AWS Transit Gateway-ൽ ഒന്നിലധികം VPC-കൾക്കായി ഒരു സൈറ്റ്-ടു-സൈറ്റ് VPN
VPN ഒരിക്കൽ മാത്രം ബന്ധിപ്പിച്ച് ഓരോ VPC-യും ഒരു ട്രാൻസിറ്റ് ഗേറ്റ്വേയിലേക്ക് ചേർത്ത്, അസോസിയേഷനെ പ്രോപഗേഷനിൽ നിന്ന് വേർതിരിക്കുക, അപ്പോൾ സ്പോക്കുകൾ ഓഫീസിലെത്തും പക്ഷേ പരസ്പരം എത്തില്ല.
ഈ പാദത്തിൽ രണ്ട് VPC-കൾക്ക് ഓഫീസ് നെറ്റ്വർക്ക് ആവശ്യമുണ്ട്, രണ്ടാമത്തെ ടണലിലാണ് കണക്ക് തകരുന്നത്. AWS Transit Gateway-ക്ക് പങ്കിട്ട റൂട്ടിംഗ് ഹബ്ബായി പ്രവർത്തിക്കാം: VPN ഒരിക്കൽ ബന്ധിപ്പിക്കുന്നു, ഓരോ VPC-യും അതേ ഹബ്ബിലേക്ക് ബന്ധിപ്പിക്കുന്നു. തുടർന്ന് ഓൺ-പ്രെമൈസസ് നെറ്റ്വർക്ക് ഒരൊറ്റ കണക്ഷനിലൂടെ ബന്ധിപ്പിച്ച എല്ലാ VPC-കളിലേക്കും എത്തുന്നു. ഇത് റൂട്ടിംഗ് തീരുമാനം ആർക്കാണ് എന്നത് മാറ്റുന്നു, മിക്ക ഡിസൈനുകളും തെറ്റ് ചെയ്യുന്നത് ഇവിടെയാണ്.
VPN അറ്റാച്ച്മെന്റും VPC അറ്റാച്ച്മെന്റുകളും ഒരേ ഗേറ്റ്വേയിലെ വേറിട്ട ഒബ്ജക്റ്റുകളാണ്, അതിനാൽ റൂട്ടിംഗ് ബന്ധങ്ങൾ പിന്നീട് നിർമ്മിക്കണം.
On-premises network <-> Site-to-Site VPN <-> Transit Gateway
|- VPC A
|- VPC B
ആളുകൾ പ്രതീക്ഷിക്കുന്ന ചെറുകുത്തുവഴി പിയറിംഗ് എന്തുകൊണ്ട് അല്ല
പ്രലോഭനീയമായ ബദൽ, VPN VPC A-യിൽ അവസാനിപ്പിച്ച് VPC B-യെ അതിലേക്ക് പിയർ ചെയ്യുക എന്നതാണ്. സാധാരണ VPC പിയറിംഗ് A-യുടെ VPN കണക്ഷനിലൂടെ അറ്റം മുതൽ അറ്റം വരെ ട്രാൻസിറ്റ് നൽകുന്നില്ല. പിയർ, പിയറിംഗ് തന്നെ നൽകുന്ന വിലാസങ്ങളിൽ മാത്രം എത്തുന്നു, VPN അറ്റം അവയിലൊന്നല്ല. ട്രാൻസിറ്റ് ഹബ്ബ് നൽകുന്നു; പിയറിംഗ് നിങ്ങൾക്ക് ഒരു ജോഡി നൽകുന്നു.
ആ പരിമിതി പിയറിംഗിന്റെ സ്വഭാവമാണ്, ഉയർത്താവുന്ന ക്വോട്ട അല്ല.
അസോസിയേഷനും പ്രോപഗേഷനും വ്യത്യസ്ത ജോലി ചെയ്യുന്നു
ട്രാൻസിറ്റ് ഗേറ്റ്വേയ്ക്കുള്ളിൽ, അറ്റാച്ച്മെന്റിൽ നിന്ന് വരുന്ന ട്രാഫിക് തിരയാൻ ഉപയോഗിക്കുന്ന റൂട്ട് ടേബിൾ അസോസിയേഷൻ തിരഞ്ഞെടുക്കുന്നു. ഒരു അറ്റാച്ച്മെന്റിന്റെ പഠിച്ചതോ ബന്ധിപ്പിച്ചതോ ആയ പ്രിഫിക്സുകൾ ഏതൊക്കെ ടേബിളുകൾക്ക് ലഭിക്കും എന്ന് പ്രോപഗേഷൻ തീരുമാനിക്കുന്നു. ഒരു അറ്റാച്ച്മെന്റിനെ ഒരു ടേബിളുമായി അസോസിയേറ്റ് ചെയ്യുമ്പോൾ തന്നെ പലതിലേക്ക് പ്രോപഗേറ്റ് ചെയ്യാം. രണ്ടിനെയും കൂട്ടിക്കലർത്തുന്നതാണ്, ആരും ആസൂത്രണം ചെയ്യാത്ത എത്തിച്ചേരലിലേക്ക് ഡിസൈൻ എത്തുന്ന വഴി.
പൂർണ്ണമായി ബന്ധിപ്പിച്ച ചെറിയ ഹബ്ബ് എളുപ്പമുള്ള കേസാണ്.
ഓരോ അറ്റാച്ച്മെന്റും ഒരൊറ്റ ടേബിളിൽ ഇടുക, VPN-ഉം രണ്ട് VPC പ്രിഫിക്സുകളും വ്യക്തമായി പരിഹരിക്കപ്പെടുന്നു. സംഘടന ഒരിക്കലും ഉദ്ദേശിക്കാത്ത VPC-കൾക്കിടയിലുള്ള എത്തിച്ചേരലും ഇത് അനുവദിക്കുന്നു, കാരണം പങ്കിട്ട ടേബിളിന് സ്പോക്ക് എന്ന ആശയമില്ല.
വർക്ക്ലോഡ് റൂട്ടുകൾ മറ്റൊരിടത്ത് താമസിക്കുന്നു
ഓരോ വർക്ക്ലോഡ് സബ്നെറ്റിനും ഉദ്ദേശിച്ച ലോക്കൽ പ്രിഫിക്സുകൾക്കായി ട്രാൻസിറ്റ് ഗേറ്റ്വേയിലേക്കുള്ള സ്വന്തം റൂട്ട് ഇപ്പോഴും ആവശ്യമാണ്. ആ VPC റൂട്ട് ടേബിളുകൾ ഗേറ്റ്വേയുടെ സ്വന്തം ടേബിളുകളിൽ നിന്ന് വേറിട്ട ഒബ്ജക്റ്റുകളാണ്. ആവശ്യമായ പ്രിഫിക്സുകൾ ചേർക്കുക, ഓരോ ലക്ഷ്യസ്ഥാനവും പുതിയ ഡിഫോൾട്ട് കൊണ്ട് മാറ്റുന്നതിന് പകരം നിലവിലുള്ള റൂട്ടുകൾ നിലനിർത്തുക. സബ്നെറ്റ് റൂട്ട് ഉപഭോക്തൃ ഉപകരണത്തിന് ഒന്നും പ്രഖ്യാപിക്കുന്നുമില്ല.
ഡൈനാമിക് അല്ലെങ്കിൽ സ്റ്റാറ്റിക് റൂട്ടിംഗ് ബോധപൂർവ്വം തിരഞ്ഞെടുക്കുക; പിയറിംഗ് ഒന്നും നൽകുന്നില്ല.
ലോക്കൽ ആക്സസ് നഷ്ടപ്പെടുത്താതെ സ്പോക്കുകളെ വേർതിരിക്കുക
A-യ്ക്കും B-യ്ക്കും ഓഫീസിലേക്ക് എത്താമെങ്കിലും പരസ്പരം റൂട്ട് ചെയ്യാൻ പാടില്ലെങ്കിൽ, ടേബിളുകൾ വിഭജിക്കുക. VPN അറ്റാച്ച്മെന്റിന്റെ അസോസിയേറ്റഡ് ടേബിളിൽ VPC പ്രിഫിക്സുകൾ ഉണ്ട്. VPC അറ്റാച്ച്മെന്റുകളുടെ അസോസിയേറ്റഡ് ടേബിളിൽ ലോക്കൽ പ്രിഫിക്സുകൾ ഉണ്ട്, A-യെ B-യുമായി ബന്ധിപ്പിക്കുന്ന റൂട്ടില്ലാതെ. ആ ബന്ധം സൃഷ്ടിക്കുന്നത് പ്രോപഗേഷനാണ്, അതിനാൽ എല്ലാ ഡിഫോൾട്ട് അസോസിയേഷനുകളും സ്വീകരിക്കേണ്ടതില്ല.
ഇത് റൂട്ടിംഗ് വേർതിരിക്കലാണ്, ഇത് ആപ്ലിക്കേഷൻ അനുമതിയല്ല.
സെക്യൂരിറ്റി ഗ്രൂപ്പുകൾ, നെറ്റ്വർക്ക് ACL-കൾ, ഹോസ്റ്റ് ഫയർവാളുകൾ, ഓരോ സേവനത്തിന്റെയും സ്വന്തം അനുമതികൾ എന്നിവ ഏത് ട്രാഫിക് സ്വീകരിക്കാമെന്ന് ഇപ്പോഴും തീരുമാനിക്കുന്നു. പരിശോധന ആവശ്യമെങ്കിൽ, ഹബ്ബ് അത് ചെയ്യുമെന്ന് കരുതുന്നതിന് പകരം അതിന്റെ പിന്തുണയുള്ള പാത വ്യക്തമായി രൂപകൽപ്പന ചെയ്യുക.
ഹബ്ബ് ശരിയാക്കാത്തത്
വിലാസ പ്ലാനുകൾ ഇപ്പോഴും ഒരുമിച്ചുകിടക്കരുത്, കാരണം ഒരു പ്രിഫിക്സ് രണ്ട് വർക്ക്ലോഡുകളെ തിരിച്ചറിയാൻ ഹബ്ബ് അനുവദിക്കുന്നില്ല. ഓരോ VPC അറ്റാച്ച്മെന്റിനും അതിന്റെ വർക്ക്ലോഡുകൾ പ്രതീക്ഷിക്കുന്ന Availability Zone പരിധി ആവശ്യമാണ്. BGP-യിൽ, ഉപഭോക്തൃ ഉപകരണത്തിന്റെ ഓരോ ആവശ്യമായ പ്രിഫിക്സിലേക്കുമുള്ള തിരിച്ചുള്ള റൂട്ടുകൾ ഡിസൈനുമായും അതിന്റെ ഇംപോർട്ട് നയവുമായും പൊരുത്തപ്പെടണം. നഷ്ടമായ പ്രഖ്യാപനം കൃത്യം പൊട്ടിയ ടണൽപോലെ തോന്നുന്നു.
VPN കണക്ഷനും ട്രാൻസിറ്റ് ഗേറ്റ്വേയും ഇപ്പോൾ പങ്കിട്ട അടിസ്ഥാന സൗകര്യമാണ്.
ടണലുകളുടെ പുനരാവൃത്തി, ഉപകരണ ശേഷി, നിരീക്ഷണം, പരിപാലനം എന്നിവ ആശ്രിതമായ എല്ലാ VPC-കൾക്കും ചുറ്റും ആസൂത്രണം ചെയ്യുക, ഓരോന്നിനെയും സ്വതന്ത്രമായി ബന്ധിപ്പിച്ചതായി കണക്കാക്കുന്നതിന് പകരം.
നിലവിലുള്ള virtual private gateway ക്രമീകരണത്തിൽ നിന്നുള്ള മാറ്റത്തിനും അതേ വ്യക്തമായ പ്ലാൻ അർഹതയുണ്ട്. അറ്റാച്ച്മെന്റുകളും നയങ്ങളും നിർമ്മിക്കുക, നിയന്ത്രിതമായ ഒരു വർക്ക്ലോഡ് പാത മാറ്റുക, പഴയ പാത ഒഴിവാക്കുന്നതിന് മുമ്പ് അനുവദിക്കപ്പെട്ടതും നിരസിക്കപ്പെട്ടതുമായ ബന്ധങ്ങൾ സ്ഥിരീകരിക്കുക. കേന്ദ്രീകരണം നെറ്റ്വർക്ക് ടീമിന് പങ്കിട്ട കണക്തത കൈകാര്യം ചെയ്യാൻ ഒരിടം നൽകുമ്പോൾ സഹായിക്കുന്നു, ഒരു വലിയ ടേബിളിന് പിന്നിൽ ആരെങ്കിൽ ആരെത്താമെന്ന് മറച്ചുവയ്ക്കുമ്പോൾ ഹാനികരമാകുന്നു.