EC2 ലഭ്യതാ മേഖലകളിലുടനീളം: VPN-ന് മുമ്പ് റൂട്ടിംഗ് പരിശോധിക്കുക

രണ്ട് EC2 ഇൻസ്റ്റൻസുകൾക്കിടയിൽ VPN സോഫ്റ്റ്വെയർ ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് മുമ്പ് ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുക: അവ ഒരേ VPC-യിലാണോ? അങ്ങനെയെങ്കിൽ, സ്വകാര്യ പാത ഇതിനകം നിലവിലുണ്ട്, മേഖലകൾക്കിടയിലുള്ള സ്ഥാപനം അത് മാറ്റുന്നില്ല. ഈ സാഹചര്യത്തിലെ ജോലിയുടെ ഭൂരിഭാഗവും ഓരോ സബ്നെറ്റും യഥാർത്ഥത്തിൽ ഏത് റൂട്ട് പട്ടിക ഉപയോഗിക്കുന്നു എന്ന് സ്ഥിരീകരിക്കുന്നതും, തുടർന്ന് പരാജയം റൂട്ടിംഗ് പ്രശ്നമായിരുന്നോ എന്ന് കണ്ടെത്തുന്നതുമാണ്. ഈ നിർദ്ദിഷ്ട ചോദ്യത്തിന് ടണൽ സാധാരണയായി തെറ്റായ ഉത്തരമാണ്.

പരിശോധന 1: ഒരേ VPC അതോ വ്യത്യസ്ത VPC-കളോ

VPC പ്രാദേശികമാണ്, ലഭ്യതാ മേഖലകളിലുടനീളം വ്യാപിക്കുന്നു, അതേസമയം ഓരോ സബ്നെറ്റും കൃത്യമായി ഒരു മേഖലയിൽ മാത്രം ഉൾപ്പെടുന്നു. ഒരേ VPC-യുടെ വ്യത്യസ്ത മേഖലകളിലുള്ള രണ്ട് ഇൻസ്റ്റൻസുകളും ഇപ്പോഴും അതേ സ്വകാര്യ റൂട്ടിംഗ് ഡൊമെയ്നിനുള്ളിലാണ്.

വ്യത്യസ്ത VPC-കൾക്ക് ഒരു പ്രദേശമോ മേഖല ലേബലോ പങ്കിടുന്നതിന്റെ പേരിൽ മാത്രം സ്വകാര്യ റൂട്ട് ഒരിക്കലും ലഭിക്കുന്നില്ല. ആ സാഹചര്യത്തിന് പിന്തുണയുള്ള കണക്ഷനും സ്വന്തം റൂട്ട്, അനുമതി ജോലിയും ആവശ്യമാണ്, അത് വേറിട്ട തീരുമാനമാണ്.

പരിശോധന 2: സബ്നെറ്റ് റൂട്ട് പട്ടികകൾ എന്ത് പറയുന്നു

യഥാർത്ഥ മൂല്യങ്ങളോടെ രൂപരേഖ എഴുതുക. VPC 10.60.0.0/16 എന്ന വിലാസത്തിൽ, സബ്നെറ്റുകൾ 10.60.1.0/24 ഉം 10.60.2.0/24 ഉം ഉള്ളപ്പോൾ, ഇൻസ്റ്റൻസുകൾക്ക് 10.60.1.10 ഉം 10.60.2.20 ഉം VPC-യുടെ ലോക്കൽ റൂട്ടിലൂടെ ഒരു പാത നൽകുന്നു.

തുടർന്ന് ആദ്യം കണ്ട പട്ടിക മാത്രമല്ല, രണ്ട് സബ്നെറ്റുകളുമായി ബന്ധപ്പെട്ട പട്ടികകൾ പരിശോധിക്കുക. കൂടുതൽ നിർദ്ദിഷ്ടമായ പരിശോധനയോ ഉപകരണ റൂട്ടോ അടിസ്ഥാന റൂട്ടിനെ മറികടക്കാം, ലോക്കൽ റൂട്ടിന്റെ ലക്ഷ്യം തന്നെ പുതിയ കോൺഫിഗറേഷനുകളിൽ മാറ്റപ്പെടാം. കൺസോളിൽ എവിടെയോ കാണുന്ന ലോക്കൽ റൂട്ട് രണ്ട് വർക്ക്ലോഡുകളും അത് ഉപയോഗിക്കുന്നു എന്ന് തെളിയിക്കുന്നില്ല.

VPC യഥാർത്ഥത്തിൽ നൽകുന്ന സ്വകാര്യ വിലാസങ്ങളും പേരുകളും ഉപയോഗിക്കുക. സ്വകാര്യ വിലാസം 10-ൽ തുടങ്ങണമെന്നില്ല, ഓർമ്മയിൽ നിന്ന് ഒന്ന് കെട്ടിച്ചമയ്ക്കുന്നതാണ് പ്രവർത്തിക്കുന്ന ഒരു പരിസ്ഥിതിയെ തെറ്റായി രോഗനിർണയം ചെയ്യുന്ന വഴി.

പരിശോധന 3: റൂട്ടിംഗോ അധികാരപ്പെടുത്തലോ

റൂട്ടിംഗ് പാക്കറ്റിനെ ലക്ഷ്യത്തിന്റെ നെറ്റ്വർക്ക് ഇന്റർഫേസ് വരെ മാത്രം എത്തിക്കുന്നു. ലക്ഷ്യത്തിന്റെ സെക്യൂരിറ്റി ഗ്രൂപ്പ് ഇപ്പോഴും ഉറവിടത്തെയും സേവനത്തെയും അനുവദിക്കണം, ഉറവിടത്തിന്റെ ഔട്ട്ഗോയിംഗ് നിയമങ്ങൾ അഭ്യർത്ഥന അനുവദിക്കണം, കൂടാതെ ഏത് നെറ്റ്വർക്ക് ACL-ഉം ഇരു ദിശകളും അനുവദിക്കണം, കാരണം ACL-കൾ അവസ്ഥ സൂക്ഷിക്കുന്നില്ല.

അതിനപ്പുറം ഗസ്റ്റ് ഫയർവാൾ, ലിസണറുടെ ബൈൻഡിംഗ്, ആപ്ലിക്കേഷന്റെ സ്വന്തം ഐഡന്റിറ്റി എന്നിവയുണ്ട്. ഇവയിൽ ഏതിനും റൂട്ടിംഗ് കൃത്യമായി എത്തിച്ച അഭ്യർത്ഥന നിരസിക്കാം.

സ്വീകരണം യഥാർത്ഥ ആപ്ലിക്കേഷൻ പ്രവർത്തനമായിരിക്കണം. വിജയകരമായ ping ആപ്ലിക്കേഷൻ ആക്സസ് നൽകുന്നില്ല, TLS നാമവും ക്രെഡൻഷ്യലുകളും ശരിയാണെന്ന് തെളിയിക്കുന്നുമില്ല, തടഞ്ഞ ping എല്ലാ സ്വകാര്യ സേവനങ്ങളും നിലച്ചു എന്ന് സ്ഥാപിക്കുന്നുമില്ല.

പരിശോധന 4: പ്രത്യേക കണക്ഷൻ യഥാർത്ഥത്തിൽ ആവശ്യമാണോ

VPN ഇപ്പോഴും രൂപകൽപ്പനയിൽ ഉണ്ടാകാം, പക്ഷേ പറഞ്ഞ കാരണത്താൽ: ഈ VPC ഓഫീസുമായി ബന്ധിപ്പിക്കുന്നതിനോ, ലാപ്ടോപ്പുകൾ അനുവദിക്കുന്നതിനോ, ഓവർലേ ആവശ്യകത നിറവേറ്റുന്നതിനോ. ആ കാരണം ഒരേ VPC-യ്ക്കുള്ളിലെ സാധാരണ ആശയവിനിമയത്തിൽ നിന്ന് വ്യത്യസ്തമാണ്.

VPC എന്തല്ല എന്നതും ഓർക്കുക. ഇത് വീട്ടിലെ ഈതർനെറ്റ് സെഗ്മെന്റിന്റെ വിപുലീകരണമല്ല. ബ്രോഡ്കാസ്റ്റ് കണ്ടെത്തലിനെ ആശ്രയിക്കുന്ന ആപ്ലിക്കേഷന് വിലയിരുത്താൻ പ്രത്യേക ആവശ്യകതയുണ്ട്. അത് റൂട്ടിംഗ് ബഗ്ഗല്ല, രൂപകൽപ്പനയിലെ വിടവാണ്.

പരിശോധന 5: എൻക്രിപ്ഷൻ ചോദ്യം

സ്വകാര്യ വിലാസവും അനുമതി നിയമവും ആപ്ലിക്കേഷൻ പാളിയിലെ ക്രിപ്റ്റോഗ്രാഫിക് സംരക്ഷണത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഡാറ്റയ്ക്ക് അറ്റത്തുനിന്ന് അറ്റത്തോളം സംരക്ഷണം ആവശ്യമെങ്കിൽ, അത് സേവനം യഥാർത്ഥത്തിൽ പിന്തുണയ്ക്കുന്ന പ്രോട്ടോക്കോളിൽ നിന്നും ഐഡന്റിറ്റി മോഡലിൽ നിന്നും വരുന്നു.

ഡിസൈൻ കുറിപ്പിൽ നെറ്റ്വർക്ക് പാളിയുടെയും ആപ്ലിക്കേഷൻ പാളിയുടെയും അവകാശവാദങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുക, കാരണം അവ കൂട്ടിച്ചേർക്കുന്നതാണ് ആരും നടപ്പാക്കാത്ത സംരക്ഷണം അവലോകനം അവകാശപ്പെടാൻ ഇടയാക്കുന്നത്.

എന്ത് രേഖപ്പെടുത്തണം

രണ്ട് സബ്നെറ്റ് ഐഡികൾ, ഓരോന്നിനും ബന്ധപ്പെട്ട റൂട്ട് പട്ടിക, സെക്യൂരിറ്റി ഗ്രൂപ്പ് റഫറൻസുകൾ, നിങ്ങൾ പരിശോധിച്ച ആപ്ലിക്കേഷൻ പ്രവർത്തനം എന്നിവ രേഖപ്പെടുത്തുക. ഇവ നാല് വസ്തുതകളാണ്, ഈ പാതയെക്കുറിച്ചുള്ള ഭാവിയിലെ മിക്ക തർക്കങ്ങളും അവ തീർക്കുന്നു.

മേഖലയിൽ സ്ഥാപിക്കുന്നത് മാത്രം ഒരിക്കലും VPN ചേർക്കാൻ പറയുന്നില്ല, സ്വകാര്യ അഭ്യർത്ഥന എന്തുകൊണ്ട് പരാജയപ്പെട്ടു എന്നും ഒരിക്കലും വിശദീകരിക്കുന്നില്ല.