ഉറവിടം/ലക്ഷ്യം പരിശോധന ഒരു കവാടമാണ്, മുഴുവൻ VPN പാതയല്ല
ഫോർവേഡ് ചെയ്യുന്ന ഇൻസ്റ്റൻസിന് AWS അനുമതിക്കൊപ്പം Linux റൂട്ടുകളും ഫയർവാൾ നിയമങ്ങളും വേണം. ഫോർവേഡ് ചെയ്യുന്ന ഇൻസ്റ്റൻസിൽ തന്നെ ഉറവിടം/ലക്ഷ്യം സാധുത പരിശോധിക്കുക.
VPN ഒരു EC2 ഇൻസ്റ്റൻസിൽ അവസാനിക്കുന്നു, ആ ഇൻസ്റ്റൻസിന്റെ ടണൽ വിലാസത്തിൽ എത്താം, എന്നാൽ അതിലൂടെ മറ്റൊരു സ്വകാര്യ ഹോസ്റ്റിലേക്ക് പോകേണ്ടിയിരുന്ന ട്രാഫിക് അപ്രത്യക്ഷമാകുന്നു. ഇവ രണ്ട് വ്യത്യസ്ത പരിശോധനകളാണ്, അവ കൂട്ടിക്കലർത്തുന്നത് മണിക്കൂറുകൾ പാഴാക്കുന്നു. ആദ്യത്തേത് ഇൻസ്റ്റൻസിൽ എത്താമോ എന്ന് ചോദിക്കുന്നു; രണ്ടാമത്തേത് സ്വന്തമല്ലാത്ത ലക്ഷ്യത്തിലേക്ക് ട്രാഫിക് ഫോർവേഡ് ചെയ്യാൻ ആവശ്യപ്പെടുന്നു, അതിന് Linux ഫോർവേഡിംഗ്, ഫയർവാൾ നയം, അപ്പുവശത്ത് ഒരു റൂട്ട്, ഗസ്റ്റ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റവുമായി യാതൊരു ബന്ധവുമില്ലാത്ത AWS തലത്തിലുള്ള അനുമതി എന്നിവ വേണം. കൺസോളിൽ ഒന്നും ആ വ്യത്യാസത്തിലേക്ക് ശ്രദ്ധ ക്ഷണിക്കുന്നില്ല. ലക്ഷണം റൂട്ടിംഗ് തകരാറിനോട് സാമ്യമുള്ളതാണ്, സാധാരണയായി അതല്ല.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രണ്ട് പരിശോധനകളും വേർതിരിക്കുക
ഗേറ്റ്വേയിൽ എത്തുന്നത് ടണലും അതിന്റെ വിലാസത്തിലേക്കുള്ള റൂട്ടും കൈമാറ്റം അനുവദിക്കുന്ന സുരക്ഷാ ഗ്രൂപ്പും തെളിയിക്കുന്നു. മറ്റൊരു ഹോസ്റ്റിനുള്ള ഫോർവേഡിംഗ് അവയൊന്നും തെളിയിക്കുന്നില്ല: അത് മറ്റൊരു ഉറവിട വിലാസവും മറ്റൊരു ലക്ഷ്യവും അതിനായി നിർബന്ധമായി നിർമ്മിക്കാത്ത ഒരു റോളിലുള്ള ഇൻസ്റ്റൻസും ഉപയോഗിക്കുന്നു. രണ്ട് പരിശോധനകളും വെവ്വേറെ എഴുതി ഏതാണ് പരാജയപ്പെടുന്നതെന്ന് രേഖപ്പെടുത്തുക, കാരണം ഓരോന്നിന്റെയും തിരുത്ത് വേറെ കൺസോളിലാണ്. ടണലുകൾ അവസാനിപ്പിക്കാൻ മാത്രം നിർമ്മിച്ച ഗേറ്റ്വേ ഇൻസ്റ്റൻസിന് മറ്റെന്തിനും ഫോർവേഡ് ചെയ്യാൻ കാരണമില്ല, അതിന്റെ സ്ഥിരമൂല്യങ്ങൾ അത് പ്രതിഫലിപ്പിക്കുന്നു. അതിനാൽ രണ്ടാമത്തെ പരിശോധനയ്ക്ക് സ്വന്തം ക്രമീകരണം വേണം, ആദ്യത്തേതിലെ ചെറിയ മാറ്റമല്ല.
ഗേറ്റ്വേയിലേക്ക് പ്രവർത്തിക്കുന്ന ping, അതിനപ്പുറമുള്ള ഹോസ്റ്റിലേക്ക് പരാജയപ്പെടുന്ന ping എന്നിവ ഇടവിട്ടുള്ള പ്രശ്നമല്ല. ഫോർവേഡ് ചെയ്യാമെന്ന് പറയപ്പെടാത്ത ഇൻസ്റ്റൻസിന്റെ പ്രതീക്ഷിത സ്വഭാവമാണിത്.
ഒരു ക്രമീകരണം തൊടുന്നതിന് മുമ്പ് പാത എഴുതുക
ക്ലയന്റ് പ്രിഫിക്സ്, ഫോർവേഡിംഗ് ഇൻസ്റ്റൻസ് അല്ലെങ്കിൽ നെറ്റ്വർക്ക് ഇന്റർഫേസ്, ലക്ഷ്യ സബ്നെറ്റ്, മറുപടി റൂട്ട് എന്നിവ രേഖപ്പെടുത്തുക. ഒരു ഇൻസ്റ്റൻസിലേക്ക് ചൂണ്ടുന്ന VPC റൂട്ട് ടേബിൾ എൻട്രി ഇൻസ്റ്റൻസിന്റെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തെ ഫോർവേഡ് ചെയ്യാൻ ക്രമീകരിക്കുന്നില്ല, ഫോർവേഡിംഗ് ഓണായ ഗസ്റ്റ് കേർണൽ VPC റൂട്ട് സൃഷ്ടിക്കുന്നുമില്ല. ആ ബന്ധത്തിന്റെ രണ്ടറ്റവും ഉണ്ടായിരിക്കണം, അവ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ വ്യത്യസ്ത പ്രവേശനമുള്ള ആളുകൾ തിരുത്തുന്നു.
തുടർന്ന് ഉറവിടം/ലക്ഷ്യം പരിശോധനയുടെ ക്രമീകരണം യഥാർത്ഥ ഫോർവേഡിംഗ് ഘടകത്തിൽ പരിശോധിക്കുക, VPCയിലെ ഓരോ ഇൻസ്റ്റൻസിലുമല്ല. മറ്റുള്ളവർക്കായി ട്രാഫിക് ഫോർവേഡ് ചെയ്യുന്ന ഇൻസ്റ്റൻസിന് ആ പരിശോധന ഓഫാക്കേണ്ടത് എന്തുകൊണ്ടെന്നും, ക്രമീകരണം മുഴുവൻ VPCയുടെ സ്ഥിരമൂല്യമല്ലാതെ ഓരോ ഇൻസ്റ്റൻസിന്റെയും തീരുമാനമാകുന്നത് എന്തുകൊണ്ടെന്നും AWS രേഖപ്പെടുത്തുന്നു.
നാല് അതിരുകൾ, പരിശോധന അവയിലൊന്ന് മാത്രം
പാതയെ നാല് ചോദ്യങ്ങളായി കാണുക, ക്രമത്തിൽ അവയ്ക്ക് ഉത്തരം നൽകുക. ആദ്യം പരാജയപ്പെടുന്ന ഉത്തരമാണ് ജോലിയുള്ളിടം, ബാക്കിയൊന്നും അത് നികത്തില്ല.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
ക്രമം പ്രധാനമാണ് കാരണം പരിശോധന വിലകുറഞ്ഞതാണ്: റൂട്ടുകൾ ഒരു പേജിൽ കാണാം, പരിശോധന ഒരു ഗുണവിശേഷമാണ്, ലക്ഷ്യത്തിന്റെ അഭിപ്രായം സാധാരണയായി ആളുകൾ ഒടുവിൽ ചോദിക്കുന്ന കാര്യമാണ്.
വിവർത്തനം ലക്ഷ്യം ഏത് ഉറവിടത്തെ കാണുന്നു എന്ന് മാറ്റുന്നു
റൂട്ട് ചെയ്ത രൂപകൽപ്പന ക്ലയന്റിന്റെ ഉറവിട വിലാസം നിലനിർത്തുന്നു, അതിനാൽ ലക്ഷ്യത്തിന് ക്ലയന്റ് പ്രിഫിക്സിലേക്ക് മടങ്ങിപ്പോകുന്ന റൂട്ട് വേണം. വിവർത്തനം ചെയ്ത രൂപകൽപ്പന പകരം ഗേറ്റ്വേയുടെ വിലാസം അവതരിപ്പിക്കുന്നു, അത് ആ ആവശ്യകത ഒഴിവാക്കി ഗേറ്റ്വേയിലെ ഒരു അവസ്ഥാ പട്ടിക കൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നു. ബന്ധമില്ലാത്ത ഒരു ഉദാഹരണം അത് ഉപയോഗിച്ച് പ്രവർത്തിച്ചതായി തോന്നിയതിനാൽ വിവർത്തനം ചേർക്കാതെ, ഉദ്ദേശിക്കുന്ന വാസ്തുവിദ്യ അനുസരിച്ച് തീരുമാനിക്കുക.
നിങ്ങൾ വിവർത്തനം ചെയ്യുന്നുവെങ്കിൽ, നിയമം ക്ലയന്റ് പ്രിഫിക്സിലേക്കും ഉദ്ദേശിച്ച ലക്ഷ്യത്തിലേക്കും പരിമിതപ്പെടുത്തുക. നിലനിർത്തുന്നുവെങ്കിൽ, അപ്പുവശം റൂട്ട് യഥാർത്ഥത്തിൽ അറിയുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക, പഠിക്കുമെന്ന് അനുമാനിക്കരുത്.
യഥാർത്ഥ ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക, പിന്നീട് മാറ്റം നിലനിർത്തുക
ഗേറ്റ്വേയിൽ സൃഷ്ടിച്ച അഭ്യർത്ഥന വിജയിച്ചേക്കാം, എന്നാൽ ഫോർവേഡ് ചെയ്ത അഭ്യർത്ഥന പരാജയപ്പെടുന്നു, കാരണം അത് വേറെ ഉറവിടവും വേറെ ഫോർവേഡിംഗ് കേസുമാണ്. ലക്ഷ്യമിട്ട തിരുത്തലിന് ശേഷം പരാജയപ്പെട്ട അതേ ക്ലയന്റിൽ-നിന്ന്-വിഭവത്തിലേക്കുള്ള പരിശോധന അതേ ക്ലയന്റിൽ നിന്ന് ആവർത്തിക്കുക, അഭ്യർത്ഥന എത്തിയത് മാത്രമല്ല മറുപടി തിരികെ വരുന്നു എന്നും ഉറപ്പാക്കുക.
അവസാനം, ക്രമീകരണം ഗേറ്റ്വേയുടെ കൈകാര്യം ചെയ്യുന്ന കോൺഫിഗറേഷനിൽ ഇടുക, പകരം വരുന്ന ഇൻസ്റ്റൻസിന് അത് ലഭിക്കാൻ. കൈകൊണ്ട് ചെയ്ത ഒരു ഒഴിവാക്കലിനെ ആശ്രയിക്കുന്ന വിജയകരമായ പരിശോധന അടുത്ത പുനർനിർമ്മാണത്തിൽ അവസാനിക്കുന്ന പരിശോധനയാണ്, അത് കണ്ടെത്തിയ വ്യക്തി എന്തുകൊണ്ടെന്ന് ഓർക്കാൻ അവിടെ ഉണ്ടാകില്ല.