AWS Client VPN എൻഡ്‌പോയിന്റ് DNS: പരിഹരിച്ച IP പിൻ ചെയ്യുന്നത് എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു
AWS Client VPN എൻഡ്‌പോയിന്റ് നാമം നിങ്ങൾ പരിഹരിച്ച വിലാസം കൊണ്ട് മാറ്റുക, പിന്നീട് ടണൽ പ്രവർത്തിക്കുന്നത് നിലയ്ക്കും. എക്സ്പോർട്ട് ചെയ്ത നാമവും അതിന്റെ റാൻഡം പ്രിഫിക്സും നിലനിർത്തുക.
കഴിഞ്ഞ ആഴ്ച dig +short നിങ്ങളുടെ AWS Client VPN പ്രൊഫൈലിലെ എൻഡ്‌പോയിന്റ് നാമത്തിന് ഒരു വിലാസം നൽകി, ടണൽ കണക്ട് ചെയ്തു. ഈ ആഴ്ച അതേ പ്രൊഫൈൽ നിങ്ങളുടെ ലാപ്ടോപ്പിൽ 'Connecting' എന്ന നിലയിൽ നിൽക്കുന്നു, സഹപ്രവർത്തകന്റെ തൊടാത്ത പകർപ്പ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നു. ഒന്നും തടയപ്പെട്ടില്ല, സർട്ടിഫിക്കറ്റ് കാലഹരണപ്പെട്ടില്ല. ആരോ എൻഡ്‌പോയിന്റ് ഹോസ്റ്റ്നെയിം ആ പരിഹരിച്ച വിലാസം കൊണ്ട് മാറ്റി, സേവനം ഇപ്പോൾ അവിടെ പ്രതികരിക്കുന്നില്ല. എക്സ്പോർട്ട് ചെയ്ത നാമമാണ് ആ മാറ്റത്തെ അതിജീവിക്കാൻ നിർമ്മിച്ച ഭാഗം.
നിങ്ങളുടെ പ്രൊഫൈലിലെ നാമം ചോദിക്കപ്പെടുന്ന നാമമല്ലായിരിക്കാം
Client VPN-ൽ നിന്ന് എക്സ്പോർട്ട് ചെയ്യുന്ന പ്രൊഫൈലുകളിൽ സാധാരണയായി remote-random-hostname ഉണ്ടാകും. ആ ഓപ്ഷൻ ഓണായിരിക്കുമ്പോൾ ക്ലയന്റ് ഒരു താൽക്കാലിക ലേബൽ നിർമ്മിച്ച്, ഒരു ഡോട്ട് കൊണ്ട് എൻഡ്‌പോയിന്റ് നാമവുമായി ചേർത്ത്, സംയോജിത നാമം പരിഹരിക്കുന്നു. എൻഡ്‌പോയിന്റിന്റെ സോണിലുള്ള വൈൽഡ്കാർഡ് റെക്കോർഡ് ഏത് ലേബലിനും ഉത്തരം നൽകുന്നു, അതുകൊണ്ടാണ് കെട്ടിച്ചമച്ച പ്രിഫിക്സും പരിഹരിക്കപ്പെടുന്നത്, കൂടാതെ ക്വറി കൈകൊണ്ട് പുനർനിർമ്മിക്കാൻ ശ്രമിക്കുമ്പോൾ ഈ തന്ത്രം അദൃശ്യമായി നിൽക്കുന്നത്.
അതിനാൽ എൻഡ്‌പോയിന്റ് നാമം ടെർമിനലിൽ ഒട്ടിച്ച് ഉത്തരം ലഭിക്കുമ്പോൾ, ക്ലയന്റ് കണക്ഷൻ സമയത്ത് ഉപയോഗിക്കുന്ന നാമത്തിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു നാമമാണ് നിങ്ങൾ പരിഹരിച്ചത്. ആ പൊരുത്തക്കേട് പ്രൊഫൈലിൽ തിരുത്തേണ്ട ന്യൂനതയല്ല. ലേബൽ ബോധപൂർവം വീണ്ടും നിർമ്മിക്കപ്പെടുന്നു: ഓപ്ഷൻ കാഷുകൾ പഴയ ഉത്തരം സൂക്ഷിക്കുന്നത് തടയുന്നു, അത് ഒരിക്കലും നിങ്ങളുടെ മെഷീനെയോ സെഷനെയോ തിരിച്ചറിയുന്നില്ല.
ക്ലയന്റ് ഓപ്ഷൻ പൂർണ്ണമായി അവഗണിക്കുന്ന ഒരു അനുകൂല്യാവസ്ഥ ഞാൻ നേരിട്ടിട്ടുണ്ട്. AWS പരിഹാരം രേഖപ്പെടുത്തുന്നു: യഥാർത്ഥ എൻഡ്‌പോയിന്റ് നാമം നിലനിർത്തി മുന്നിൽ ഒരു റാൻഡം സ്ട്രിംഗും ഡോട്ടും ചേർക്കുക, അതിനെ ഒട്ടിക്കേണ്ട മൂല്യമല്ല, നാമകരണ മാതൃകയായി കാണുക. പഴയ ക്ലയന്റിൽ അത് പ്രയോഗിക്കുന്നത് ന്യായമാണ്; പ്രിഫിക്സുള്ള സ്ട്രിംഗ് എൻഡ്‌പോയിന്റായി ഹാർഡ്കോഡ് ചെയ്യുന്നത് അല്ല.
സംരക്ഷിച്ച ഉത്തരം എന്തുകൊണ്ട് ശരിയായി തുടരാനാവില്ല
Client VPN എൻഡ്‌പോയിന്റ് വിലാസങ്ങൾ AWS കൈകാര്യം ചെയ്യുന്നു, അവ സമയത്തിനനുസരിച്ച് മാറുന്നു, ഇത് മികച്ച സമ്പ്രദായങ്ങളുടെ ഡോക്യുമെന്റ് വ്യക്തമായി പറയുന്നു. പിടിച്ചെടുത്ത ഉത്തരം ഒരു പരിഹാരത്തിന്റെ സ്നാപ്പ്ഷോട്ടാണ്. അത് ഹാർഡ്കോഡ് ചെയ്യുന്ന പ്രൊഫൈൽ സേവനം മാറുന്നതോടെ പ്രവർത്തനരഹിതമായ ഹോസ്റ്റിനെ ലക്ഷ്യമിടുന്ന പ്രൊഫൈലാകും, പരാജയം അപൂർവ്വമായി DNS പോലെ തോന്നുന്നു: കണക്ഷൻ ടൈംഔട്ട് അല്ലെങ്കിൽ നിന്നുപോയ ഹാൻഡ്ഷേക്ക് ലഭിക്കുന്നു, അതിനാൽ ആളുകൾ റൂട്ടിംഗും സർട്ടിഫിക്കറ്റുകളും പിന്തുടരുന്നു.
/etc/hosts ലെ അതേ ഉത്തരം അതേ കാലഹരണം ഒരു അധിക പ്രശ്നത്തോടെ പിന്തുടരുന്നു. hosts എൻട്രി റീബൂട്ടുകളും വീണ്ടും എക്സ്പോർട്ടുകളും 'ക്ലയന്റ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുക' പരിഹാരങ്ങളും അതിജീവിക്കുന്നു, അതിനാൽ വിലാസം മാറുമ്പോഴെല്ലാം പരാജയം മടങ്ങുന്നു. ഒരു എൻട്രി ആഴ്ചകളോളം നിരുപദ്രവമായി കിടന്നതും, പിന്നീട് അത് വഹിച്ച എല്ലാ മെഷീനുകളും പ്രവർത്തനരഹിതമാക്കിയതും, പുതിയ ഇൻസ്റ്റാളുകൾ സാധാരണയായി കണക്ട് ചെയ്തതും ഞാൻ കണ്ടിട്ടുണ്ട്. അതേ അക്കൗണ്ടിൽ ഒരു കൂട്ടം പരാജയപ്പെടുകയും മറ്റൊന്ന് കുഴപ്പമില്ലാതിരിക്കുകയും ചെയ്യുന്ന ഈ വിഭജനമാണ് നിങ്ങൾക്ക് ലഭിക്കുന്ന ഏറ്റവും വിലകുറഞ്ഞ സൂചന.
റാൻഡമൈസേഷന്റെ പരിധി ശരിയായി നിർണ്ണയിക്കുക. ഇത് ഓരോ കണക്ഷൻ ശ്രമത്തിനും സംഭവിക്കുന്നു. സ്ഥാപിതമായ ടണൽ അതിന്റെ എൻഡ്‌പോയിന്റ് വീണ്ടും പരിഹരിക്കുന്നില്ല, സെഷന് നടുവിൽ സർവറുകൾ മാറ്റുന്നില്ല, വ്യക്തിഗത ആപ്ലിക്കേഷൻ അഭ്യർത്ഥനകൾ ഓരോന്നും പുതിയ VPN ഹോസ്റ്റ് തിരഞ്ഞെടുക്കുന്നില്ല. അടുത്ത ശ്രമം മാത്രം വീണ്ടും പരിഹരിക്കുന്നു, അതിനാൽ ഉച്ചയ്ക്ക് മുഴുവൻ പ്രവർത്തിക്കുന്ന സെഷൻ നാളെ രാവിലെയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
ടണൽ ഉയരുമ്പോൾ സേവനം എന്താണ് പരിശോധിക്കുന്നത്
Client VPN ആവശ്യപ്പെടുന്നത് നിങ്ങൾ കണക്ട് ചെയ്തിരിക്കുന്ന വിലാസം എൻഡ്‌പോയിന്റിന്റെ DNS നാമത്തിനായി പരിഹരിച്ച വിലാസവുമായി പൊരുത്തപ്പെടണം എന്നാണ്. ഈ ഒരു ആവശ്യകത ബന്ധമില്ലാത്തതായി തോന്നുന്ന നിരവധി പരാജയങ്ങൾ വിശദീകരിക്കുന്നു: മറ്റൊരിടത്തേക്ക് ചൂണ്ടുന്ന ഇഷ്ടാനുസൃത DNS റെക്കോർഡ്, യഥാർത്ഥ എൻഡ്‌പോയിന്റ് വിലാസത്തിലേക്ക് ഫോർവേഡ് ചെയ്യുന്ന ഇഷ്ടാനുസൃത ഫ്രണ്ട്എൻഡ്, ഒപ്പം അസംസ്കൃത വിലാസത്തിലേക്ക് മാറ്റിയെഴുതിയ പ്രൊഫൈൽ. AWS ഇഷ്ടാനുസൃത റെക്കോർഡും ഫോർവേഡിംഗും ചേർന്ന ക്രമീകരണത്തെ പുതിയ AWS ക്ലയന്റുകളുമായി ഒരു പരാജയമായി രേഖപ്പെടുത്തുന്നു. പരിശോധന ഇടുങ്ങിയതാണ്; എല്ലാ അലിയാസുകളും നിരോധിച്ചിരിക്കുന്നു എന്ന വിധിയല്ല.
VPN പ്രോട്ടോക്കോളുകളെക്കുറിച്ചുള്ള പൊതു നിയമവുമല്ല ഇത്. സംഖ്യാരൂപത്തിലുള്ള remote സാധാരണ OpenVPN വിന്യാസത്തിൽ പൂർണ്ണമായും സാധുവാണ്, പലതും അങ്ങനെ പ്രവർത്തിക്കുന്നു. നിയന്ത്രണം കൈകാര്യം ചെയ്യുന്ന ക്രമീകരണത്തിൽ നിന്നാണ് വരുന്നത്, അതിനടിയിലുള്ള പ്രോട്ടോക്കോളിൽ നിന്നല്ല.
അതാണ് സർട്ടിഫിക്കറ്റ് പരിശോധന അയച്ചുവിടുന്നതിനെ തെറ്റായ പ്രതികരണമാക്കുന്നത്. വിലാസം മാറിയതിന് ശേഷം പ്രൊഫൈൽ പരാജയപ്പെട്ടാൽ, സർവർ പരിശോധന ഓഫ് ചെയ്യുന്നത് പരിഹാരമോ വിലാസ-പൊരുത്ത ആവശ്യകതയോ ശരിയാക്കുന്നതിന് പകരം പിശക് മാറ്റിവയ്ക്കുന്നു, ഏതിനെയും വിശ്വസിക്കുന്ന ക്ലയന്റ് അവശേഷിപ്പിക്കുന്നു. എക്സ്പോർട്ട് ചെയ്ത CA, സർവർ പരിശോധന, പരസ്പര പ്രാമാണീകരണ ക്രമീകരണങ്ങൾ വന്നതുപോലെ തന്നെ സൂക്ഷിക്കുക.
അനുവദനീയ പട്ടികകൾ, എഗ്രസ്, സ്വകാര്യ DNS എന്നിവ മൂന്ന് വേറിട്ട പ്രശ്നങ്ങളാണ്
ലാപ്ടോപ്പ് കണക്ട് ചെയ്യുന്നതിന് മുമ്പ് ഒരു ലക്ഷ്യസ്ഥാനം അനുവദിക്കേണ്ട ഫയർവാൾ നിയമം പുറം ശ്രോതാവിനെക്കുറിച്ചാണ്. നെറ്റ്വർക്ക് ഉടമയ്ക്ക് എൻഡ്‌പോയിന്റ് നാമം, ട്രാൻസ്പോർട്ട്, കോൺഫിഗർ ചെയ്ത പോർട്ട് നൽകുക, എന്നിട്ട് അവരുടെ നിയന്ത്രണത്തിന് സേവനത്തിന്റെ DNS സ്വഭാവം പിന്തുടരാൻ കഴിയുമോ എന്ന് ചോദിക്കുക. പിടിച്ചെടുത്ത ഒരു വിലാസം സൂക്ഷിക്കുന്ന നിയമം എഴുതപ്പെടാത്ത കാലഹരണമുള്ള സ്നാപ്പ്ഷോട്ടാണ്. നിയന്ത്രണം മാറ്റമില്ലാത്ത ലക്ഷ്യസ്ഥാനങ്ങൾ മാത്രം സ്വീകരിക്കുന്നുവെങ്കിൽ, നിശ്ശബ്ദമായി ഉത്തരം ഹാർഡ്കോഡ് ചെയ്യുന്നതിന് പകരം വിന്യാസത്തിന് മുമ്പ് ആ വിടവ് പരിഹരിക്കുക.
ടണൽ ഉയർന്നതിന് ശേഷമുള്ള അഭ്യർത്ഥനകൾക്ക് സ്ഥിരമായ ഉറവിട വിലാസം വേണ്ട പങ്കാളിക്ക് മറ്റൊരു ആവശ്യകതയുണ്ട്: എഗ്രസ്. ഒരു വെബ്സൈറ്റ് കാണുന്നത് ആപ്ലിക്കേഷൻ റൂട്ടും സ്പ്ലിറ്റ്-ടണൽ നയവും അനുസരിച്ചാണ്, ക്ലയന്റ് കണക്ട് ചെയ്ത വിലാസം അനുസരിച്ചല്ല. സ്പ്ലിറ്റ്-ടണൽ ട്രാഫിക് AWS-നെ തൊട്ടേക്കാം.
ടണലിനുള്ളിലെ സ്വകാര്യ DNS മൂന്നാം പാളിയാണ്. ക്ലയന്റുകൾക്ക് നൽകുന്ന റിസോൾവർ കണക്ഷന് ശേഷം ആന്തരിക നാമങ്ങൾക്ക് ഉത്തരം നൽകുന്നു; ടണൽ ഉണ്ടാകുന്നതിന് മുമ്പ് അത് പൊതു എൻഡ്‌പോയിന്റ് പരിഹരിക്കാൻ കഴിയില്ല. എൻഡ്‌പോയിന്റ് പരിഹാര പരാജയവും ആന്തരിക ആപ്ലിക്കേഷൻ പരിഹാര പരാജയവും വ്യത്യസ്ത ഘട്ടങ്ങളിൽ സംഭവിക്കുന്നു, അവ കൂട്ടിക്കലർത്തുന്നത് തെറ്റായ ലോഗിലേക്ക് നയിക്കുന്നു.
വിലാസ കുടുംബവും അതേ പട്ടികയിൽ പെടുന്നു. IPv4 ഉത്തരം IPv6 അല്ലെങ്കിൽ ഇരട്ട-സ്റ്റാക്ക് എൻഡ്‌പോയിന്റിന്റെ അനുവദനീയമായ പാതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ ഒരു കുടുംബത്തിൽ എടുത്ത സ്നാപ്പ്ഷോട്ട് മറ്റൊന്നിന് തെളിവല്ല.
ഒന്നും പിൻ ചെയ്യാതെ ഒരു കണക്ഷൻ പരിശോധിക്കുക
എക്സ്പോർട്ട് ചെയ്ത അതേ പ്രൊഫൈലിൽ നിന്ന് തുടങ്ങി അത് യഥാർത്ഥത്തിൽ എന്താണ് ആവശ്യപ്പെടുന്നതെന്ന് വായിക്കുക:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'തുടർന്ന് മൂന്ന് കാര്യങ്ങൾ താരതമ്യം ചെയ്യുക: പ്രൊഫൈലിലുള്ള എൻഡ്‌പോയിന്റ് നാമം, പുതിയ ശ്രമത്തിനായി ക്ലയന്റ് റിപ്പോർട്ട് ചെയ്യുന്ന വിലാസം, നാമം ഇപ്പോൾ എന്തിലേക്ക് പരിഹരിക്കുന്നു എന്നത്. പരിഹരിക്കുന്ന നാമം റെക്കോർഡ് ഉത്തരം നൽകുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു; ട്രാൻസ്പോർട്ടും പ്രാമാണീകരണവും വേറെയാണ്, എൻഡ്‌പോയിന്റ് ping-ന് ഉത്തരം നൽകേണ്ടതില്ല. മധ്യ ഇനത്തിന് ക്ലയന്റിന്റെ സ്വന്തം ലോഗ് മാത്രമാണ് ഉറവിടം, അതിനാൽ ശ്രമത്തിനിടയിൽ അത് പകർത്തുക, ശേഷമല്ല.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
ഇന്ന് ഉത്തരം നൽകുന്ന വിലാസം ഇന്നിനെക്കുറിച്ചുള്ള തെളിവാണ്; സേവനം സാധുവായി നിലനിർത്തുന്നത് നാമമാണ്. നിരീക്ഷണം രേഖപ്പെടുത്തി, എൻഡ്‌പോയിന്റ് ഉടമയ്ക്ക് അയച്ച്, പ്രൊഫൈൽ നാമത്തിലേക്ക് ചൂണ്ടുന്നതായി വിടുക.
ഉപേക്ഷിക്കേണ്ട രണ്ട് ശീലങ്ങൾ: നിന്നുപോയ ഹാൻഡ്ഷേക്ക് കടക്കാൻ സർട്ടിഫിക്കറ്റ് പരിശോധന ഓഫ് ചെയ്യുന്നതും, ഒന്ന് പറ്റിപ്പിടിക്കുമെന്ന പ്രതീക്ഷയിൽ എൻഡ്‌പോയിന്റ് നാമത്തിന് മുന്നിൽ ലേബലുകൾ കൂട്ടുന്നതും. ലേബൽ വൈൽഡ്കാർഡ് റെക്കോർഡിലൂടെ പരിഹരിക്കുന്നു, അല്ലെങ്കിൽ പ്രശ്നം മറ്റൊരിടത്താണ്. ശരിയായി കോൺഫിഗർ ചെയ്ത പ്രൊഫൈൽ ഇപ്പോഴും പരാജയപ്പെട്ടാൽ, നീണ്ട ഹോസ്റ്റ്നെയിമല്ല, കൃത്യമായ ക്വറിയും കണക്ഷൻ ഇവന്റും അയയ്ക്കുക.
അടയ്ക്കുന്നതിന് മുമ്പ്: പ്രൊഫൈലിൽ ഇപ്പോഴും എക്സ്പോർട്ട് ചെയ്ത എൻഡ്‌പോയിന്റ് നാമമുണ്ട്, ഒരു hosts ഫയലും വിലാസം പിൻ ചെയ്യുന്നില്ല, ക്ലയന്റ് ലോഗിലെ remote നിലവിലെ പരിഹാരവുമായി പൊരുത്തപ്പെടുന്നു, ഫയർവാൾ നിയമം വിലാസത്തിന് പകരം എൻഡ്‌പോയിന്റിനെ പേരിടുന്നു. അടുത്ത വ്യക്തിക്ക് കൈമാറേണ്ട അവസ്ഥയും ഇതുതന്നെ.