AWS Client VPN നിയമങ്ങൾ റിസോഴ്‌സിലാണ്, സബ്‌നെറ്റിലല്ല

ജീവനക്കാർ VPC യിലെ ഒരു ആപ്ലിക്കേഷനിൽ എത്തണം, അതേ ഇൻസ്റ്റൻസിലെ ഡാറ്റാബേസ് ലിസണറിൽ എത്തരുത്, അതിനാൽ ആരോ VPN endpoint നായി രണ്ടാമത്തെ പൊതു സബ്‌നെറ്റ് ചേർത്ത് ആവശ്യകത പൂർത്തിയായി പ്രഖ്യാപിക്കുന്നു. സബ്‌നെറ്റിന്റെ സ്ഥാനം റൂട്ടിംഗും ലഭ്യതയും മാറ്റുന്നു. അത് ഒരു പോർട്ടും നൽകുകയോ തടയുകയോ ചെയ്യുന്നില്ല. ആവശ്യകത പ്രകടിപ്പിക്കുന്ന അനുമതി ലക്ഷ്യസ്ഥാനത്ത്, റിസോഴ്‌സിന്റെ സെക്യൂരിറ്റി ഗ്രൂപ്പിൽ കഴിയുന്നു, VPN അതിർത്തി ആ നിയമം സൂചിപ്പിക്കുന്ന ഹാൻഡിൽ നൽകുന്നു.

സബ്‌നെറ്റിന്റെ സ്ഥാനം റൂട്ടിംഗാണ്, അധികാരമല്ല

endpoint ന്റെ നെറ്റ്‌വർക്ക് അസോസിയേഷൻ എവിടെയാണെന്നത് ഏത് റൂട്ട് ടേബിൾ ക്ലയന്റ് ട്രാഫിക് കൊണ്ടുപോകുന്നു, ഏത് ലഭ്യതാ മേഖലകൾ പരാജയത്തെ അതിജീവിക്കുന്നു എന്നത് തീരുമാനിക്കുന്നു. ആ ട്രാഫിക് ഏത് ഇൻസ്റ്റൻസിലെ ഏത് പോർട്ടിൽ എത്താം എന്നതിനെപ്പറ്റി അത് ഒന്നും പറയുന്നില്ല. ഒരേ സബ്‌നെറ്റുമായി ബന്ധിപ്പിച്ച രണ്ട് ക്ലയന്റുകളും ഇപ്പോഴും ഒരേ ഉറവിട ഐഡന്റിറ്റിയുമായി എത്തുന്നു, സബ്‌നെറ്റിന്റെ പേരുകൊണ്ട് റിസോഴ്‌സിന് അവരെ വേർതിരിക്കാനാവില്ല.

പകരം ആവശ്യകതയിൽ നിന്ന് തുടങ്ങുക: ആരാണ് വിളിക്കുന്നത്, ഏത് റിസോഴ്‌സ്, ഏത് സേവന പോർട്ട്, ഏത് ദിശ. തുടർന്ന് ആ നാല് കാര്യങ്ങൾ ലക്ഷ്യസ്ഥാനത്ത് പ്രകടിപ്പിക്കാൻ കഴിയുന്ന നിയമ മാതൃക തിരഞ്ഞെടുക്കുക. ആ ചട്ടക്കൂട് സാധാരണയായി അധിക സബ്‌നെറ്റ് ഡിസൈനിൽ നിന്ന് പൂർണ്ണമായി ഒഴിവാക്കുന്നു.

Client VPN അസോസിയേഷൻ ഗ്രൂപ്പാണ് ആ ഹാൻഡിൽ

സബ്‌നെറ്റുമായി ബന്ധിപ്പിച്ച AWS Client VPN endpoint ന് രേഖപ്പെടുത്തിയ ക്രമം നിർദ്ദിഷ്ടമാണ്. ഉദ്ദേശിച്ച സെക്യൂരിറ്റി ഗ്രൂപ്പ് endpoint ന്റെ ലക്ഷ്യ നെറ്റ്‌വർക്ക് അസോസിയേഷനുകളിൽ പ്രയോഗിക്കുക, തുടർന്ന് ആ Client VPN ഗ്രൂപ്പ് ഉറവിടമായി ഉപയോഗിച്ച് റിസോഴ്‌സിന്റെ സെക്യൂരിറ്റി ഗ്രൂപ്പിൽ ആവശ്യമായ ട്രാഫിക് അനുവദിക്കുക.

നിർദ്ദിഷ്ടമായി, ആപ്ലിക്കേഷൻ ഇൻസ്റ്റൻസിന്റെ ഗ്രൂപ്പ് അസോസിയേഷൻ ഗ്രൂപ്പിൽ നിന്ന് ആപ്ലിക്കേഷൻ പോർട്ട് മാത്രം അനുവദിക്കുന്നു, മറ്റൊന്നുമല്ല. AWS ന്റെ റിസോഴ്‌സ് ആക്സസ് നടപടിക്രമം ആ ബന്ധം വിവരിക്കുന്നു, endpoint ബന്ധിപ്പിക്കുന്ന ഓരോ സബ്‌നെറ്റിലും അതേ ഗ്രൂപ്പ് നയം നിലനിർത്തുന്നത് മൂല്യവത്താണ്, കാരണം മറ്റൊരു ഗ്രൂപ്പുമായുള്ള പഴയ അസോസിയേഷൻ അതിർത്തി നിശബ്ദമായി വിശാലമാക്കുന്നു.

ആ നിയമം ആരെയും പ്രാമാണീകരിക്കുന്നില്ല. ലോഗിൻ പ്രത്യേക നിയന്ത്രണമാണ്, റിസോഴ്‌സിലേക്കുള്ള പാത മൂന്നാമത്തേതാണ്. അഭ്യർത്ഥന എത്തുന്നതിന് മുൻപ് മൂന്നും ശരിയാകണം. ഏതാണ് പരാജയപ്പെടുന്നത് എന്നത് ഏത് തിരുത്തലാണ് ശരി എന്ന് തീരുമാനിക്കുന്നു, നിയമം മാറ്റുന്നത് ആദ്യത്തേതിന് മാത്രമാണ് ശരിയായ ഉത്തരം.

ഒരു അസോസിയേഷൻ ഗ്രൂപ്പിന് വേർതിരിക്കാനാവാത്തത്

ഒരേ അസോസിയേഷൻ ഗ്രൂപ്പിന് പിന്നിലുള്ള ഓരോ ക്ലയന്റും അതേ സെക്യൂരിറ്റി ഗ്രൂപ്പ് ഉറവിടമായി റിസോഴ്‌സിൽ എത്തുന്നു. വ്യത്യസ്ത റോളുകളുള്ള രണ്ട് ഉപയോക്താക്കളെ ആ പാളിയിൽ വേർതിരിക്കാനാവില്ല, ഗ്രൂപ്പിന് എന്ത് പേരോ ടാഗോ നൽകിയാലും. Client VPN ന്റെ ബാഹ്യ ഗ്രൂപ്പ് അധികാരം ഡയറക്ടറി അല്ലെങ്കിൽ SAML ഗ്രൂപ്പിന് ലക്ഷ്യ പ്രിഫിക്സ് പ്രകാരം ആക്സസ് പരിമിതപ്പെടുത്തുന്നു, അത് റിസോഴ്‌സ് റോളിനേക്കാൾ പരുക്കനാണ്, ഐഡന്റിറ്റി സിസ്റ്റമായല്ല, നെറ്റ്‌വർക്ക് അതിർത്തിയായി കാണണം.

സൂക്ഷ്മമായ വ്യത്യാസങ്ങൾ ആപ്ലിക്കേഷന്റേതാണ്. ഭൂരിഭാഗം ജീവനക്കാർക്കും അടച്ചിടേണ്ട ഡാറ്റാബേസ് ലിസണർ, ഗ്രൂപ്പ് അംഗത്വം വൃത്തിയായി നിലനിൽക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നതിനേക്കാൾ, അനുവദിച്ച പ്രിഫിക്സിൽ ഒട്ടും എത്താനാവാത്ത രീതിയിൽ സൂക്ഷിക്കുന്നതാണ് മികച്ച സംരക്ഷണം.

ഗ്രൂപ്പിന്റെ പേര് മാറ്റുന്നത് ഐഡന്റിറ്റി സൃഷ്ടിക്കുന്നില്ല, ഓരോ ടീമിനും അത് പകർത്തുന്നത് ഓഡിറ്റ് ചെയ്യേണ്ട അസോസിയേഷനുകൾ മാത്രം വർദ്ധിപ്പിക്കുന്നു.

ആ നിയമം എല്ലാ VPN ഡിസൈനുകളിലേക്കും പകർത്തരുത്

സ്വയം കൈകാര്യം ചെയ്യുന്ന EC2 VPN ഗേറ്റ്‌വേ, റൂട്ട് ചെയ്ത പരിശോധനാ ഉപകരണം, മാനേജുചെയ്യുന്ന Client VPN എന്നിവ മൂന്ന് വ്യത്യസ്ത പാക്കറ്റ് പാതകളാണ്. ഏത് ഉറവിട വിലാസമാണ് യഥാർത്ഥത്തിൽ റിസോഴ്‌സിൽ എത്തുന്നത്, ഇടയിൽ വിവർത്തനം നടക്കുന്നുണ്ടോ, ആ പാതയിൽ സേവനം ഏത് റഫറൻസ് സംവിധാനങ്ങൾ പിന്തുണയ്ക്കുന്നു എന്നിവ നിർണ്ണയിക്കുക.

ഇടനില ഉപകരണത്തിലൂടെ ട്രാഫിക് കടത്തിവിടുന്നത് നേരിട്ടുള്ള ഇൻസ്റ്റൻസ്-തൊട്ട്-ഇൻസ്റ്റൻസ് ട്രാഫിക് പോലെ ഉറവിട സെക്യൂരിറ്റി ഗ്രൂപ്പ് റഫറൻസ് നിലനിർത്തുന്നില്ല. അത്തരം ഡിസൈനുകൾക്ക് ഗ്രൂപ്പ് റഫറൻസിന് പകരം ഉചിതമായ സ്വകാര്യ ഉറവിട വിലാസങ്ങളോ CIDR ഓ ആവശ്യമായിവരാമെന്ന് AWS രേഖപ്പെടുത്തുന്നു. മാനേജുചെയ്യുന്ന Client VPN നടപടിക്രമം, ഓരോ ഗേറ്റ്‌വേയുടെയും ബന്ധിപ്പിച്ച ഗ്രൂപ്പ് കൈമാറ്റം ചെയ്ത പാക്കറ്റുകൾക്ക് സാർവത്രിക ഐഡന്റിറ്റി ടോക്കണായി പ്രവർത്തിക്കുന്നു എന്നതിന് തെളിവല്ല.

പാതയിൽ ഒരു NAT ഹോപ്പ് മതി അനുമാനം തകർക്കാൻ, പരാജയം നിലവിലുള്ളതും എന്നും പൊരുത്തപ്പെടാത്തതുമായ ഒരു നിയമം പോലെ തോന്നുന്നു.

ഫലപ്രദമായ അതിർത്തി പരിശോധിക്കുക

റിസോഴ്‌സുമായി ബന്ധിപ്പിച്ച ഓരോ സെക്യൂരിറ്റി ഗ്രൂപ്പും വായിക്കുക, കാരണം അനുവദനീയ നിയമങ്ങൾ കൂടിച്ചേരുന്നു, ഇടുങ്ങിയ നിയമം മറ്റൊരു ഗ്രൂപ്പിലെ വിശാലമായ നിയമത്തെ റദ്ദാക്കുന്നില്ല. തുടർന്ന് നെറ്റ്‌വർക്ക് ACL, ഹോസ്റ്റ് ഫയർവാൾ, ആപ്ലിക്കേഷന്റെ സ്വന്തം അധികാരം എന്നിവ പരിശോധിക്കുക, ഇവ വെവ്വേറെ തെറ്റുകളുള്ള വെവ്വേറെ പാളികളാണ്.

അതേ റിസോഴ്‌സിനെതിരെ ഒരു അനുവദിച്ച അഭ്യർത്ഥനയും ഒരു ബോധപൂർവം ഒഴിവാക്കിയ അഭ്യർത്ഥനയും കൊണ്ട് അവസാനിപ്പിക്കുക. ആ ജോടി അതിർത്തി തെളിയിക്കുന്നു, ഒരു വിജയകരമായ കണക്ഷൻ എന്തോ തുറന്നിരിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു. endpoint അടങ്ങുന്ന സബ്‌നെറ്റിന് പകരം പാത, ഫലപ്രദമായ ഉറവിടം, ഉദ്ദേശിച്ച സേവന പോർട്ട് എന്നിവ സ്ഥിരീകരിക്കുക.

ജോലിക്രമം: നാല് ഭാഗ ആവശ്യകത എഴുതുക, ഗ്രൂപ്പ് അസോസിയേഷനുകളിൽ ബന്ധിപ്പിക്കുക, റിസോഴ്‌സ് നിയമം പോർട്ടിൽ പരിമിതപ്പെടുത്തുക, ഒരു അനുമതിയും ഒരു നിരസിക്കലും പരിശോധിക്കുക, അതിനുശേഷം മാത്രം റൂട്ടിംഗ് കാരണങ്ങളാൽ സബ്‌നെറ്റുകൾ വിഭജിക്കുന്നത് പരിഗണിക്കുക.