ASA ദൂരസ്ഥ ഉപയോക്താവ് സബ്നെറ്റിലെത്തുന്നു, ആപ്പിലേക്ക് എത്താത്തത് എന്തുകൊണ്ട്
റൂട്ടുകൾ ടണൽ പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, ഉപയോക്താവിന് ആപ്പ് തുറക്കാമെന്നല്ല. സെഷൻ ലഭിച്ച ഫിൽട്ടർ വായിക്കുക, തുടർന്ന് അനുവദിച്ചതും നിരസിച്ചതുമായ കണക്ഷൻ പരിശോധിക്കുക.
നിങ്ങളുടെ ഉപയോക്താവ് കണക്ട് ചെയ്യുന്നു, വിലാസം ലഭിക്കുന്നു, ആപ്പിന്റെ സബ്നെറ്റിലുള്ള സെർവറിലേക്ക് പിംഗ് ചെയ്യുന്നു, എന്നിട്ടും അതിലുള്ള സേവനം തുറക്കാൻ കഴിയുന്നില്ല. ഈ സംയോജനം ASA-യിൽ സാധാരണമാണ്, കാരണം വിജയകരമായ ടണലും ഉപയോഗപ്രദമായ അനുമതിയും വ്യത്യസ്ത ക്രമീകരണങ്ങളാണ് തീരുമാനിക്കുന്നത്. സ്പ്ലിറ്റ്-ടണൽ ലിസ്റ്റ് ഏത് ലക്ഷ്യങ്ങൾ ടണലിൽ പ്രവേശിക്കണം എന്ന് തിരഞ്ഞെടുത്തു; VPN ഫിൽട്ടറും ലക്ഷ്യത്തിന്റെ സ്വന്തം ആക്സസ് നിയമങ്ങളും ഡീക്രിപ്റ്റ് ചെയ്ത അഭ്യർത്ഥന എന്തിലേക്ക് എത്താമെന്ന് തീരുമാനിക്കുന്നു. റൂട്ട് ലിസ്റ്റ് വിശാലമാക്കുന്നതിനു പകരം മൂന്ന് തീരുമാനങ്ങളും ക്രമത്തിൽ പരിശോധിക്കുക, എന്തെങ്കിലും മാറുന്നതുവരെ.
ആശയക്കുഴപ്പത്തിലാക്കാൻ എളുപ്പമുള്ള മൂന്ന് തീരുമാനങ്ങൾ
പ്രവേശനം ഉപയോക്താവിന് ടണൽ നിർമ്മിക്കാമോ എന്ന് ഉത്തരം നൽകുന്നു: ക്രെഡൻഷ്യലുകൾ, സർട്ടിഫിക്കറ്റ്, ഏതെങ്കിലും രണ്ടാം ഘടകം. റൂട്ട് തിരഞ്ഞെടുപ്പ് ക്ലയന്റ് ഏത് ലക്ഷ്യങ്ങൾ ആ ടണലിലേക്ക് അയക്കുന്നു എന്ന് ഉത്തരം നൽകുന്നു. അംഗീകാരം ഡീക്രിപ്റ്റ് ചെയ്ത അഭ്യർത്ഥന സേവനത്തിലെത്താമോ എന്ന് ഉത്തരം നൽകുന്നു. ഉപയോക്താവ് റിപ്പോർട്ട് ചെയ്യുന്ന പിശക് മൂന്നാമത്തേത് മാത്രം സൃഷ്ടിക്കുന്നു.
അവയെ വേർതിരിച്ചറിയാനുള്ള വേഗമാർഗം ഒരു മാറ്റം എന്ത് തകർക്കുമെന്ന് ചോദിക്കുകയാണ്. സ്പ്ലിറ്റ് ലിസ്റ്റിൽ നിന്ന് ഒരു റൂട്ട് നീക്കിയാൽ ആ സബ്നെറ്റിലേക്കുള്ള ട്രാഫിക് നിലയ്ക്കും, പക്ഷേ ഒന്നും അനുവദിക്കുന്നില്ല; VPN ഫിൽട്ടറിൽ ഒരു ACE ചേർത്താൽ ക്ലയന്റ് ടണലിൽ എന്ത് കൊണ്ടുപോകുന്നു എന്നത് മാറ്റാതെ ഒരു ലക്ഷ്യം അനുവദിക്കുന്നു.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
സെഷൻ യഥാർത്ഥത്തിൽ ലഭിച്ച ഫിൽട്ടർ വായിക്കുക
ബാധകമാണെന്ന് നിങ്ങൾ കരുതുന്ന കോൺഫിഗറേഷനിൽ നിന്നല്ല, സജീവ സെഷനിൽ നിന്ന് തുടങ്ങുക. show vpn-sessiondb detail anyconnect അനുവദിച്ച ഗ്രൂപ്പ് പോളിസിയും ആ സെഷനിൽ ഘടിപ്പിച്ച ഫിൽട്ടറിന്റെ പേരും അച്ചടിക്കുന്നു. ഈ ഫീൽഡ് ശൂന്യമാണെങ്കിൽ ഒരു ഫിൽട്ടറും ഒന്നും നിർബന്ധിക്കുന്നില്ല, തടയൽ മറ്റെവിടെ നിന്നാണ് വരുന്നത്.
തുടർന്ന് മൂല്യം ഉള്ള പോളിസി, സ്ഥിരസ്ഥിതികൾ ഉൾപ്പെടെ വായിക്കുക, കാരണം ഫിൽട്ടർ നിങ്ങൾ നോക്കുന്നിടത്ത് എഴുതപ്പെട്ടതല്ല, പാരമ്പര്യമായി വരാം:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
സെഷനിലെ ഫിൽട്ടർ നാമം നിങ്ങൾ ഇപ്പോൾ തിരുത്തിയ ACL-മായി താരതമ്യപ്പെടുത്തുക. ഉപയോക്താവിന് ഒരിക്കലും ലഭിക്കാത്ത സമാനനാമമുള്ള ACL-ക്ക് ആ സെഷന്റെ റിസോഴ്സ് പോളിസി മാറ്റാൻ കഴിയില്ല, ശരിയായി തോന്നുന്ന മാറ്റത്തിന് ഫലമില്ലാത്തതിന്റെ ഏറ്റവും സാധാരണ കാരണം ഇതാണ്.
മുൻഗണന ബാക്കി വിശദീകരിക്കുന്നു. ഫിൽട്ടർ ക്രമീകരണത്തിന് DAP റെക്കോർഡ് ഉപയോക്തൃനാമ ആട്രിബ്യൂട്ടുകൾക്ക് മുകളിലാണ്, ഉപയോക്തൃനാമ ആട്രിബ്യൂട്ടുകൾ ഗ്രൂപ്പ് പോളിസിക്ക് മുകളിലും. സെഷൻ പ്രതീക്ഷിക്കാത്ത ഒരു ഫിൽട്ടർ കാണിച്ചാൽ, ഗ്രൂപ്പിൽ തൊടുന്നതിന് മുൻപ് ആ ഉപയോക്താവിനോട് യോജിക്കുന്ന DAP പോളിസി തിരയുക.
സ്പ്ലിറ്റ് ലിസ്റ്റും ഫിൽട്ടറും വെവ്വേറെ ഫീൽഡുകളാണ്
ASA 9.x-ൽ ഗ്രൂപ്പ് പോളിസി split-tunnel-network-list ഉം vpn-filter ഉം വ്യത്യസ്ത ക്രമീകരണങ്ങളായി സൂക്ഷിക്കുന്നു, 9.22 ഗ്രൂപ്പ്-പോളിസി ഗൈഡ് അവയെ വെവ്വേറെ രേഖപ്പെടുത്തുന്നത് അതുകൊണ്ടാണ്. നെറ്റ്വർക്ക് ലിസ്റ്റ് ക്ലയന്റിനുള്ള റൂട്ടിംഗ് സൂചനയാണ്; ഫിൽട്ടർ ഡീക്രിപ്റ്റ് ചെയ്ത ട്രാഫിക്കിൽ പ്രയോഗിക്കുന്ന ആക്സസ് നിയന്ത്രണ പട്ടികയാണ്.
ഉപയോക്താവിന് സബ്നെറ്റിൽ ഒരു HTTPS സേവനം മാത്രം വേണ്ടിവരുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്. പാക്കറ്റുകൾ ടണലിൽ പ്രവേശിക്കാൻ സബ്നെറ്റ് സ്പ്ലിറ്റ് ലിസ്റ്റിൽ ഇടുക, പിന്നീട് ഫിൽട്ടറിൽ ആ സേവനത്തിന് മാത്രം അനുവാദം നൽകുക. റൂട്ട് ലിസ്റ്റ് വിശാലമാക്കുന്നത് ഒന്നും അധികാരപ്പെടുത്തുന്നില്ല, ചുരുക്കുന്നത് നിർബന്ധിത നടപടിയല്ല.
ഇന്റർഫേസ് ACL വഴിയിൽ ഉണ്ടോ എന്ന് പരിശോധിക്കുക
ഡീക്രിപ്റ്റ് ചെയ്ത ദൂരസ്ഥ ആക്സസ് ട്രാഫിക് ആളുകൾ കരുതുന്നതുപോലെ എപ്പോഴും പുറം ഇന്റർഫേസ് ACL-ലൂടെ കടന്നുപോകുന്നില്ല. sysopt connection permit-vpn സജീവമായിടത്ത്, ASA ആ ട്രാഫിക്കിന് തന്റെ രേഖപ്പെടുത്തിയ VPN ഒഴിവാക്കൽ പ്രയോഗിക്കുന്നു, ബാധകമായ VPN ഫിൽട്ടറുകൾ അതിനുശേഷവും പ്രാബല്യത്തിലുണ്ട്. ക്രമീകരണം show run all sysopt ഉപയോഗിച്ച് പരിശോധിക്കുക, ടോപ്പോളജി ഡയഗ്രാമിൽ നിന്ന് അനുമാനിക്കുന്നതിനു പകരം.
ഏതായാലും, ലക്ഷ്യ ഹോസ്റ്റിന്റെ സ്വന്തം ഫയർവാളും ആപ്പിന്റെ അംഗീകാരവും വഴിയിൽ തുടരുന്നു. TCP 443 അനുവദിക്കുന്ന ASA നിയമം ആപ്പ് ഉപയോക്താവിനെ സ്വീകരിക്കാൻ നിർബന്ധിക്കുന്നില്ല.
നിരസിക്കപ്പെട്ട കണക്ഷനോടെയും മാറ്റം സ്വീകരിക്കുക
അനുവദിച്ച ഒരു പരീക്ഷ മാത്രം വളരെ കുറച്ചേ തെളിയിക്കുന്നുള്ളൂ, കാരണം ഫിൽട്ടർ ഉണ്ടായാലും ഇല്ലെങ്കിലും പ്രവർത്തിക്കുന്ന ടണൽ അതേ ആദ്യ പാക്കറ്റ് സൃഷ്ടിക്കുന്നു. ക്ലയന്റിൽ നിന്ന് ഉദ്ദേശിച്ച സേവനം തുറക്കുക, പിന്നീട് അടച്ചിരിക്കേണ്ട ഒരു ലക്ഷ്യം പരീക്ഷിച്ച് അത് ശരിയായ കാരണത്താൽ പരാജയപ്പെടുന്നു എന്ന് സ്ഥിരീകരിക്കുക.
ടിക്കറ്റ് അടയ്ക്കുമ്പോൾ നാല് വസ്തുതകൾ രേഖപ്പെടുത്തുക: സ്വീകരിച്ച ഐഡന്റിറ്റി, സെഷൻ യഥാർത്ഥത്തിൽ ലഭിച്ച പോളിസിയും ഫിൽട്ടറും, സ്പ്ലിറ്റ് ലിസ്റ്റിലെ ലക്ഷ്യങ്ങൾ, ഉപയോക്താവിന് എത്താൻ അനുവാദമുള്ള റിസോഴ്സ്. ഈ നാലും റൂട്ട് ലിസ്റ്റ് ഫയർവാളാക്കി മാറ്റാതെ ട്രാഫിക് എവിടെ നിയന്ത്രിക്കുന്നു എന്ന് വിശദീകരിക്കുന്നു.
ഫിൽട്ടർ അനുവദിച്ചതിനുശേഷവും സേവനം നിരസിക്കുന്നുവെങ്കിൽ ഹോസ്റ്റിലേക്ക് പോകുക: ശ്രവണ വിലാസം, ഹോസ്റ്റ് ഫയർവാൾ, ആപ്പിന്റെ സ്വന്തം ഉപയോക്തൃ മാപ്പിംഗ്. അപ്പോൾ ടണൽ തന്റെ ജോലി ചെയ്തു, ASA-യിലെ കൂടുതൽ മാറ്റങ്ങൾ അപകടസാധ്യത മാത്രം കൂട്ടുന്നു.