ഒരു AWS Client VPN സെഷനു പിന്നിലെ LAN: എന്താണ് ഫോർവേഡ് ചെയ്യപ്പെടുന്നത്

ഹോസ്റ്റിൽ പ്രവർത്തിക്കുന്ന സെഷൻ സ്വയം LAN-ലേക്ക് വ്യാപിക്കുന്നില്ല. ക്ലയന്റ് പിന്തുണ, ഫോർവേഡിംഗ്, വിവർത്തനം, മറുപടി പാത എന്നീ ക്രമത്തിൽ പരിശോധിക്കുക.

ലാപ്‌ടോപ്പ് AWS Client VPN എൻഡ്‌പോയിന്റിലേക്ക് കണക്റ്റ് ചെയ്യുന്നു, സ്വകാര്യ സബ്‌നെറ്റിൽ എത്തുന്നു, എല്ലാം ആരോഗ്യകരമായി തോന്നുന്നു. അതേ LAN-ലെ ഡെസ്‌ക്ടോപ്പിന് എവിടെയും എത്താനാവുന്നില്ല, എന്നിരുന്നാലും Linux ഹോസ്റ്റിനും ബ്രിഡ്ജ് ഇന്റർഫേസുണ്ട്, രണ്ട് മെഷീനുകളും ഒരേ വയറിലാണ്. ടണലിൽ ഒന്നും തെറ്റായി കോൺഫിഗർ ചെയ്തിട്ടില്ല; കാണാത്ത ഭാഗം റൂട്ടിംഗ് ആണ്, ബ്രിഡ്ജ് തെറ്റായ സൂചനയാണ്.

Client VPN സെഷൻ LAN-ലേക്ക് വ്യാപിപ്പിക്കുന്നത് ഗേറ്റ്‌വേ റോളാണ്. ഇത് മാനേജ്ഡ് സേവനത്തിലേക്ക് നീട്ടിയ Ethernet സെഗ്‌മെന്റല്ല.

ഹോസ്റ്റ് പ്രവർത്തിക്കുന്നു, LAN പ്രവർത്തിക്കുന്നില്ല

Linux മെഷീനിലെ ടണൽ ഇന്റർഫേസിന് Client VPN ക്ലയന്റ് CIDR-നുള്ളിൽ വിലാസമുണ്ട്, എൻഡ്‌പോയിന്റ് VPC ശ്രേണികൾക്കായി റൂട്ടുകൾ പുഷ് ചെയ്തു. ആ മെഷീനിൽ നടത്തുന്ന അഭ്യർത്ഥന പ്രാദേശികമായി സൃഷ്ടിച്ച ട്രാഫിക്കാണ്: അത് ഒരു റൂട്ട് തിരഞ്ഞെടുക്കുന്നു, ടണലിലൂടെ പുറത്തുപോകുന്നു, മറുപടി ലഭിക്കുന്നു. ആ പാത ഒരിക്കലും ഫോർവേഡിംഗ് കോഡ്, LAN ഇന്റർഫേസ്, ട്രാൻസിറ്റ് നിയന്ത്രിക്കുന്ന ഏതെങ്കിലും ഫയർവാൾ നിയമം എന്നിവയെ സ്പർശിക്കുന്നില്ല.

മറ്റൊരു LAN ഉപകരണത്തിൽ നിന്നുള്ള ട്രാഫിക് വ്യത്യസ്തമായ പ്രവാഹമാണ്. അത് LAN ഇന്റർഫേസിൽ എത്തുന്നു, ടണലിലേക്ക് ചൂണ്ടുന്ന റൂട്ട് വേണം, ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാക്കണം, അത് അനുവദിക്കുന്ന ഫയർവാൾ വേണം, മറുപടി അതേ ഹോസ്റ്റിലൂടെ തിരികെ വരണം. നാല് വ്യവസ്ഥകൾ, പ്രവർത്തിക്കുന്ന ലാപ്‌ടോപ്പ് പരിശോധന അവയൊന്നും തെളിയിക്കുന്നില്ല. ഡെസ്‌ക്ടോപ്പിൽ നിന്ന് പരാജയം വിചിത്രമായി തോന്നുന്നു: ടണൽ ഓണാണ്, ക്രെഡൻഷ്യലുകൾ സാധുവാണ്, ലക്ഷ്യം ഒരിക്കലും മറുപടി നൽകുന്നില്ല. കുറ്റം ഗേറ്റ്‌വേയുടെ ഫോർവേഡിംഗ് പാതയിൽ പ്രാദേശികമാണ്, സേവനത്തിലല്ല.

എല്ലാ ക്ലയന്റിനും ഗേറ്റ്‌വേ ആകാനാവില്ല

AWS പറയുന്നത് അവരുടെ Client VPN ഡെസ്‌ക്ടോപ്പ് ആപ്പ് IP ഫോർവേഡിംഗിനെ പിന്തുണയ്ക്കുന്നില്ലെന്നും മറ്റ് ക്ലയന്റുകൾ പിന്തുണയ്ക്കാമെന്നും ആണ്. ആ നിയന്ത്രണം ഏതെങ്കിലും കമാൻഡ് ടൈപ്പ് ചെയ്യുന്നതിന് മുൻപേ ആർക്കിടെക്ചർ തീരുമാനിക്കുന്നു. ലഭ്യമായ ഒരേയൊരു ക്ലയന്റ് ഔദ്യോഗിക ഡെസ്‌ക്ടോപ്പ് ആപ്പ് ആണെങ്കിൽ, LAN-നുവേണ്ടി ഫോർവേഡ് ചെയ്യുന്ന Linux ഗേറ്റ്‌വേ നിങ്ങൾക്ക് പൂർത്തിയാക്കാവുന്ന ക്രമീകരണമല്ല, എത്ര masquerading ചെയ്താലും അത് മാറില്ല.

പകരം വരുന്ന ക്ലയന്റ് എൻഡ്‌പോയിന്റിന്റെ പ്രാമാണീകരണ രീതിയോടും നിങ്ങൾ നടപ്പാക്കാൻ ഉദ്ദേശിക്കുന്ന നയത്തോടും പൊരുത്തപ്പെടണം. സർട്ടിഫിക്കറ്റ് അടിസ്ഥാനമാക്കിയ, ഡയറക്ടറി അടിസ്ഥാനമാക്കിയ, SAML അടിസ്ഥാനമാക്കിയ എൻഡ്‌പോയിന്റുകൾ ഒരേ ക്ലയന്റ് കോൺഫിഗറേഷനുകൾ സ്വീകരിക്കുന്നില്ല, പ്രാമാണീകരിക്കുന്നുവെങ്കിലും പുഷ് ചെയ്ത റൂട്ടുകൾ അവഗണിക്കുന്ന മൂന്നാം കക്ഷി ക്ലയന്റ് മെച്ചപ്പെടുത്തലല്ല.

ക്ലയന്റ് തിരഞ്ഞെടുപ്പിനെ ഡിസൈൻ അവലോകനത്തിന്റെ ഭാഗമായി കാണുക. LAN ഫോർവേഡിംഗ് പാറ്റേൺ ആകെ ലഭ്യമാണോ എന്നും, ഗേറ്റ്‌വേയ്ക്ക് പിന്നിലെ ഓരോ ഉപകരണത്തിനും എൻഡ്‌പോയിന്റ് ഏത് ഐഡന്റിറ്റി കാണുന്നു എന്നും അത് തീരുമാനിക്കുന്നു. ക്ലയന്റും അത് പരീക്ഷിച്ച എൻഡ്‌പോയിന്റ് കോൺഫിഗറേഷനും രേഖപ്പെടുത്തുക. ആറ് മാസത്തിന് ശേഷമുള്ള ക്ലയന്റ് മാറ്റം ഡിസൈൻ അനുമാനിച്ച കഴിവ് നിശബ്ദമായി നീക്കം ചെയ്തേക്കാം.

LAN-നെ ടണലിലേക്ക് തിരിച്ചുവിട്ട് വിവർത്തനം ചെയ്യുക

പിന്തുണയുള്ള ക്ലയന്റ് ഉണ്ടെങ്കിൽ ബാക്കിയുള്ളത് സാധാരണ ഗേറ്റ്‌വേ ജോലിയാണ്. LAN ഉപകരണങ്ങൾക്ക് VPC ശ്രേണിക്കായി Linux ഹോസ്റ്റിലേക്ക് ചൂണ്ടുന്ന റൂട്ട് വേണം, ഹോസ്റ്റിന് ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാക്കണം. VPC ട്രാഫിക്കിനെ ഏതോ LAN വിലാസമായല്ല, കണക്റ്റ് ചെയ്ത ക്ലയന്റായി കാണണമെങ്കിൽ, പുറത്തുപോകുമ്പോൾ ഉറവിടം വിവർത്തനം ചെയ്യുക.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

നിയമം മുകളിൽ പറഞ്ഞതുപോലെ ടണൽ ഇന്റർഫേസിലും VPC ശ്രേണിയിലും പരിമിതപ്പെടുത്തുക, ഹോസ്റ്റ് ഫോർവേഡ് ചെയ്യുന്ന എല്ലാം masquerade ചെയ്യുന്നതിനുപകരം. ഇടുങ്ങിയ നിയമത്തെക്കുറിച്ച് ചിന്തിക്കാൻ എളുപ്പമാണ്, അത് യഥാർത്ഥ ഉറവിട വിലാസം നിലനിർത്തേണ്ട ട്രാഫിക്കിനെ നിശബ്ദമായി മാറ്റുന്നുമില്ല.

കഴിയുമെങ്കിൽ LAN റൂട്ട് സ്വയം വരട്ടെ: DHCP ഓപ്ഷൻ, റൗട്ടർ പ്രഖ്യാപനം, അല്ലെങ്കിൽ LAN കൈകാര്യം ചെയ്യുന്നത് പുഷ് ചെയ്യുന്ന സ്റ്റാറ്റിക് റൂട്ട്. ഒരു പരീക്ഷണ മെഷീനിൽ മാത്രം നിലനിൽക്കുന്ന റൂട്ട്, മറ്റാരെങ്കിലും അത് പരീക്ഷിക്കുന്ന നിമിഷം ഡിസൈൻ തകർന്നതായി കാണിക്കും.

മറുപടിക്കും ഒരു പാത വേണം

അഭ്യർത്ഥന VPC-യിൽ എത്തിയാൽ, മറുപടി അതേ വിവർത്തന അവസ്ഥകളിലൂടെ തിരികെ വന്ന് ഗേറ്റ്‌വേയിൽ LAN റൂട്ട് കണ്ടെത്തണം. ആ ഭാഗം സാധാരണയായി masquerade നിയമം ഉള്ളപ്പോൾ പ്രവർത്തിക്കുന്നു, കാരണം മാപ്പിംഗ് അത് ചെയ്ത ഹോസ്റ്റിൽ ജീവിക്കുന്നു. VPC വശത്ത് മറുപടി മറ്റൊരിടത്തേക്ക് അയക്കുന്ന റൂട്ട് ഉണ്ടെങ്കിൽ അത് തകരുന്നു, അതുകൊണ്ടാണ് ക്ലയന്റ് CIDR റൂട്ടും എൻഡ്‌പോയിന്റിലെ സബ്‌നെറ്റ് അസോസിയേഷനും രണ്ടും പ്രധാനമാകുന്നത്.

ping മാത്രമല്ല, കൗണ്ടറുകൾ നോക്കുക. പൂജ്യം പാക്കറ്റുള്ള masquerade നിയമം അഭ്യർത്ഥന ഒരിക്കലും ടണൽ ഇന്റർഫേസിൽ എത്തിയിട്ടില്ലെന്ന് പറയുന്നു, അത് LAN റൂട്ടിലേക്കോ ക്ലയന്റിന്റെ സ്വന്തം റൂട്ടിംഗ് ടേബിളിലേക്കോ ചൂണ്ടുന്നു. പാക്കറ്റുകളുണ്ടെങ്കിലും മറുപടികളില്ലാത്ത നിയമം VPC വശത്തേക്ക്, അനുമതി നിയമങ്ങളിലേക്ക്, അല്ലെങ്കിൽ വിവർത്തനം ചെയ്ത ഉറവിടം സ്വീകരിക്കാത്ത സുരക്ഷാ ഗ്രൂപ്പിലേക്ക് ചൂണ്ടുന്നു. എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് രണ്ട് ദിശകളും വായിക്കുക, കാരണം ഒരു വശത്ത് മാത്രം വളരുന്ന എണ്ണം പതിഞ്ഞ പാതയല്ല, ഏകദിശാ പാതയാണ്.

എൻഡ്‌പോയിന്റ് ഒരു മാനേജ്ഡ് സേവനമാണെന്ന് ഓർക്കുക. എഡിറ്റ് ചെയ്യാൻ സർവർ കോൺഫിഗറേഷൻ ഫയലുമില്ല, ചേർക്കാൻ client-config നിർദ്ദേശവുമില്ല, അതിനാൽ ഇഷ്ടാനുസൃത ക്ലയന്റ് സബ്‌നെറ്റ് റൂട്ടുകളുള്ള സ്വയം-മാനേജ്ഡ് OpenVPN സർവറിനായി എഴുതിയ നിർദ്ദേശങ്ങൾ കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല. AWS-ൽ ലിവറുകൾ സബ്‌നെറ്റ് അസോസിയേഷൻ, അനുമതി നിയമങ്ങൾ, VPC റൂട്ടിംഗ് ടേബിളുകൾ എന്നിവയാണ്.

പങ്കിട്ട ഐഡന്റിറ്റിയാണ് നയം ഉത്തരം നൽകേണ്ട ഭാഗം

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

അത് സ്വീകാര്യമായേക്കാം, അല്ലെങ്കിൽ ഡിസൈൻ നിരസിക്കപ്പെടാനുള്ള കാരണമായേക്കാം. VPC വിഭവങ്ങൾ ആരാണ് വിളിക്കുന്നത് എന്നതിനെക്കുറിച്ച് എന്ത് അനുമാനിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. അനുമതി മോഡലിന് യോജിക്കുന്ന പങ്കിട്ട ഐഡന്റിറ്റി കുഴപ്പമില്ല; ഒരു പ്രാമാണീകൃത സെഷനെ നിശബ്ദമായി മുഴുവൻ LAN ആക്സസാക്കി മാറ്റുന്നത് എഴുതപ്പെടാൻ കാത്തിരിക്കുന്ന ഒരു കണ്ടെത്തലാണ്.

ആവശ്യകത ശരിക്കും ഒരു മുഴുവൻ സൈറ്റിനെ VPC-യുമായി ബന്ധിപ്പിക്കലാണെങ്കിൽ, റിമോട്ട്-ആക്സസ് ക്ലയന്റ് വ്യാപിപ്പിക്കുന്നതിന് മുൻപ് പിന്തുണയുള്ള സൈറ്റ്-ടു-സൈറ്റ് ഡിസൈൻ താരതമ്യം ചെയ്യുക. അർത്ഥശാസ്ത്രം വ്യത്യസ്തമാണ്, VPC LAN-ലേക്ക് കണക്ഷനുകൾ ആരംഭിക്കേണ്ടിവരുമ്പോൾ NAT ചെയ്ത ക്ലയന്റ് സെഷൻ സൈറ്റ് ലിങ്കിന് മോശം പകരമാണ്.

ക്ലയന്റ്, റൂട്ട്, വിവർത്തനം, ഐഡന്റിറ്റി കഥ എന്നിവ ആ ക്രമത്തിൽ തീരുമാനിക്കുക. ഓരോന്നും അടുത്തതിനെ പരിമിതപ്പെടുത്തുന്നു, ആ ക്രമമാണ് ഹോസ്റ്റ് എന്തുകൊണ്ട് പ്രവർത്തിക്കുന്നു, LAN എന്തുകൊണ്ട് പ്രവർത്തിക്കുന്നില്ല എന്ന് വിശദീകരിക്കുന്നത്.

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