EC2 Elastic IP ഇൻസ്റ്റൻസിന്റെ സ്വകാര്യ VPN വിലാസമല്ല

ഇൻസ്റ്റൻസിന് ഒരു സ്വകാര്യ വിലാസമുണ്ട്, Elastic IP അതുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, ആ പൊതു /32-നുള്ള ഒരു റൂട്ട് VPN-ലേക്ക് ചേർക്കുന്നു, രണ്ടും ഒരേ കാര്യമാകുമെന്ന പ്രതീക്ഷയിൽ. ആകുന്നില്ല. Elastic IP എന്നത് അതിഥിക്ക് പുറത്ത്, ഇന്റർനെറ്റ് ഗേറ്റ്വേ നടത്തുന്ന, ഇന്റർനെറ്റ് പാത സ്വീകരിക്കുന്ന ട്രാഫിക്കിൽ ചെയ്യുന്ന ഒരു വിവർത്തനമാണ്. അതിഥിയുടെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ആ വിലാസം ഒരു ഇന്റർഫേസിൽ കോൺഫിഗർ ചെയ്തതായി ഒരിക്കലും കാണുന്നില്ല. അത് ഒരു ടണൽ ഇന്റർഫേസിൽ ചേർക്കുന്നത് മുകളിലെ വിവർത്തനം പുനർനിർമ്മിക്കുന്നില്ല, ഒരേ യന്ത്രത്തിന് രണ്ടാമത്തെ, വൈരുദ്ധ്യാപരമായ ഐഡന്റിറ്റി സൃഷ്ടിക്കുന്നു.

രണ്ട് വിലാസങ്ങൾ, ഒരു ഇൻസ്റ്റൻസ്

ഇൻസ്റ്റൻസിന്റെ നെറ്റ്വർക്ക് ഇന്റർഫേസ് VPC-യ്ക്കുള്ളിൽ ഒരു സ്വകാര്യ വിലാസം സൂക്ഷിക്കുന്നു, അതാണ് അതിഥി അറിയുന്ന വിലാസം. Elastic IP അതേ ഇന്റർഫേസുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, പക്ഷേ മാപ്പിംഗിന്റെ പൊതു വശത്താണ് ജീവിക്കുന്നത്.

ഇന്റർനെറ്റിലൂടെ ഇൻസ്റ്റൻസിലെത്തുന്ന എല്ലാം സ്വകാര്യ വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്താണ് എത്തുന്നത്. ഇൻസ്റ്റൻസ് ഇന്റർനെറ്റിലേക്ക് അയക്കുന്ന എല്ലാം Elastic IP ഉറവിടമായി പുറപ്പെടുന്നു, വീണ്ടും ആ വിവർത്തനം കാരണം.

അതിഥിക്കുള്ളിൽ ഒരു വിലാസമുണ്ട്. പുറത്ത് രണ്ടെണ്ണമുണ്ട്. ഈ അസമത്വമാണ് ഈ മേഖലയിലെ മിക്ക ആശയക്കുഴപ്പവും വിശദീകരിക്കുന്നത്. ഗേറ്റ്വേ എന്താണ് വിവർത്തനം ചെയ്യുന്നതെന്ന് അതിഥിക്ക് കോൺഫിഗർ ചെയ്യാനാകില്ല. അതിന് യഥാർത്ഥത്തിൽ ഉള്ള വിലാസത്തിൽ മാത്രമേ ഉത്തരം നൽകാനാകൂ.

ഇന്റർനെറ്റ് ഗേറ്റ്വേ യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു

AWS-ന്റെ ഇന്റർനെറ്റ് ഗേറ്റ്വേ ഡോക്യുമെന്റേഷൻ ഈ ക്രമീകരണം വിവരിക്കുന്നു: ഇൻസ്റ്റൻസിന് അതിന്റെ സ്വകാര്യ IPv4 വിലാസം അറിയാം, ഇന്റർനെറ്റ് പാതയിലെ ട്രാഫിക്കിന് ഗേറ്റ്വേ അനുബന്ധ പൊതു IPv4 അല്ലെങ്കിൽ Elastic IP വിവർത്തനം നൽകുന്നു.

ഇത് നെറ്റ്വർക്ക് വിലാസ വിവർത്തനമാണ്, ഒരു അപരനാമമല്ല. ഗേറ്റ്വേയാണ് മാപ്പിംഗ് പരിപാലിക്കുന്നത്, അത് അസോസിയേഷനുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, അതിലൂടെ കടന്നുപോകുന്ന പാക്കറ്റുകൾക്ക് മാത്രമേ ബാധകമാകൂ. അസോസിയേഷൻ നീക്കം ചെയ്താൽ, അതിഥി ഒന്നും അറിയാതെ തന്നെ പൊതു ഐഡന്റിറ്റി അപ്രത്യക്ഷമാകും.

അതുകൊണ്ടാണ് പൊതു /32-ലേക്ക് അഡ്രസ് ചെയ്ത സ്വകാര്യ VPN പാക്കറ്റ് അതിഥിയുടെ പ്രാദേശിക വിലാസത്തിലേക്കുള്ള സ്വകാര്യ പാക്കറ്റായി വീണ്ടും വ്യാഖ്യാനിക്കാത്തത്. പാക്കറ്റ് യോജിക്കുന്ന റൂട്ട് പിന്തുടരുന്നു, അത് അതിനെ ഇന്റർനെറ്റ് ഗേറ്റ്വേയിലേക്ക് അയക്കുന്നു, ഗേറ്റ്വേയുടെ പെരുമാറ്റം പാത രണ്ട് ദിശകളിലും അനുവദനീയമാണോ എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

ടണൽ ഇന്റർഫേസ് തന്ത്രം പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്

Elastic IP ഒരു ടണൽ ഇന്റർഫേസിന് നൽകുന്നത് പൊതു വിലാസത്തെ പ്രാദേശികമായി കാണാൻ അതിഥിയോട് ആവശ്യപ്പെടുന്നു. ഇപ്പോൾ രണ്ട് കാര്യങ്ങൾ ഒരേ വിലാസം അവകാശപ്പെടുന്നു: ഇന്റർനെറ്റ് പാതയിലെ ഗേറ്റ്വേ വിവർത്തനവും ടണലിനുള്ളിലെ പ്രാദേശിക ഇന്റർഫേസും. ഏതാണ് ബാധകമെന്നതിന് മടങ്ങിവരുന്ന ട്രാഫിക്കിന് സ്ഥിരമായ ഉത്തരമില്ല.

പ്രവർത്തിക്കുന്നതായി തോന്നുമ്പോഴും, യഥാർത്ഥ ചോദ്യം ഡിസൈൻ മറച്ചുവെച്ചിട്ടുണ്ട്. ക്ലയന്റുകൾ ടണലിലൂടെ സ്വകാര്യ വിലാസത്തിലോ ഇന്റർനെറ്റിലൂടെ പൊതു എൻഡ്പോയിന്റിലോ എത്തുന്നു, ഈ രണ്ട് പാതകൾക്ക് വ്യത്യസ്ത സെക്യൂരിറ്റി ഗ്രൂപ്പുകളും വ്യത്യസ്ത ലോഗിംഗും വ്യത്യസ്ത പരാജയ മാതൃകകളുമുണ്ട്.

വിലാസമായിരുന്നില്ല ഒരിക്കലും പ്രശ്നം. പാതയുടെ തിരഞ്ഞെടുപ്പായിരുന്നു.

മൂന്ന് ലക്ഷ്യങ്ങൾ, മൂന്ന് ഡിസൈനുകൾ

ലക്ഷ്യം ഒരു പൊതു VPN എൻഡ്പോയിന്റാണെങ്കിൽ, Elastic IP ആണ് ശരിയായ ഉപകരണം: ദൂരസ്ഥരായ പിയർമാർ ഇന്റർനെറ്റിലൂടെ അതിലേക്ക് ബന്ധിപ്പിക്കുന്നു, എൻക്രിപ്റ്റ് ചെയ്ത ട്രാൻസ്പോർട്ട് ഇൻസ്റ്റൻസിൽ അവസാനിക്കുന്നു. തുടർന്ന് ആന്തരിക ആപ്ലിക്കേഷൻ ട്രാഫിക് സ്വകാര്യ വിലാസം ഉപയോഗിക്കുന്നു.

ലക്ഷ്യം ആപ്ലിക്കേഷനിലേക്കുള്ള സ്വകാര്യ പ്രവേശനമാണെങ്കിൽ, ലക്ഷ്യം സ്വകാര്യ വിലാസമോ അതിലേക്ക് റിസോൾവ് ചെയ്യുന്ന സ്വകാര്യ DNS നാമമോ ആണ്, VPN റൂട്ടും സെക്യൂരിറ്റി ഗ്രൂപ്പും മടങ്ങിവരുന്ന പാതയും എല്ലാം യോജിക്കണം. ആ ഡിസൈനിൽ Elastic IP ഒട്ടും പ്രത്യക്ഷപ്പെടുന്നില്ല.

ലക്ഷ്യം VPN ഉപയോക്താക്കൾക്കുള്ള സ്ഥിരമായ പൊതു എഗ്രെസ് ഐഡന്റിറ്റിയാണെങ്കിൽ, അത് എഗ്രെസ് വശത്തുള്ള ഒരു NAT ഡിസൈനാണ്, ക്ലയന്റിന്റെ ടണലിലെ വിലാസമല്ല. സമാനമായി കേൾക്കുന്ന മൂന്ന് ലക്ഷ്യങ്ങൾ മൂന്ന് വ്യത്യസ്ത ഡയഗ്രമുകൾ നൽകുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് Elastic IP ഒരു പുതിയ സ്ഥലത്ത് വയ്ക്കുന്നത് ഉൾക്കൊള്ളുന്നത്.

നിങ്ങൾ തിരഞ്ഞെടുത്ത പാത പരിശോധിക്കുക

സ്വകാര്യ പ്രവേശനത്തിന്, VPN റൂട്ട് സ്വകാര്യ പ്രിഫിക്സ് ഉൾക്കൊള്ളുന്നുവെന്നും, VPC റൂട്ട് ടേബിൾ ട്രാഫിക് ടണലിലേക്ക് തിരികെ അയക്കുന്നുവെന്നും, സെക്യൂരിറ്റി ഗ്രൂപ്പ് ക്ലയന്റിന്റെ ഉറവിടം അനുവദിക്കുന്നുവെന്നും, ക്ലയന്റിന്റെ സ്വന്തം ഫയർവാൾ മറുപടി അനുവദിക്കുന്നുവെന്നും ഉറപ്പാക്കുക. തുടർന്ന് ping-ന് പകരം ഒരു യഥാർത്ഥ അഭ്യർത്ഥന പരീക്ഷിക്കുക.

പൊതു പ്രവേശനത്തിന്, ക്ലയന്റിന്റെ ഇന്റർനെറ്റ് എഗ്രെസ്, പൊതു പ്രവേശനത്തിന്റെ റൂട്ടിംഗ്, അതിന്റെ സെക്യൂരിറ്റി പോളിസി എന്നിവ ഉറപ്പാക്കുക. VPN ക്ലയന്റിന് ടണലിലൂടെ പൊതു എൻഡ്പോയിന്റിലേക്ക് എത്താനാകുമോ എന്നത് ടണലിന്റെ എഗ്രെസ്, ഫയർവാൾ നിയമങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു, Elastic IP അസോസിയേഷനെയല്ല.

പൊതു ഹോസ്റ്റ്നെയിം ഇരുവശത്തുനിന്നും പ്രവർത്തിക്കേണ്ടതുണ്ടെങ്കിൽ, VPN ക്ലയന്റുകൾക്ക് സ്വകാര്യ വിലാസവും മറ്റെല്ലാവർക്കും പൊതു വിലാസവും നൽകി ഉത്തരം നൽകുന്ന DNS ഡിസൈൻ ഉപയോഗിക്കുക, സർട്ടിഫിക്കറ്റ് വിലാസത്തിനല്ല പേരിന് സാധുവായി സൂക്ഷിക്കുക. ജോലിയുടെ ക്രമം: ലക്ഷ്യത്തിന് പേര് നൽകുക, അതിന് അർഹമായ വിലാസം തിരഞ്ഞെടുക്കുക, തുടർന്ന് പാതകളും പോളിസിയും ഒരു അഭ്യർത്ഥനയും പരിശോധിക്കുക.