ക്ലൗഡ് അതിർത്തിയിൽ VPN ക്ലയന്റ് IP കൾ സംരക്ഷിക്കുക അല്ലെങ്കിൽ SNAT ചെയ്യുക

VPN ക്ലയന്റിന്റെ വിലാസം ആപ്ലിക്കേഷൻ വരെ നിലനിർത്തുന്നത് ഓരോ ലോഗ് വരിയും അനുമതി പട്ടികയിലെ ഓരോ എൻട്രിയും ഒരേ അർത്ഥം നൽകുന്നു. ക്ലൗഡ് അറ്റത്ത് അത് വീണ്ടും എഴുതുന്നത് റൂട്ടിംഗ് പട്ടിക ലളിതമാക്കുകയും ലോഗുകൾ കുറച്ച് ഉപയോഗപ്രദമാക്കുകയും ചെയ്യുന്നു. രണ്ട് തിരഞ്ഞെടുപ്പുകളും സ്വയം തെറ്റല്ല, അത് തീരുമാനിക്കുന്ന വാദം അപൂർവ്വമായി പ്രകടനത്തെക്കുറിച്ചാണ്. മൂന്ന് വ്യവസ്ഥകൾ അത് തീരുമാനിക്കുന്നു: ഏത് മനുഷ്യനാണ് കണക്ട് ചെയ്തതെന്ന് ആപ്ലിക്കേഷൻ അറിയണമോ, നിങ്ങൾ അയക്കാൻ ഉദ്ദേശിക്കുന്ന ഉറവിടം ക്ലൗഡ് വസ്ത്രം സ്വീകരിക്കുമോ, പിന്നീട് മടക്ക പാതയുടെ ഉത്തരവാദിത്തം ആര് ഏൽക്കും.

മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു

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

രണ്ടാമത്തെ വ്യവസ്ഥ യാന്ത്രികമാണ്. ഒരു വെർച്വൽ നെറ്റ്വർക്ക് അയക്കുന്ന ഇന്റർഫേസിന് നൽകിയിട്ടില്ലാത്ത ഒരു വിലാസം അവകാശപ്പെടുന്ന പാക്കറ്റിനെ സ്വയമേവ വിശ്വസിക്കുന്നില്ല. മിക്ക ക്ലൗഡ് വസ്ത്രങ്ങളും അത് വിവിധ രീതികളിലും വിവിധ പേരുകളിലും നടപ്പിലാക്കുന്നു, അത് അവഗണിക്കുന്ന ഒരു ഡിസൈൻ ഡയഗ്രാമിൽ ശരിയായി തോന്നുകയും ഉത്പാദനത്തിൽ നിശബ്ദമായി വീഴുകയും ചെയ്യും.

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

പാത വ്യാജനിർമ്മാണത്തിനുള്ള അനുമതിയല്ല

മടക്ക പാത ചേർക്കുന്നത് ഉത്തരങ്ങൾ എവിടെ പോകണം എന്ന് നിങ്ങളുടെ സബ്നെറ്റിനോട് പറയുന്നു. ആ പാക്കറ്റുകൾ കൈമാറുന്ന ഇൻസ്റ്റൻസിന് വിദേശ ഉറവിടത്തോടെ അവ അയക്കാൻ അധികാരമുണ്ടെന്ന് അത് വസ്ത്രത്തോട് പറയുന്നില്ല. AWS ൽ പ്രസക്തമായ നിയന്ത്രണം ഉറവിട-ലക്ഷ്യ പരിശോധനയാണ്, അത് ഓരോ ഇൻസ്റ്റൻസിനും കാണാം:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

രേഖപ്പെടുത്തിയ ജോലി കൈമാറ്റമായ ഇൻസ്റ്റൻസിന് മാത്രം അത് ഓഫ് ചെയ്യുക, മറ്റൊന്നിനും അല്ല. പരിശോധന ഓണായി വെക്കുന്ന ഓരോ ആപ്ലിക്കേഷൻ VM ഉം കടം വാങ്ങിയ ഉറവിടത്തോടെ ട്രാഫിക് അയക്കാൻ ഉപയോഗിക്കാവുന്ന ഒരു യന്ത്രം കുറവാണ്. നിങ്ങളുടെ പ്ലാറ്റ്ഫോം AWS അല്ലെങ്കിൽ, സ്വഭാവം കൈമാറുമെന്ന് കരുതുന്നതിന് പകരം തത്തുല്യമായ ആന്റി-സ്പൂഫിംഗ് അല്ലെങ്കിൽ അനുവദിച്ച വിലാസ ക്രമീകരണം തിരയുക.

വേഗത്തിലുള്ള പാക്കറ്റ് ക്യാപ്ചർ കൺസോൾ വായിക്കുന്നതിനേക്കാൾ വേഗത്തിൽ ചോദ്യം തീർക്കുന്നു. ഉത്തരങ്ങൾ പുറത്തുപോയി ക്ലയന്റ് അവ ഒരിക്കലും കാണുന്നില്ലെങ്കിൽ, ആപ്ലിക്കേഷനല്ല പരാജയപ്പെടുന്നത്, വസ്ത്രമാണ് വ്യാജ ഉറവിടം വലിച്ചെറിയുന്നത്.

വിവർത്തനം എന്ത് വാങ്ങുന്നു, എന്ത് ചെലവാകുന്നു

ഗേറ്റ്വേയിൽ ഉറവിടം വീണ്ടും എഴുതുന്നത് മടക്ക പാതയുടെ പ്രശ്നം ഇല്ലാതാക്കുന്നു. ആപ്ലിക്കേഷൻ എത്തിച്ചേരാൻ ഇതിനകം അറിയുന്ന ഒരു വിലാസം മാത്രം കാണുന്നു, ക്ലയന്റ് പ്രിഫിക്സ് ഒരിക്കലും ക്ലൗഡ് റൂട്ട് പട്ടികയിൽ വരേണ്ടതില്ല. Linux ൽ നിയമം ഒരു വരിയാണ്, കഴിയുന്നത്ര ഇടുങ്ങിയ പതിപ്പ് എഴുതുന്നത് മൂല്യവത്താണ്:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

ആപ്ലിക്കേഷൻ ഇപ്പോൾ എന്ത് രേഖപ്പെടുത്തുന്നു എന്ന് ശ്രദ്ധിക്കുക: ഓരോ ഉപയോക്താവിനും 10.40.3.10, ഓരോ കണക്ഷനിലും, എന്നെന്നേക്കുമായി. ആ മൂല്യത്തിന്മേൽ നിർമ്മിച്ച ഏത് വിലാസ അനുമതി പട്ടികയും ഇപ്പോൾ മുഴുവൻ വിദൂര ആക്സസ് ജനസംഖ്യയ്ക്കും പ്രവേശനം നൽകുന്നു, ഏത് സംഭവ അവലോകനവും ഇത് ആരായിരുന്നു എന്ന് ഉത്തരം നൽകാൻ ഗേറ്റ്വേയിലേക്ക് മടങ്ങണം.

പരിഹാരം വിവർത്തനം ഉപേക്ഷിക്കലല്ല, വിലാസം ഐഡന്റിറ്റിയാണെന്ന് നടിക്കുന്നത് നിർത്തലാണ്. ക്ലയന്റിന്റെ ഐഡന്റിറ്റി പ്രാമാണീകരിച്ച ഫീൽഡിൽ കൊണ്ടുനടക്കുക, വിവർത്തനം ചെയ്ത ട്യൂപ്പിളിനൊപ്പം ഗേറ്റ്വേയിൽ അത് ലോഗ് ചെയ്യുക, ആപ്ലിക്കേഷനെ അതിൽ ചേരാൻ അനുവദിക്കുക. ജോയിൻ കീ ഇല്ലാതെ, വിവർത്തനം ഒരു നെറ്റ്വർക്ക് പ്രശ്നത്തെ ശാശ്വത ഫോറൻസിക് പ്രശ്നമാക്കി മാറ്റുന്നു.

റിലേ മറ്റൊരു ഇന്റർഫേസാണ്

ആപ്ലിക്കേഷന്റെ മുന്നിലുള്ള റിവേഴ്സ് പ്രോക്സി റൂട്ട് ചെയ്ത പാതയുടെ ചോദ്യം പൂർണ്ണമായി ഒഴിവാക്കുന്നു. പ്രോക്സി സ്വന്തം ബാക്ക്എൻഡ് കണക്ഷൻ തുറക്കുന്നു, അതിനാൽ ക്ലയന്റ് പ്രിഫിക്സ് വെർച്വൽ നെറ്റ്വർക്കിനുള്ളിൽ ഒരിക്കലും റൂട്ട് ചെയ്യാവുന്നതായിരിക്കേണ്ടതില്ല, ആപ്ലിക്കേഷന് പ്രോക്സി സെറ്റ് ചെയ്യുന്ന ഹെഡറിൽ ഐഡന്റിറ്റി ലഭിക്കാം.

ആ ഹെഡർ ബാക്ക്എൻഡ് പ്രോക്സിയിൽ നിന്ന് മാത്രം സ്വീകരിക്കുകയും മറ്റൊന്നിൽ നിന്നും സ്വീകരിക്കാതിരിക്കുകയും ചെയ്യുമ്പോൾ മാത്രമാണ് വിശ്വസനീയം. nginx പദങ്ങളിൽ അതിനർത്ഥം വരുന്നതെല്ലാം വിശ്വസിക്കുന്നതിന് പകരം വിശ്വസനീയമായ പങ്കാളിയെ വ്യക്തമായി പേരിടുക എന്നതാണ്:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

ബാക്ക്എൻഡിലേക്ക് നേരിട്ട് എത്താൻ കഴിയുന്ന ഏത് ക്ലയന്റിനും അതേ ഹെഡർ വ്യാജമാക്കാം, അതിനാൽ ബാക്ക്എൻഡ് പ്രോക്സിയിലൂടെയല്ലാതെ എത്താനാകാത്തതായിരിക്കണം. ഇത് ഫയർവാൾ വസ്തുതയാണ്, കോൺഫിഗറേഷൻ അഭിപ്രായമല്ല, സ്നിപ്പെറ്റ് പകർത്തുമ്പോൾ ആളുകൾ ഒഴിവാക്കുന്ന അനുമാനം ഇതാണ്.

റിലേ നിങ്ങൾ എന്ത് വാങ്ങുന്നു എന്നതും മാറ്റുന്നു. ആപ്ലിക്കേഷൻ തലത്തിലുള്ള ഐഡന്റിറ്റിയും അത് ലോഗ് ചെയ്യാനുള്ള സ്വാഭാവിക സ്ഥലവും ലഭിക്കുന്നു; പൊതുത്വം വിട്ടുകൊടുക്കുന്നു, കാരണം ഓരോ പുതിയ പ്രോട്ടോക്കോളിനും സ്വന്തം പ്രോക്സി പിന്തുണ വേണം. HTTP സേവനങ്ങൾക്ക് ഈ വിനിമയം സാധാരണയായി നല്ലതാണ്, HTTP അല്ലാത്ത എന്തിനും സാധാരണയായി അത് ലഭ്യമല്ല.

ഓരോ അതിർത്തിയും എന്ത് കാണുന്നു എന്ന് എഴുതുക

നിങ്ങൾ എന്ത് തിരഞ്ഞെടുത്താലും, ഡിസൈൻ അവലോകനം ഓരോ ഹോപ്പിലും ഉറവിട വിലാസവും തെളിയിക്കാവുന്ന ഐഡന്റിറ്റിയും പേരിടുന്ന ഒരു പട്ടികയോടെ അവസാനിക്കണം. അതില്ലാതെ, ആദ്യ സംഭവം വ്യത്യസ്ത ക്ലയന്റുകളെ വിവരിക്കുന്ന മൂന്ന് ടീമുകളെ സൃഷ്ടിക്കുന്നു.

പിന്നെ തിരഞ്ഞെടുക്കുക. ആപ്ലിക്കേഷന്റെ അധികാരം യഥാർത്ഥത്തിൽ ക്ലയന്റ് വിലാസത്തെ ആശ്രയിക്കുന്നുവെങ്കിൽ, പാത നിങ്ങൾക്ക് ഏൽക്കാനാകുമെങ്കിൽ ഉറവിടം സംരക്ഷിക്കുക. അങ്ങനെയല്ലെങ്കിൽ, ഐഡന്റിറ്റി ബാൻഡിന് പുറത്ത് കൊണ്ടുനടക്കാനാകുമെങ്കിൽ വിവർത്തനം ചെയ്യുക, പ്ലാറ്റ്ഫോം-നിർദ്ദിഷ്ട കൈമാറ്റ ക്രമീകരണങ്ങൾക്ക് AWS കൈമാറ്റ ഇൻസ്റ്റൻസ് മാർഗ്ഗനിർദ്ദേശം ഉപയോഗിക്കുക. സേവനം HTTP സംസാരിക്കുകയും ഐഡന്റിറ്റി വിലാസമാകുന്നത് പൂർണ്ണമായി അവസാനിപ്പിക്കണമെന്ന് ആഗ്രഹിക്കുകയും ചെയ്യുമ്പോൾ റിലേയിലേക്ക് പോകുക.