EC2 നിങ്ങളുടെ AWS Client VPN ലാപ്‌ടോപ്പിൽ എത്താൻ കഴിയാത്തത് എന്തുകൊണ്ട്
Client VPN IPv4 ക്ലയന്റ് ഉറവിടങ്ങളെ endpoint-ന്റെ ഇന്റർഫേസിലേക്ക് വിവർത്തനം ചെയ്യുന്നു. അതുകൊണ്ടാണ് മറുപടി പ്രവർത്തിക്കുന്നത്, EC2-ൽ നിന്നുള്ള പുതിയ കണക്ഷൻ പ്രവർത്തിക്കാത്തത്.
AWS Client VPN വഴി ബന്ധിപ്പിച്ച ലാപ്‌ടോപ്പ് EC2 ആപ്ലിക്കേഷനിൽ യാതൊരു ബുദ്ധിമുട്ടും കൂടാതെ എത്തുന്നു. തുടർന്ന് നിങ്ങൾ വിപരീതം പരീക്ഷിക്കുന്നു, EC2-ൽ നിന്ന് ക്ലയന്റിന് നൽകിയ വിലാസത്തിലേക്ക്, കണക്ഷൻ തൂങ്ങിക്കിടക്കുകയോ നിരസിക്കപ്പെടുകയോ ചെയ്യുന്നു. ഈ അസമത്വം അപൂർവ്വമായി കാണാതായ സുരക്ഷാ ഗ്രൂപ്പ് നിയമമായിരിക്കും. VPC സബ്നെറ്റുകളുമായി ബന്ധിപ്പിച്ച Client VPN endpoint-ൽ AWS IPv4 ക്ലയന്റ് ഉറവിടങ്ങളെ endpoint-ന്റെ നെറ്റ്‌വർക്ക് ഇന്റർഫേസിലേക്ക് വിവർത്തനം ചെയ്യുന്നു, അതിനാൽ നിങ്ങളുടെ ലാപ്‌ടോപ്പിനെ പ്രതിനിധീകരിക്കുന്ന ഇൻബൗണ്ട് VPC വിലാസം ഇല്ല.
ക്യാപ്ചർ കാണിക്കുന്നതിൽ നിന്ന് തുടങ്ങുക
ക്ലയന്റ് ബന്ധിപ്പിക്കുന്ന സമയത്ത് EC2 ഹോസ്റ്റിൽ ക്യാപ്ചർ എടുത്ത് ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ കാണുന്ന ഉറവിട വിലാസം വായിക്കുക. അത് ക്ലയന്റ് പൂളിലെ വിലാസമല്ലാതെ VPC വശത്തെ endpoint ഇന്റർഫേസ് ആണെങ്കിൽ, ഒരു നിയമം പോലും മാറ്റുന്നതിന് മുൻപേ വിവർത്തനം സ്ഥിരീകരിക്കപ്പെട്ടു.
ക്ലയന്റ് പൂൾ ഒരു അനുവദന ശ്രേണിയാണ്, തിരിച്ചുള്ള റൂട്ടുള്ള സബ്നെറ്റല്ല. ഈ വ്യത്യാസത്തിലാണ് ഇത്തരം അന്വേഷണങ്ങളിൽ ഭൂരിഭാഗവും പിഴയ്ക്കുന്നത്.
അസമത്വം വിശദീകരിക്കുന്ന വിവർത്തനം
മൂന്ന് ഫ്ലോകൾ പരസ്പരം കൂട്ടിക്കലർത്തപ്പെടുന്നു, അവയിൽ ആളുകൾ പരീക്ഷിക്കുന്ന ഒന്ന് മാത്രമാണ്.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN ഘടകങ്ങളുടെ വിവരണം IPv4 ക്ലയന്റ് ഉറവിടങ്ങൾ endpoint ഇന്റർഫേസിലേക്ക് വിവർത്തനം ചെയ്യപ്പെടുന്നു എന്ന് വ്യക്തമാക്കുന്നു, മധ്യ നിരയ്ക്ക് ഒത്തുനോക്കാൻ ഒന്നുമില്ലാത്തത് എന്തുകൊണ്ടെന്ന് കാണാൻ അത് മതി.
പുതിയ കണക്ഷന് ഒരു റൂട്ട്, വിലാസ പരിഹാര ഘട്ടം, അനുമതി തീരുമാനം എന്നിവ വേണം. മറ്റൊരാളുടെ സെഷനിൽ നിന്നുള്ള വിവർത്തന അവസ്ഥ ഇവ മൂന്നിൽ ഒന്നും നൽകുന്നില്ല.
മറുപടി പുതിയ കണക്ഷൻ ആകാത്തത് എന്തുകൊണ്ട്
TCP മറുപടി നിലവിലുള്ള എൻട്രിയുമായി ഒത്തുനോക്കപ്പെടുന്നു, അതുകൊണ്ടാണ് ഇൻബൗണ്ട് നിയമമില്ലാതെ തന്നെ തിരിച്ചുള്ള പാത പ്രവർത്തിക്കുന്നത്. EC2 ഹോസ്റ്റിൽ നിന്നുള്ള പുതിയ SYN-ന് ഒത്തുനോക്കാൻ എൻട്രിയില്ല, അതിനാൽ VPC-യ്ക്ക് എങ്ങനെ എത്തണമെന്ന് അറിയാത്ത ലക്ഷ്യത്തിലേക്കുള്ള സാധാരണ ഔട്ട്ബൗണ്ട് ശ്രമമായി അത് മാറുന്നു.
അതുകൊണ്ടുതന്നെ ഇതിനെ ഒരു ദിശയിൽ മാത്രം പോകുന്ന ട്രാഫിക്കെന്ന് വിവരിക്കുന്നത് തെറ്റിദ്ധരിപ്പിക്കുന്നതാണ്. ഈ സെഷനുകളിൽ തിരിച്ചുള്ള ട്രാഫിക് തുടർച്ചയായി ഒഴുകുന്നു. പാതയില്ലാത്ത ഭാഗം തുടക്കമാണ്.
പ്രവർത്തിക്കേണ്ട സെഷൻ ഇപ്പോഴും തകർക്കുന്നത് എന്ത്
സുരക്ഷാ ഗ്രൂപ്പുകൾ, നെറ്റ്‌വർക്ക് ACL-കൾ, ലാപ്‌ടോപ്പിന്റെ സ്വന്തം ഫയർവാൾ എന്നിവ വിജയിക്കേണ്ട കണക്ഷനുകൾക്ക് പ്രധാനമാണ്. പരാജയപ്പെട്ട ping ഏറ്റവും കുറച്ച് പറയുന്നു, കാരണം ICMP നയം പലപ്പോഴും നിങ്ങൾക്ക് പ്രധാനമായ TCP നയത്തിൽ നിന്ന് വേറിട്ടതാണ്.
ഈ നിയമങ്ങൾ വിവർത്തനം ചെയ്ത ഉറവിടത്തിനനുസരിച്ച് എഴുതുക, ക്ലയന്റ് വിലാസത്തിനനുസരിച്ചല്ല. നെറ്റ്‌വർക്കിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടാത്ത വിലാസത്തിൽ ബന്ധിച്ച നിയമങ്ങളാണ് ഈ രൂപകൽപ്പനയിലെ ഏറ്റവും സാധാരണ സ്വയം വരുത്തിയ പരാജയം.
VPC യഥാർത്ഥത്തിൽ സംഭാഷണം തുടങ്ങേണ്ടിവരുമ്പോൾ
ഒരു സേവനം ഒരു വർക്ക്‌സ്റ്റേഷനെ അറിയിക്കേണ്ടതുണ്ടെങ്കിൽ, ദിശ തിരിച്ചിടുക, സേവനം മറുപടി നൽകുന്ന സ്ഥിരമായ ഔട്ട്ബൗണ്ട് ചാനൽ ക്ലയന്റിന് സൂക്ഷിക്കാൻ അനുവദിക്കുക. ഒരു മുഴുവൻ ദൂര നെറ്റ്‌വർക്കും VPC-യിൽ നിന്ന് എത്താവുന്നതായിരിക്കണമെങ്കിൽ, Client VPN ഇത് ഇതിനകം ചെയ്യുന്നു എന്ന് അനുമാനിക്കുന്നതിനുപകരം അതിന്റെ പ്രിഫിക്സുകളും ആക്സസ് നയവും പ്രസിദ്ധീകരിക്കുന്ന ഒരു ആർക്കിടെക്ചർ തിരഞ്ഞെടുക്കുക. ക്ലയന്റ്-ടു-ക്ലയന്റ് ആക്സസ് മൂന്നാമത്തെ, ഇടുങ്ങിയ കേസാണ്, അതിന് സ്വന്തം റൂട്ട്, അനുമതി ഒബ്ജക്റ്റുകൾ ഉണ്ട്. ഇവയൊന്നും നിലവിലുള്ള endpoint-ലെ ഒരു ചെക്ക്ബോക്സ് മാത്രമല്ല.
IPv4 വിശദീകരണത്തിന്റെ പരിധിയും സത്യസന്ധമായി നിലനിർത്തുക. നിലവിലെ AWS ഡോക്യുമെന്റേഷൻ IPv6-നെ വേർതിരിക്കുന്നു, അവിടെ ആ വിവർത്തനം ബാധകമല്ല, കൂടാതെ വ്യത്യസ്തമായി റൂട്ട് ചെയ്യുന്ന മറ്റ് കണക്ഷൻ മോഡലുകളും.
മൂന്ന് ലേബൽ ചെയ്ത ഘട്ടങ്ങളിൽ പരീക്ഷിക്കുക: ക്ലയന്റ് അനുവദിച്ച സെഷൻ തുറക്കുന്നു, VPC സേവനം ആ സെഷന് മറുപടി നൽകുന്നു, ഒരു VPC ഹോസ്റ്റ് ക്ലയന്റിലേക്ക് പുതിയ സെഷൻ തുറക്കുന്നു. ആദ്യ രണ്ടെണ്ണം വിജയിക്കുകയും മൂന്നാമത്തേത് പരാജയപ്പെടുകയും ചെയ്യുന്നത് ഈ രൂപകൽപ്പനയുടെ പ്രതീക്ഷിത രൂപമാണ്, ഫയർവാൾ നിയമങ്ങളാൽ പിന്തുടരേണ്ട ന്യൂനതയല്ല.