AWS Client VPN കണക്ട് ആണ്, പക്ഷേ EC2 ഇപ്പോഴും പ്രതികരിക്കുന്നില്ല
കണക്ട് എന്നത് സർട്ടിഫിക്കറ്റ് അല്ലെങ്കിൽ SAML ലോഗിൻ വിജയിച്ചു എന്ന് മാത്രം അർത്ഥമാക്കുന്നു. അനുമതി നിയമങ്ങൾ, endpoint റൂട്ടുകൾ, സെക്യൂരിറ്റി ഗ്രൂപ്പുകൾ എന്നിവ ഓരോന്നും സ്വകാര്യ ഹോസ്റ്റിലേക്കുള്ള വഴിയുടെ ഓരോ ഭാഗം കാക്കുന്നു.
എന്റെ ലാപ്‌ടോപ്പ് കണക്ട് എന്ന് കാണിച്ചു. AWS Client VPN ക്ലയന്റ് അതിന്റെ പച്ച നില കാണിച്ചു, endpoint ഒരു സെഷൻ രേഖപ്പെടുത്തി, എന്നിട്ടും സ്വകാര്യ സബ്‌നെറ്റിലെ EC2 ഇൻസ്റ്റൻസിൽ MongoDB പോർട്ട് തുറക്കാൻ എനിക്ക് കഴിഞ്ഞില്ല. പ്രകടമായി ഒന്നും തകർന്നിരുന്നില്ല: സർട്ടിഫിക്കറ്റ് സാധുവായിരുന്നു, പ്രൊഫൈൽ കൺസോളിൽ നിന്ന് വന്നു, ടണൽ ട്രാഫിക് വഹിച്ചു. തെറ്റ് എന്റേതായിരുന്നു, കാരണം ഞാൻ കണക്ട് എന്നതിനെ അംഗീകരിച്ചത് എന്ന് വായിച്ചു.
ലോഗിൻ കൃത്യമായി ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഈ ഐഡന്റിറ്റിക്ക് ഒരു സെഷൻ സ്ഥാപിക്കാമോ? അതിനുശേഷമുള്ളതെല്ലാം നിങ്ങളുടെ സർട്ടിഫിക്കറ്റ് ഒരിക്കലും കാണാത്ത വെവ്വേറെ നിയമങ്ങളാണ് തീരുമാനിക്കുന്നത്. പ്രാമാണീകരണം കടക്കുന്ന സെഷനും എത്തുന്ന പാക്കറ്റും രണ്ട് വ്യത്യസ്ത വിജയങ്ങളാണ്, അവയ്ക്കിടയിലെ വിടവാണ് VPN ഓണാണ് പക്ഷേ ഹോസ്റ്റ് എത്തിച്ചേരാനാവില്ല എന്ന തരത്തിലുള്ള ഭൂരിഭാഗം പരാതികളും ജീവിക്കുന്ന ഇടം.
താഴെയുള്ള പരിശോധനകൾ ഞാൻ ഇപ്പോൾ ഉപയോഗിക്കുന്ന ക്രമമാണ്.
കണക്ട് ചെയ്ത സെഷൻ യഥാർത്ഥത്തിൽ എന്ത് തെളിയിക്കുന്നു
ഹാൻഡ്‌ഷേക്ക് സമയത്ത് endpoint ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് അതിന്റെ trust store-ന് എതിരായി സാധൂകരിക്കുന്നു, അല്ലെങ്കിൽ SAML കോൺഫിഗർ ചെയ്തിരിക്കുമ്പോൾ ബ്രൗസറിനെ നിങ്ങളുടെ ഐഡന്റിറ്റി പ്രൊവൈഡറിലേക്ക് വഴിതിരിച്ചുവിടുന്നു. അത് കടന്നാൽ, ക്ലയന്റിന് endpoint-ന്റെ ക്ലയന്റ് CIDR-ൽ നിന്ന് ഒരു വിലാസം ലഭിക്കുന്നു, കൺസോൾ സജീവ കണക്ഷൻ കാണിക്കുന്നു. ആ കൈമാറ്റത്തിന്റെ ഒരിടത്തും 10.0.4.17-ലേക്ക് 27017 പോർട്ടിൽ എത്താൻ കഴിയുമോ എന്ന് ആരും ചോദിക്കുന്നില്ല.
ഒരു ലക്ഷ്യസ്ഥാനത്തിനുള്ള അനുമതി endpoint-ൽ വെവ്വേറെ ഒരു ഒബ്ജക്റ്റാണ്. ഓരോ ഫ്ലോയും അനുമതി നിയമങ്ങളുമായി താരതമ്യപ്പെടുത്തുന്നു, ഓരോ നിയമവും ഒരു ലക്ഷ്യ CIDR-നെ നിയമം നൽകപ്പെടുന്ന ഗ്രൂപ്പുമായി ചേർക്കുന്നു. ഒരു നിയമവും ലക്ഷ്യസ്ഥാനം ഉൾക്കൊള്ളുന്നില്ലെങ്കിൽ, endpoint സെഷൻ സ്വീകരിച്ച് ട്രാഫിക് ഉപേക്ഷിക്കുന്നു. ബാനറില്ല, വീണ്ടും കണക്ട് ചെയ്യാനുള്ള ലൂപ്പില്ല, നിരസിച്ചു എന്ന് പറയുന്ന ഒന്നും ക്ലയന്റ് UI-യിലുമില്ല.
അനുമതി നിയമത്തെ VPC-യുമായി അല്ല, റിസോഴ്സുമായി താരതമ്യപ്പെടുത്തുക
നിയമങ്ങൾ പട്ടികപ്പെടുത്തി ഇൻസ്റ്റൻസിന് യഥാർത്ഥത്തിൽ ഉള്ള വിലാസത്തിന്റെ അടുത്ത് വയ്ക്കുക:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8ഔട്ട്പുട്ട് ഓരോ നിയമത്തിനും ലക്ഷ്യ CIDR-ഉം ഗ്രൂപ്പ് ID-യും കാണിക്കുന്നു. അതിൽ രണ്ട് പരാജയങ്ങൾ ഒളിഞ്ഞിരിക്കുന്നു. നിയമം 10.0.0.0/16 അനുവദിക്കാം, എന്നാൽ ഇൻസ്റ്റൻസ് 10.1.0.0/16-ലെ പീയർ ചെയ്ത VPC-യിലാണ്; പീയറിംഗ് റൂട്ട് ഉണ്ട്, പക്ഷേ രണ്ടാമത്തെ ശ്രേണിക്ക് ആരും അനുമതി നിയമം എഴുതിയിട്ടില്ല. അല്ലെങ്കിൽ ഉപയോക്താവ് ഡയറക്ടറിയിൽ അംഗമായിരിക്കുന്ന, എന്നാൽ endpoint വിലയിരുത്തുന്ന ഗ്രൂപ്പിൽ അല്ലാത്ത ഒരു ഡയറക്ടറി ഗ്രൂപ്പിനെ നിയമം ചൂണ്ടിക്കാണിക്കുന്നു.
ലക്ഷ്യസ്ഥാനം ഉൾക്കൊള്ളുന്ന ഏറ്റവും ഇടുങ്ങിയ നിയമം എഴുതുക, രണ്ടാമത്തെ CIDR യഥാർത്ഥത്തിൽ ആവശ്യമുള്ളപ്പോൾ മാത്രം രണ്ടാമത്തെ നിയമം ചേർക്കുക. വേഗത്തിലുള്ള തുടക്കത്തിൽ നിന്നുള്ള വിശാലമായ 0.0.0.0/0 നിയമം പ്രവർത്തിക്കുന്നു, അതുകൊണ്ടാണ് അത് ഉത്പാദനം വരെ നിലനിൽക്കുന്നതും മോഡൽ മറച്ചുവയ്ക്കുന്നതും.
പാക്കറ്റ് നീങ്ങുമോ എന്ന് രണ്ട് റൂട്ട് ടേബിളുകൾ തീരുമാനിക്കുന്നു
endpoint റൂട്ട് ഒരു ലക്ഷ്യ CIDR-നെ endpoint ബന്ധപ്പെട്ടിരിക്കുന്ന സബ്‌നെറ്റുകളിലൊന്നിലേക്ക് മാപ്പ് ചെയ്യുന്നു. അത് വഴിയുടെ പകുതിയാണ്. സബ്‌നെറ്റിന്റെ സ്വന്തം റൂട്ട് ടേബിളിന് ഇപ്പോഴും പാക്കറ്റ് എങ്ങനെ കൈമാറണം എന്ന് അറിയണം, ലക്ഷ്യസ്ഥാനം പീയറിംഗ് കണക്ഷന്, ട്രാൻസിറ്റ് ഗേറ്റ്‌വേയ്ക്ക്, അല്ലെങ്കിൽ സൈറ്റ്-ടു-സൈറ്റ് ടണൽ വഴി എത്താവുന്ന ഓൺ-പ്രെമൈസസ് ശ്രേണിക്ക് പിന്നിലാകുന്ന നിമിഷം അത് പ്രധാനമാകുന്നു.
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8ലക്ഷ്യസ്ഥാനം റിസോഴ്സിന്റെ CIDR-നോട് യോജിക്കുന്നതും ലക്ഷ്യം ബന്ധപ്പെട്ട സബ്‌നെറ്റുമായ ഒരു റൂട്ട് അന്വേഷിക്കുക. റൂട്ട് ഇല്ലെങ്കിൽ ചേർക്കുക. ഉണ്ടെങ്കിലും ഹോസ്റ്റ് ഇപ്പോഴും നിശ്ശബ്ദമാണെങ്കിൽ, വിടവ് VPC വശത്താണ്, അതിനാൽ അസോസിയേഷൻ സബ്‌നെറ്റിന്റെ റൂട്ട് ടേബിളുമായി താരതമ്യപ്പെടുത്തുക.
ക്ലയന്റ് വശത്തെ ഒരു ക്രമീകരണം ടണൽ തകർക്കാതെ റൂട്ടിംഗ് തകർക്കുന്നു: route-nopull അടങ്ങിയ ഒരു പ്രൊഫൈൽ. OpenVPN അടിസ്ഥാനമാക്കിയ ക്ലയന്റിനോട് സെർവർ തള്ളുന്ന റൂട്ടുകൾ അവഗണിക്കാൻ ഈ നിർദ്ദേശം പറയുന്നു, അതിനാൽ ഇന്റർഫേസ് endpoint-ന്റെ സ്വന്തം വിലാസത്തോടെ മാത്രം ഉയരുന്നു, ലക്ഷ്യസ്ഥാനത്തിന് റൂട്ടേയില്ല. Linux-ൽ ip route show അല്ലെങ്കിൽ macOS-ൽ netstat -rn ഉപയോഗിച്ച് tun ഇന്റർഫേസ് വഴി റൂട്ട് ഉണ്ടോ എന്ന് പരിശോധിക്കുക. ഇല്ലെങ്കിൽ, എക്സ്പോർട്ട് ചെയ്ത പ്രൊഫൈലിൽ നിന്ന് route-nopull നീക്കി വീണ്ടും കണക്ട് ചെയ്യുക, തള്ളിയ റൂട്ടുകൾ പ്രാബല്യത്തിൽ വരാൻ.
സെക്യൂരിറ്റി ഗ്രൂപ്പുകൾ നിങ്ങളുടെ ക്ലയന്റ് വിലാസം കാണുന്നില്ല
ഞാൻ ഒരു ഉച്ചയ്ക്ക് തെറ്റായി പിടിച്ച ഭാഗമാണിത്. ഒരു സബ്‌നെറ്റുമായി ബന്ധപ്പെട്ട IPv4 endpoint-ിന്, ക്ലയന്റിന്റെ ഉറവിട വിലാസം ആ സബ്‌നെറ്റിലെ endpoint-ന്റെ നെറ്റ്‌വർക്ക് ഇന്റർഫേസ് വിലാസത്തിലേക്ക് സേവനം വിവർത്തനം ചെയ്യുന്നു. ഇൻസ്റ്റൻസിൽ എത്തുന്ന പാക്കറ്റ് നിങ്ങളുടെ ക്ലയന്റ് കാണിച്ച വിലാസം വഹിക്കുന്നില്ല, അതിനാൽ ക്ലയന്റ് പൂൾ, പറയട്ടെ 172.16.0.0/22, അനുവദിക്കുന്ന സെക്യൂരിറ്റി ഗ്രൂപ്പ് നിയമം ഒന്നുമായും യോജിക്കുന്നില്ല.
പോർട്ട് ക്ലയന്റ് CIDR-ൽ നിന്നല്ല, അസോസിയേഷന്റെ ഇന്റർഫേസിൽ ഘടിപ്പിച്ച endpoint-ന്റെ സെക്യൂരിറ്റി ഗ്രൂപ്പിൽ നിന്ന് അനുവദിക്കുക. വിലാസം ഹാർഡ്‌കോഡ് ചെയ്യുന്നതിനേക്കാൾ ഗ്രൂപ്പിനെ റഫർ ചെയ്യുന്നത് നീണ്ടുനിൽക്കും, കാരണം ഇന്റർഫേസ് വിലാസം നിങ്ങളുടെ നിയന്ത്രണത്തിലല്ല. നെറ്റ്‌വർക്ക് ACL-കൾ സ്റ്റേറ്റ്‌ലെസ് ആണ്, അതിനാൽ ഇഷ്ടാനുസൃത എൻട്രികൾ ഉള്ളിടത്ത് ഇൻബൗണ്ടും ഔട്ട്ബൗണ്ടും ഫ്ലോ അനുവദിക്കണം.
ഇൻസ്റ്റൻസിന്റെ സ്വകാര്യ വിലാസത്തിലേക്കും കണക്ട് ചെയ്യുക. പൊതു IP പാക്കറ്റിനെ VPC-യിൽ നിന്ന് പുറത്തുകൊണ്ടുപോയി മറ്റ് നിയമങ്ങളുള്ള മറ്റൊരു വഴിയിലൂടെ തിരികെ കൊണ്ടുവരുന്നു, അതിനാൽ പൊതു വിലാസത്തിലെ പരീക്ഷണം സ്വകാര്യ വഴിയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
ആദ്യ പരാജയത്തിൽ നിൽക്കുന്ന ഐസൊലേഷൻ ക്രമം
ഇവ ക്രമത്തിൽ ചെയ്ത് ഒന്ന് പരാജയപ്പെടുന്നിടത്ത് നിർത്തുക. ഓരോ ഘട്ടവും എല്ലാ പാളികളെയല്ല, ഒരു പാളിയെ ഒഴിവാക്കുന്നു.
- സെഷൻ ഏത് ഐഡന്റിറ്റി ഉപയോഗിച്ചു, endpoint ഏത് ഗ്രൂപ്പ് വിലയിരുത്തുന്നു എന്ന് സ്ഥിരീകരിക്കുക. ഒരു trust store-ലെ സർട്ടിഫിക്കറ്റ് ഡയറക്ടറിയിൽ നിന്നുള്ള SAML പ്രസ്താവനയുമായി ഒരേ പ്രിൻസിപ്പലല്ല.
- ആ ഗ്രൂപ്പിനായി അനുമതി നിയമം റിസോഴ്സിന്റെ CIDR ഉൾക്കൊള്ളുന്നു എന്ന് സ്ഥിരീകരിക്കുക.
- endpoint റൂട്ട് ഉണ്ടെന്നും ബന്ധപ്പെട്ട സബ്‌നെറ്റിനെ ലക്ഷ്യമാക്കുന്നുവെന്നും, തുടർന്ന് സബ്‌നെറ്റ് റൂട്ട് ടേബിളിന് മുന്നോട്ട് കൈമാറാൻ കഴിയുമെന്നും സ്ഥിരീകരിക്കുക.
- സെക്യൂരിറ്റി ഗ്രൂപ്പ് പോർട്ട് ക്ലയന്റ് പൂളിൽ നിന്നല്ല, endpoint ഇന്റർഫേസിൽ നിന്ന് അനുവദിക്കുന്നു എന്ന് സ്ഥിരീകരിക്കുക.
- ആപ്ലിക്കേഷൻ പ്രശ്നത്തെ ക്ലയന്റ് വഴിയുടെ പ്രശ്നത്തിൽ നിന്ന് വേർതിരിക്കാൻ VPC-യുടെ ഉള്ളിൽ നിന്ന്, അതേ സബ്‌നെറ്റിലെ മറ്റൊരു ഇൻസ്റ്റൻസിൽ SSM സെഷൻ ഉപയോഗിച്ച് പരീക്ഷിക്കുക.
ഘട്ടങ്ങൾ നിർണ്ണായകമല്ലാത്തപ്പോൾ ഞാൻ ഈ പട്ടികയെ ആശ്രയിക്കുന്നു:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
അക്കൗണ്ടിന്റെ രണ്ട് വിശദാംശങ്ങൾ അനുമതി പരാജയത്തെപ്പോലെ തോന്നിക്കുന്ന ലക്ഷണങ്ങൾ ഉണ്ടാക്കുന്നു. ഓരോ ഉപയോക്താവിനും വെവ്വേറെ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് വേണം; ഒന്ന് രണ്ട് മെഷീനുകളിൽ പങ്കിട്ടാൽ സെഷനുകൾ പരസ്പരം മാറ്റിവയ്ക്കുന്നു, ഫലം നിരസിക്കലല്ല, വീണ്ടും കണക്ട് ചെയ്യാനുള്ള ലൂപ്പാണ്. പുതിയ endpoint സൃഷ്ടിക്കുമ്പോൾ കൺസോൾ ഒരു DNS പേര് കാണിക്കുന്നു, ചില ക്ലയന്റ് പതിപ്പുകൾ അത് endpoint പേജിൽ കാണിക്കുന്ന റാൻഡം പ്രിഫിക്‌സോടുകൂടി മാത്രമാണ് സ്വീകരിക്കുന്നത്, അതിനാൽ പേര് വീണ്ടും നിർമ്മിക്കാതെ പൂർണ്ണമായ പേര് പകർത്തുക.
അഞ്ചാമത്തെ ഘട്ടം നിങ്ങളെ തടഞ്ഞാൽ, എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് endpoint-ന്റെ കണക്ഷൻ ലോഗ് എടുത്ത് അനുമതി എൻട്രികൾ വായിക്കുക. പരിശോധിച്ച ലക്ഷ്യസ്ഥാനവും യോജിച്ചതോ യോജിക്കാത്തതോ ആയ നിയമവും ലോഗ് പേരെടുത്ത് പറയുന്നു, അത് നാല് പാളികളുള്ള ചോദ്യത്തെ ഒരു ഉത്തരത്തിലേക്ക് ചുരുക്കുന്നു.