ഒരു ആന്തരിക ലോഡ് ബാലൻസറിനെതിരെ പൊതു DNS ലുക്കപ്പ് നടത്തിയാൽ സ്വകാര്യ വിലാസം തിരികെ ലഭിച്ചേക്കാം; റെക്കോർഡ് എന്തിനുള്ളതാണെന്ന് പരിശോധിക്കുന്നതുവരെ ഇത് തെറ്റായ കോൺഫിഗറേഷൻ പോലെ തോന്നും. ആന്തരിക ലോഡ് ബാലൻസർ നാമങ്ങൾ പൊതുവായി റിസോൾവ് ചെയ്യാവുന്നതാകാമെന്നും അവയുടെ നോഡുകൾ സ്വകാര്യ വിലാസങ്ങൾ മാത്രം കൈവശം വയ്ക്കുന്നുവെന്നും AWS രേഖപ്പെടുത്തുന്നു. റിസോൾവർ സേവനം എവിടെയാണെന്ന് ഉത്തരം നൽകി; അത് ഒരു റൂട്ട് സൃഷ്ടിച്ചില്ല, സുരക്ഷാ ഗ്രൂപ്പ് തുറന്നില്ല, ആരെയും പ്രമാണീകരിച്ചില്ല. ആ ഉത്തരം ഒരു പ്രശ്നമാണോ എന്നത് ക്രമത്തിൽ പരിശോധിക്കാവുന്ന വസ്തുതകളെ ആശ്രയിച്ചിരിക്കുന്നു.

ആദ്യ പടി: IP അല്ല, സ്കീം വായിക്കുക

സ്കീം ഫീൽഡ് ലോഡ് ബാലൻസറിന്റെ സ്വന്തം അതിർത്തിയെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്. aws elbv2 describe-load-balancers --names app-internal internal അല്ലെങ്കിൽ internet-facing മൂല്യമുള്ള Scheme തിരികെ നൽകുന്നു, കൂടാതെ IPv4 അല്ലെങ്കിൽ ഇരട്ട സ്റ്റാക്കിനുള്ള വിലാസ തരവും. ഇൻറർനെറ്റിലേക്ക് അഭിമുഖീകരിക്കുന്ന ലോഡ് ബാലൻസറിന് സ്വകാര്യ ലക്ഷ്യങ്ങളിലേക്ക് ഫോർവേഡ് ചെയ്യാനാകും, അതിനാൽ സ്വകാര്യ ബാക്കെൻഡ് വിലാസങ്ങൾ കാണുന്നത് മുൻഭാഗത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

മറ്റെന്തെങ്കിലും നോക്കുന്നതിന് മുമ്പ് സ്കീം എഴുതി വയ്ക്കുക, കാരണം തുടർന്നുള്ള ഓരോ വിലയിരുത്തലും അതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഏതൊക്കെ നിയന്ത്രണങ്ങളുണ്ടെന്നും അത് പറയുന്നു, സുരക്ഷാ ഗ്രൂപ്പുകളും ലിസണർ നിയമങ്ങളും മുതൽ ആ ലോഡ് ബാലൻസർ തരത്തിന്റെ സവിശേഷതകൾ വരെ. പഴയ കൺസോൾ സ്ക്രീൻഷോട്ടിൽ നിന്ന് പകർത്തിയ സ്കീം ഒരു കുറിപ്പും ഇല്ലാത്തതിനേക്കാൾ മോശമാണ്. API-യിൽ നിന്ന് വീണ്ടും വായിച്ച് മൂല്യം ടിക്കറ്റിൽ ഒട്ടിക്കുക.

രണ്ടാം പടി: നാമം എന്തിലേക്ക് റിസോൾവ് ചെയ്യുന്നു എന്ന് നോക്കുക

VPC-യ്ക്ക് പുറത്തുനിന്ന് dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com ഉപയോഗിച്ച് ചോദിക്കുക, ഉത്തരങ്ങൾ 10.0.0.0/8, 172.16.0.0/12 അല്ലെങ്കിൽ 192.168.0.0/16 എന്നിവയിലാണോ എന്ന് ശ്രദ്ധിക്കുക. പൊതു റിസോൾവറിൽ നിന്നുള്ള സ്വകാര്യ ഉത്തരം ആന്തരിക ലോഡ് ബാലൻസർ നാമത്തിന് പ്രതീക്ഷിക്കുന്ന പെരുമാറ്റമാണ്; വിലാസം ഇൻറർനെറ്റിൽ നിന്ന് റൂട്ട് ചെയ്യാമെന്നതിന്റെ തെളിവല്ല.

അതേ നാമം VPC-യ്ക്കുള്ളിൽ നിന്ന് റിസോൾവ് ചെയ്ത് താരതമ്യം ചെയ്യുക. രണ്ട് ഉത്തരങ്ങളും വ്യത്യസ്തമാണെങ്കിൽ, നിങ്ങൾ സ്പ്ലിറ്റ്-ഹൊറൈസൺ നാമകരണം കാണുന്നു, ആ വ്യത്യാസം ഡിസൈൻ വിശദാംശമാണ്, ചോർച്ചയല്ല.

മൂന്നാം പടി: അതിൽ എത്താവുന്ന പാതകൾ പട്ടികപ്പെടുത്തുക

സ്വകാര്യ വിലാസം റൂട്ടും സുരക്ഷാ നിയമവും ഉള്ള എവിടെനിന്നും എത്താവുന്നതാണ്. അവ ബോധപൂർവം പട്ടികപ്പെടുത്തുക: സൈറ്റ്-ടു-സൈറ്റ് VPN, ക്ലയന്റ് VPN, VPC പിയറിംഗ്, ട്രാൻസിറ്റ് ഗേറ്റ്വേ അറ്റാച്ച്മെന്റുകൾ, Direct Connect, കൂടാതെ VPC-യ്ക്കുള്ളിലെ ഏതെങ്കിലും പ്രോക്സിയോ ബാസ്റ്റിയണോ. അവയിലൊന്ന് ഉദ്ദേശിച്ച പാതയാണ്, ബാക്കിയുള്ളവ ഒരു ആക്രമണകാരി തിരയുന്ന പാതകളാണ്.

തുടർന്ന് ഓരോ പാതയിലെയും നിയന്ത്രണങ്ങൾ പരിശോധിക്കുക: ലോഡ് ബാലൻസറിലെ സുരക്ഷാ ഗ്രൂപ്പുകൾ, സബ്നെറ്റുകളിലെ നെറ്റ്വർക്ക് ACL, പാത നിലനിൽക്കുന്നതാക്കുന്ന റൂട്ടിംഗ്. വെളിപ്പെട്ട ആന്തരിക സേവനത്തെക്കുറിച്ച് റിപ്പോർട്ട് ചെയ്ത മിക്ക കേസുകളും ഇവിടെ പരിഹരിക്കപ്പെടുന്നു: ഒന്നുകിൽ ഉദ്ദേശിക്കാത്ത പിയറിംഗ് ഉണ്ടായിരുന്നു, അല്ലെങ്കിൽ പാത ഉദ്ദേശിച്ചതായിരുന്നു, ആപ്പ്ലിക്കേഷന് പ്രമാണീകരണം ഇല്ലായിരുന്നു.

നാലാം പടി: ലിസണറും ആപ്പ്ലിക്കേഷനും വെവ്വേറെ പരീക്ഷിക്കുക

സേവനത്തിൽ എത്തരുതാത്ത ഒരു നെറ്റ്വർക്കിൽ നിന്ന് കണക്റ്റ് ചെയ്യാൻ ശ്രമിച്ച് കഴിയില്ലെന്ന് ഉറപ്പാക്കുക. തുടർന്ന് എത്തേണ്ട ഒന്നിൽ നിന്ന് ശ്രമിച്ച് ഒരു ലിസണറിൽ എത്തുന്നുവെന്ന് ഉറപ്പാക്കുക. ഈ രണ്ട് ഫലങ്ങൾ നെറ്റ്വർക്ക് എത്തിച്ചേരലിനെ ആപ്പ്ലിക്കേഷൻ പെരുമാറ്റത്തിൽ നിന്ന് വേർതിരിക്കുന്നു, വെളിപ്പെടൽ ചോദ്യത്തിന് പ്രധാനമായ ഏക തെളിവ് അവയാണ്.

എത്താവുന്ന ലിസണർ പ്രവേശിക്കാവുന്ന ആപ്പ്ലിക്കേഷന് തുല്യമല്ല. TLS സർട്ടിഫിക്കറ്റും പ്രോട്ടോക്കോൾ നയവും, തുടർന്ന് ആപ്പ്ലിക്കേഷന്റെ സ്വന്തം പ്രമാണീകരണവും അംഗീകാരവും പരിശോധിക്കുക. കോർപ്പറേറ്റ് VPN-ൽ ഏതെങ്കിലും വിളിക്കുന്നയാളെ സ്വീകരിക്കുന്ന ആന്തരിക ഉപകരണം ആ VPN-ലെ ഓരോ വിട്ടുവീഴ്ച ചെയ്ത ലാപ്ടോപ്പിനും വെളിപ്പെട്ടതാണ്, ഇത് ഇൻറർനെറ്റിലേക്ക് അഭിമുഖീകരിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ അപകടസാധ്യതയാണ്, പക്ഷേ ഇപ്പോഴും അപകടസാധ്യതയാണ്.

നിയന്ത്രണങ്ങൾ തരം അനുസരിച്ച് വ്യത്യാസപ്പെടുന്നുവെന്ന് ഓർക്കുക. ആപ്പ്ലിക്കേഷൻ പാളി ഫയർവാളുകൾ ഒരു ലോഡ് ബാലൻസർ കുടുംബത്തോട് ചേരുന്നു, മറ്റൊന്നിനോടല്ല, അതിനാൽ തുല്യത അനുമാനിക്കുന്നതിന് പകരം നിങ്ങളുടെ മുന്നിലുള്ള സ്കീമിനും തരത്തിനും യഥാർത്ഥത്തിൽ എന്താണ് ലഭ്യമെന്ന് ഉറപ്പാക്കുക.

അഞ്ചാം പടി: നാമത്തിന് തന്നെ പ്രാധാന്യമുണ്ടോ എന്ന് തീരുമാനിക്കുക

പൊതു റിസോൾവബിലിറ്റി ഒരു സേവന നാമം, ഒരു പ്രദേശം, ഒരു വിലാസ ശ്രേണി എന്നിവ വെളിപ്പെടുത്തിയേക്കാം. അതിനെ നയപരമായ ഉത്തരമുള്ള ഒരു വിവര വെളിപ്പെടൽ ചോദ്യമായി കാണുക, സ്വയം പ്രവർത്തിക്കുന്ന സംഭവമായി അല്ല: സങ്കീർണ്ണമായ ബിസിനസ് പദങ്ങൾ റിസോഴ്സ് നാമങ്ങൾക്ക് പുറത്ത് നിർത്തുക, നാമകരണ സമ്പ്രദായം നിങ്ങൾ ആഗ്രഹിക്കുന്നതിലധികം വെളിപ്പെടുത്തുന്നുവെങ്കിൽ അപകട രേഖയിൽ വെളിപ്പെടൽ രേഖപ്പെടുത്തുക.

സംഘടനയ്ക്ക് സ്വകാര്യ നാമകരണ അനുഭവം വേണമെങ്കിൽ, ഒരു സ്വകാര്യ ഹോസ്റ്റ് ചെയ്ത സോൺ ബന്ധപ്പെട്ട VPC-കൾക്കുള്ളിൽ മാത്രം റിസോൾവ് ചെയ്യുന്ന ഒരു അലിയാസ് നൽകാം. അത് ഉപയോക്താക്കൾ കാണുന്ന നാമം മാറ്റുന്നു; ദാതാവ് സൃഷ്ടിച്ച നാമം രഹസ്യമാക്കുന്നില്ല, ഒരു നെറ്റ്വർക്ക് പാതയും നീക്കം ചെയ്യുന്നില്ല.

ഉത്തരം മറയ്ക്കാൻ വിലാസങ്ങൾ പിൻ ചെയ്യാൻ ശ്രമിക്കരുത്. ലോഡ് ബാലൻസർ വിലാസങ്ങൾ മാറുന്നു, പിൻ ചെയ്യൽ TLS പരിശോധനാ ശീലങ്ങൾ തകർക്കുന്നു, യഥാർത്ഥത്തിൽ വേണ്ട നിയന്ത്രണം ആർക്ക് കണക്ഷൻ സ്ഥാപിക്കാമെന്നും ആപ്പ്ലിക്കേഷൻ അവരിൽ നിന്ന് എന്ത് ആവശ്യപ്പെടുന്നുവെന്നും ആണ്. നാല് വസ്തുതകൾ പരിശോധിച്ച് എഴുതുക, ചോദ്യം അവ്യക്തമായി തുടരില്ല.

അനുബന്ധ ലേഖനങ്ങൾ