EC2 Windows: VPN ക്ലയന്റ്, VPN സർവർ അതോ AWS ഗേറ്റ്വേ?
Windows EC2 ഇൻസ്റ്റൻസിന് VPN സോഫ്റ്റ്വെയർ പ്രവർത്തിപ്പിക്കാം, പക്ഷേ ക്ലയന്റ്, സ്വയം നിയന്ത്രിക്കുന്ന സർവർ, AWS ഗേറ്റ്വേ എന്നിവ വ്യത്യസ്ത ഉടമകളുള്ള വ്യത്യസ്ത റോളുകളാണ്.
ഒരു ടീമിന് Windows EC2 ഇൻസ്റ്റൻസിൽ പ്രവർത്തിക്കുന്ന ആപ്പിന് VPN കണക്റ്റിവിറ്റി വേണം, അനുയോജ്യമായ ക്ലയന്റ് സോഫ്റ്റ്വെയർ കണ്ടെത്തി ഇൻസ്റ്റാൾ ചെയ്യുന്നു, എന്നിട്ട് VPCയുടെ ബാക്കി ഭാഗത്തിന് അത് ഉപയോഗിക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ടെന്ന് ചോദിക്കുന്നു. ഇൻസ്റ്റാളേഷൻ വിജയിച്ചു; റോൾ ഒരിക്കലും തീരുമാനിച്ചില്ല. ഗസ്റ്റിനുള്ളിൽ പ്രവർത്തിക്കുന്ന സോഫ്റ്റ്വെയർ മറ്റൊരാളുടെ നെറ്റ്വർക്കിൽ ചേരുന്ന ക്ലയന്റ്, മറ്റ് ക്ലയന്റുകളെ സ്വീകരിക്കുന്ന സർവർ, അല്ലെങ്കിൽ AWS നിയന്ത്രിക്കുന്ന രണ്ട് VPN ഉൽപ്പന്നങ്ങളിൽ ഒന്നുമല്ലാതിരിക്കാം, ഓരോ റോളും നിങ്ങൾക്ക് വ്യത്യസ്ത ജോലി അവശേഷിപ്പിക്കുന്നു.
ലക്ഷണം സാധാരണയായി തെറ്റായ റോൾ
സാധാരണ ലക്ഷണം തെറ്റായ പ്രശ്നം പരിഹരിക്കുന്ന പ്രവർത്തിക്കുന്ന ടണൽ ആണ്. VM-നുള്ളിലെ ക്ലയന്റ് ആ VM-ന് പുറത്തേക്കുള്ള പാത നൽകുന്നു; നിങ്ങളുടെ ലാപ്ടോപ്പിനോ ഓഫീസിനോ മറ്റൊരു സബ്നെറ്റിനോ അകത്തേക്കുള്ള വഴി നൽകുന്നില്ല. VM-നുള്ളിലെ സർവർ മറ്റുള്ളവർക്ക് അകത്തേക്കുള്ള വഴി നൽകുന്നു, പക്ഷേ ഇപ്പോൾ ശ്രോതാവ്, പ്രമാണീകരണം, ഫോർവേഡിംഗ് എന്നിവ നിങ്ങളുടേതാണ്.
നിയന്ത്രിത സേവനങ്ങൾ സേവനത്തിന്റെ പ്രവർത്തനം AWS-ലേക്ക് മാറ്റി രൂപകൽപ്പന നിങ്ങൾക്ക് വിടുന്നു. Site-to-Site VPN ഉപഭോക്തൃ ഗേറ്റ്വേയും AWS ഗേറ്റ്വേയും വഴി നെറ്റ്വർക്കുകൾ ബന്ധിപ്പിക്കുന്നു, Client VPN ദൂരസ്ഥ ഉപകരണങ്ങൾക്ക് നിയന്ത്രിത എൻഡ്പോയിന്റ് നൽകുന്നു. രണ്ട് സന്ദർഭങ്ങളിലും റൂട്ടുകളും അധികാര നിയമങ്ങളും ഐഡന്റിറ്റി ഉറവിടവും നിങ്ങളുടെ കോൺഫിഗറേഷനാണ്, രണ്ട് ഉൽപ്പന്നങ്ങളിൽ ഒന്നും Windows ഗസ്റ്റിനുള്ളിൽ പൊതു ഉപയോഗ ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല.
നാല് രൂപങ്ങൾ സാധ്യമാണ്, എന്ത് എന്തിനോട് ബന്ധിപ്പിക്കുന്നു, പ്രവർത്തന ഭാരം ആര് വഹിക്കുന്നു എന്നിവയുടെ അടിസ്ഥാനത്തിൽ പട്ടിക അവയെ വേർതിരിക്കുന്നു.
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
ഉൽപ്പന്നത്തിന്റെ പേരല്ല, വരി വായിക്കുക: അതേ Windows ഇൻസ്റ്റൻസിനുള്ളിൽ ഏത് സോഫ്റ്റ്വെയർ പ്രവർത്തിക്കുന്നു എന്നതിനെ ആശ്രയിച്ച് അത് രണ്ട് വ്യത്യസ്ത വരികളിൽ ആകാം.
VM-നുള്ളിലെ ക്ലയന്റ്: VM നെറ്റ്വർക്കിൽ ചേരുന്നു
പുറത്തേക്കുള്ള ക്ലയന്റ് എന്തെങ്കിലും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് മുമ്പ് Windows ബിൽഡ്, ആർക്കിടെക്ചർ, ഡ്രൈവർ ആവശ്യകതകൾ പരിശോധിക്കണം. ക്ലയന്റ് ഇൻസ്റ്റൻസിലെ റൂട്ടുകളും DNS-ഉം മാറ്റും, ഇത് അവിടെ ഇതിനകം പ്രവർത്തിക്കുന്ന സേവനങ്ങളെ ബാധിച്ചേക്കാം, ദൂരസ്ഥ അഡ്മിനിസ്ട്രേഷനായി ഉപയോഗിക്കുന്ന പാത ഉൾപ്പെടെ. ക്ലയന്റ് സജ്ജീകരിക്കുന്ന അഡാപ്റ്റർ നാമവും ഇന്റർഫേസ് മെട്രിക്കും രേഖപ്പെടുത്തുക, കാരണം പുതിയ ഇന്റർഫേസിന് നിലവിലുള്ളതിനേക്കാൾ മുൻഗണന ലഭിച്ചേക്കാം. SSH അല്ലെങ്കിൽ RDP-യ്ക്ക് പകരം സെഷൻ മാനേജർ വഴി ഇൻസ്റ്റൻസ് നിയന്ത്രിക്കുന്നുവെങ്കിൽ, ക്ലയന്റ് ബന്ധിപ്പിച്ചതിന് ശേഷവും ആ പാത പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.
ക്ലയന്റ് പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുമ്പ് അത് ഏത് ട്രാഫിക് വഹിക്കണമെന്ന് തീരുമാനിക്കുക. പൂർണ്ണ ടണൽ അഡ്മിനിസ്ട്രേഷൻ സെഷൻ പിടിച്ചെടുത്ത് നിങ്ങളെ പുറത്ത് പൂട്ടിയേക്കാം, വിഭജിത ടണൽ ഇൻസ്റ്റൻസിനെ സ്വകാര്യ നെറ്റ്വർക്കിൽ എത്തിക്കുമ്പോൾ അതിന്റെ മറ്റ് ട്രാഫിക് മറ്റൊരു എക്സിറ്റ് എടുക്കുന്നു. രണ്ടാമതൊരു അഡ്മിനിസ്ട്രേഷൻ പാത ലഭ്യമാക്കി പരീക്ഷിക്കുക, ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യുന്ന റൂട്ടുകൾ രേഖപ്പെടുത്തുക, അങ്ങനെ പിന്നീടുള്ള മാറ്റം വിശദീകരിക്കാനാകും.
VM-നുള്ളിലെ സർവർ: മറ്റ് ക്ലയന്റുകൾ അതിൽ ചേരുന്നു
സ്വയം നിയന്ത്രിക്കുന്ന സർവറിൽ ശ്രോതാവ്, സർട്ടിഫിക്കറ്റ് അല്ലെങ്കിൽ കീ മെറ്റീരിയൽ, ഉപയോക്തൃ ഡാറ്റാബേസ്, ഫോർവേഡിംഗ് നിയമങ്ങൾ എന്നിവ നിങ്ങളുടേതാണ്. സർവർ മറ്റ് ക്ലയന്റുകൾക്കായി ട്രാഫിക് ഫോർവേഡ് ചെയ്യുന്നുവെങ്കിൽ, ഇൻസ്റ്റൻസ് ഒരു റൂട്ടർ ആകുന്നു, അതിന് ഗസ്റ്റ് തലത്തിലുള്ള ഫോർവേഡിംഗും AWS തലത്തിലുള്ള റൂട്ട്, സെക്യൂരിറ്റി ഗ്രൂപ്പ് മാറ്റങ്ങളും ആവശ്യമാണ്.
ഗസ്റ്റിൽ നിന്ന് ശ്രോതാവ് പരിശോധിക്കുക, വീണ്ടും മറ്റൊരു സബ്നെറ്റിൽ നിന്ന്, തുടർന്ന് ഇൻസ്റ്റൻസ് ഫോർവേഡ് ചെയ്യുന്ന ഹോസ്റ്റ് പരിശോധിക്കുക. ആരോഗ്യകരമായ പ്രാദേശിക സേവനം ഫോർവേഡ് ചെയ്ത പാതയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, അതിനാൽ രണ്ട് ഫലങ്ങളും മാറ്റക്കുറിപ്പിൽ രേഖപ്പെടുത്തുക.
നിയന്ത്രിത ഗേറ്റ്വേകൾ സേവനം നിലനിർത്തുന്നു, നിങ്ങളുടെ ആക്സസ് രൂപകൽപ്പനയല്ല
AWS Site-to-Site VPN ഉപഭോക്തൃ-ഗേറ്റ്വേ, AWS-ഗേറ്റ്വേ ടണൽ റോളുകൾ രേഖപ്പെടുത്തുന്നു, ആ കണക്ഷൻ വാങ്ങുന്നത് ഓരോ ദൂരസ്ഥ-ആക്സസ് രൂപകൽപ്പനയെയും മാറ്റിസ്ഥാപിക്കുന്നില്ല. Client VPN ക്ലയന്റ് പേഴ്സോണകളോടുകൂടിയ നിയന്ത്രിത എൻഡ്പോയിന്റ് രേഖപ്പെടുത്തുന്നു, അധികാര നിയമങ്ങളും ലക്ഷ്യ റൂട്ടുകളും നിങ്ങളുടേതായി തുടരുന്നു. AWS എൻഡ്പോയിന്റും അതിന്റെ സർട്ടിഫിക്കറ്റുകളും പ്രവർത്തിപ്പിക്കുന്നു; ആർക്ക് ഏത് ആപ്പിൽ എത്താം എന്നത് ഇപ്പോഴും നിങ്ങൾ എഴുതി പരിപാലിക്കുന്ന അധികാര നിയമമാണ്.
അഞ്ച് അക്ഷങ്ങളിൽ ഉൽപ്പന്നങ്ങളിൽ നിന്ന് തിരഞ്ഞെടുക്കുക: ഓരോന്നും ഏത് റോൾ വഹിക്കുന്നു, ഏത് പ്രോട്ടോക്കോളുകൾ സ്വീകരിക്കുന്നു, ഏത് ഐഡന്റിറ്റി ഉറവിടം പ്രതീക്ഷിക്കുന്നു, ട്രാഫിക് എങ്ങനെ ഫോർവേഡ് ചെയ്യുന്നു, ലഭ്യത എങ്ങനെ നൽകുന്നു. ഫോറം ത്രെഡിൽ ഉദ്ധരിച്ച ഏതെങ്കിലും ഒറ്റ ത്രൂപുട്ട് സംഖ്യ അവഗണിക്കുക, കാരണം പ്രസിദ്ധീകരിച്ച ശേഷി സേവനത്തോടൊപ്പം മാറുന്നു. നിയന്ത്രിത ടണൽ ജോടി ഏതെങ്കിലും ഏകപക്ഷീയ ഗസ്റ്റ് ക്ലയന്റിന്റെ സ്വഭാവം മാറ്റുമെന്ന് കരുതരുത്.
ഉൽപ്പന്നത്തിന് മുമ്പ് റോൾ തിരഞ്ഞെടുക്കുക
ദിശ പേരിടുന്ന ഒരു വാക്യം എഴുതുക: ഈ VM ഒരു നെറ്റ്വർക്കിൽ ചേരുന്നു, ഈ VM ക്ലയന്റുകളെ സ്വീകരിക്കുന്നു, അല്ലെങ്കിൽ ഒരു AWS ഗേറ്റ്വേ നിർവചിച്ച നെറ്റ്വർക്കുകൾ ബന്ധിപ്പിക്കുന്നു.
ആ വാക്യമാണ് ഉൽപ്പന്നങ്ങളുടെ ചെറിയ പട്ടിക, സോഫ്റ്റ്വെയറിന്റെ ഉടമ, നിങ്ങൾ ഡീബഗ് ചെയ്യാൻ പോകുന്ന പരാജയ മാതൃകകൾ എന്നിവ തീരുമാനിക്കുന്നത്. ആവശ്യകത ദൂരസ്ഥ ഉപയോക്താക്കൾ ഒരു ആപ്പിൽ എത്തുകയാണെങ്കിൽ, ആപ്പിന്റെ VM-ൽ ഇൻസ്റ്റാൾ ചെയ്ത ക്ലയന്റ് തെറ്റായ രൂപമാണ്. ആവശ്യകത ഒരു VM പങ്കാളി നെറ്റ്വർക്കിൽ എത്തുകയാണെങ്കിൽ, നിയന്ത്രിത സൈറ്റ്-ടു-സൈറ്റ് ഗേറ്റ്വേ ജോലിക്ക് ആവശ്യമുള്ളതിനേക്കാൾ കൂടുതൽ യന്ത്രമാണ്. രണ്ട് ഉത്തരങ്ങളും സാധുവാണ്; അവയിൽ ഒന്ന് മാത്രം നിങ്ങൾ എഴുതിയ വാക്യവുമായി യോജിക്കുന്നു.