സൈറ്റ് VPN വഴി വിദൂര ASA-ലേക്ക് SSH: ഘട്ടം ഘട്ടമായി

നിങ്ങൾ SSH ക്ലയന്റിനെ വിദൂര ASA-യുടെ ആന്തരിക വിലാസത്തിലേക്ക് ചൂണ്ടുമ്പോൾ കണക്ട് ചെയ്യുമ്പോൾ തന്നെ സെഷൻ മരിക്കുന്നു. ഫയർവാൾ അതിന്റെ സ്വന്തം സൈറ്റിൽ നിന്ന് ഉത്തരം നൽകുന്നു, ടണൽ പ്രത്യക്ഷപ്പെടുന്നു, എന്നിട്ടും പോർട്ട് 22-ൽ ഒന്നും കേൾക്കുന്നില്ല. ഇത്തരം മിക്ക കേസുകളിലും പാക്കറ്റ് ഒരിക്കലും മാനേജ്മെന്റ് പ്രവേശനത്തിലെത്തുന്നില്ല, കാരണം പരിശോധിക്കുന്ന പാത ഒരിക്കലും മാനേജ്മെന്റ് പാതയായി രൂപകൽപ്പന ചെയ്തിട്ടില്ല. താഴെയുള്ള പ്രവാഹം ക്രമത്തിൽ പിന്തുടരുക, പരാജയം സ്ഥലം മാറ്റുന്നത് നിർത്തും.

നിങ്ങൾ യഥാർത്ഥത്തിൽ കൈകാര്യം ചെയ്യുന്ന വിലാസം തിരഞ്ഞെടുക്കുക

മൂന്ന് രൂപകൽപ്പനകൾ സമാനമായി തോന്നുന്നു, വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു: ASA-യുടെ പൊതു VPN-അഭിമുഖ വിലാസത്തിൽ എത്തുക, IPsec വഴി ആന്തരിക ഇന്റർഫേസിൽ എത്തുക, സമർപ്പിത മാനേജ്മെന്റ് ഇന്റർഫേസിൽ എത്തുക. ഏതെങ്കിലും അനുമതി തൊടുന്നതിന് മുമ്പ് അഡ്മിനിസ്ട്രേറ്ററുടെ ഉറവിട വിലാസം, കൃത്യമായ ലക്ഷ്യ വിലാസം, TCP 22 എന്നിവ എഴുതി വയ്ക്കുക. തുടർന്നുള്ളതെല്ലാം ആ ജോടിയെ ആശ്രയിച്ചിരിക്കുന്നു.

രണ്ട് സർവർ VLAN വഹിക്കുന്ന ഒരു ടണൽ ഫയർവാളിന്റെ ഇന്റർഫേസ് വിലാസമോ അഡ്മിനിസ്ട്രേറ്ററുടെ മാനേജ്മെന്റ് സബ്നെറ്റോ ഒട്ടും വഹിച്ചേക്കില്ല. സൈറ്റ്-ടു-സൈറ്റ് നയത്തിനായുള്ള താൽപ്പര്യ ട്രാഫിക് പട്ടിക പരിശോധിച്ച്, ASA-യുടെ സ്വന്തം വിലാസം ലക്ഷ്യമായി കാണുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക, അതിലൂടെ കടന്നുപോകുന്ന സബ്നെറ്റുകൾ മാത്രമല്ല.

ലക്ഷ്യം ഫയർവാൾ തന്നെയായതിനാൽ, മാനേജ്മെന്റ് പ്രവേശനം ഫോർവേഡ് ചെയ്ത ട്രാഫിക് നിയമങ്ങളിൽ നിന്ന് വേറിട്ടതാണ്. ക്ലയന്റുകളെ ASA-യുടെ പിന്നിലെ സർവറുകളിലേക്ക് എത്താൻ അനുവദിക്കുന്ന ACL സ്വതന്ത്രമായി ഉപകരണത്തിന്റെ SSH മാനേജ്മെന്റ് സജീവമാക്കുന്നില്ല, ഫോർവേഡ് നിയമം ശരിയാക്കിയാലും ഈ പരാജയം മാറില്ല.

management-access ഇന്റർഫേസ്-നിർദ്ദിഷ്ടമാണ്

management-access കമാൻഡ് VPN വഴി വരുന്ന മാനേജ്മെന്റ് കണക്ഷനുകൾ പേരിട്ട ഇന്റർഫേസിൽ സ്വീകരിക്കാൻ ASA-യോട് പറയുന്നു. അത് ഒരു റൂട്ട് സൃഷ്ടിക്കുന്നില്ല, SSH അനുമതി ചേർക്കുന്നില്ല, എല്ലാ ഇന്റർഫേസുകളിലും ഒരേസമയം ബാധകമല്ല. ലക്ഷ്യ ഇന്റർഫേസ് പേരിട്ടതല്ലെങ്കിൽ, പ്രാമാണീകരണത്തിന് മുമ്പ് തന്നെ കണക്ഷൻ ഉപേക്ഷിക്കുന്നു.

ഇവിടെ രണ്ട് ഒഴിവാക്കലുകൾ പ്രവർത്തിക്കുന്നു. മാനേജ്മെന്റിന് മാത്രമുള്ള ഇന്റർഫേസുകൾ ഈ സംവിധാനത്തിന് പുറത്താണ്, കൂടാതെ ASA 9.20 മാനേജ്മെന്റ് ഗൈഡ് ഡിഫോൾട്ട് CiscoSSH സ്റ്റാക്ക് VPN വഴിയുള്ള ഇന്റർഫേസ്-കുറുകെയുള്ള SSH പിന്തുണയ്ക്കുന്നില്ലെന്നും ASA SSH സ്റ്റാക്ക് പിന്തുണയ്ക്കുന്നുവെന്നും ചൂണ്ടിക്കാണിക്കുന്നു. റൂട്ടുകളിൽ സമയം ചെലവിടുന്നതിന് മുമ്പ് വിന്യസിച്ച പതിപ്പിലെ സജീവ സ്റ്റാക്ക് ഉറപ്പാക്കുക.

ലോഗിൻ പ്രോംപ്റ്റിന് മുമ്പ് നാല് ഗേറ്റുകൾ

ക്ലയന്റും ഉപയോക്തൃനാമ പ്രോംപ്റ്റും തമ്മിൽ നാല് സ്വതന്ത്ര ഗേറ്റുകളുണ്ട്: മാനേജ്മെന്റ് ജോടിക്കുള്ള റൂട്ട്, ടണൽ പൊരുത്തം, ASA വിലാസത്തിലേക്ക് TCP 22 അനുവദിക്കുന്ന ഇന്റർഫേസ് ACL, അഡ്മിനിസ്ട്രേറ്ററുടെ ഉറവിടം ഉൾക്കൊള്ളുന്ന ssh അനുമതി, ആ ഉപയോക്താവിനുള്ള AAA പ്രാമാണീകരണം. ഏത് ഗേറ്റ് അടഞ്ഞുവെന്ന് ക്ലയന്റിനോട് പറയാതെ അവയിലേതിനും പാക്കറ്റ് ഉപേക്ഷിക്കാം.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഏത് ഗേറ്റ് പരാജയപ്പെടുന്നുവെന്ന് കാണാൻ packet-tracer ഉപയോഗിക്കുക: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. ട്രെയ്സ് ACL, NAT ഘട്ടം, to-the-box തീരുമാനം എന്നിവ പേരിടുന്നു, ഇത് സാധാരണയായി റൂട്ടിംഗ് പ്രശ്നത്തെ പ്രവേശന പ്രശ്നത്തിൽ നിന്ന് വേർതിരിക്കാൻ മതിയാകും.

ഇടുങ്ങിയ അനുമതി എഴുതുക, വിശാലമായതല്ല

അനുമതി അംഗീകൃത അഡ്മിനിസ്ട്രേറ്റീവ് സബ്നെറ്റിലേക്കും ടണൽ ട്രാഫിക് സ്വീകരിക്കുന്ന ഇന്റർഫേസിലേക്കും പരിമിതപ്പെടുത്തുക: ssh 10.10.5.0 255.255.255.0 inside. പുറം ഇന്റർഫേസിൽ എല്ലാ ഉറവിടങ്ങളും തുറക്കുന്നതിന് പകരം aaa authentication ssh console LOCAL പോലുള്ള ഒരു പ്രാമാണീകരണ രീതിയും പേരിട്ട ലോക്കൽ അക്കൗണ്ടും അതിനൊപ്പം ചേർക്കുക.

ഇന്റർഫേസ് ACL-ഉം ssh അനുമതിയും പൊരുത്തപ്പെട്ട് നിർത്തുക. ACL തടയുന്ന സബ്നെറ്റിനുള്ള അനുമതി ഇപ്പോഴും പരാജയപ്പെടുന്നു, ഒപ്പമുള്ള ssh എൻട്രി ഇല്ലാതെ സബ്നെറ്റ് അനുവദിക്കുന്ന ACL അടുത്ത ഗേറ്റിൽ പരാജയപ്പെടുന്നു. രണ്ട് പ്രസ്താവനകളും ഒരേ പാതയെ വ്യത്യസ്ത പാളികളിൽ നിന്ന് വിവരിക്കുന്നു, അതിനാൽ പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനിൽ അവ ഒരുമിച്ച് പരിശോധിക്കുക.

പേരിട്ട ഹോസ്റ്റിൽ നിന്ന് പരിശോധിക്കുക, പിന്നീട് വീണ്ടും ഇടുക്കുക

നിങ്ങളുടെ മേശയിൽ നിന്നല്ല, പേരിട്ട മാനേജ്മെന്റ് ഹോസ്റ്റിൽ നിന്ന് പുതിയ സെഷൻ തുറക്കുക, കണക്ഷൻ ഏത് ഉറവിട വിലാസവും ഇന്റർഫേസും ഉപയോഗിച്ചുവെന്ന് ASA-യിൽ ഉറപ്പാക്കുക. സെഷൻ തുറന്നിരിക്കുമ്പോൾ സജീവ സെഷനുകളും പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷന്റെ SSH ഭാഗവും പരിശോധിക്കുക, പിന്നീട് അത് അടച്ച് പരിശോധനയ്ക്കായി ചേർത്ത ഏതെങ്കിലും താൽക്കാലിക അനുമതി നീക്കം ചെയ്യുക. സെഷൻ പ്രത്യക്ഷപ്പെട്ട് ലോഗിൻ ചെയ്ത ഉടൻ വീണാൽ, ബാക്കിയുള്ള പ്രശ്നം എത്തിച്ചേരാനുള്ള കഴിവല്ല, അധികാരമാണ്. അടുത്തയാൾ രോഗനിർണയം ആവർത്തിക്കാതിരിക്കാൻ മാറ്റ രേഖയിൽ ഇന്റർഫേസും ഉറവിടവും രേഖപ്പെടുത്തുക.

മാറ്റത്തിലുടനീളം കൺസോളോ സ്വതന്ത്രമായി അംഗീകരിച്ച മറ്റൊരു വീണ്ടെടുപ്പ് പാതയോ ലഭ്യമായി നിർത്തുക. സ്വകാര്യ പാത പ്രവർത്തിച്ചാൽ, പൊതു ഉറവിടങ്ങൾക്കും ബന്ധമില്ലാത്ത VPN ഉപയോക്താക്കൾക്കും അതേ പ്രവേശനം ലഭിച്ചിട്ടില്ലെന്ന് ഉറപ്പാക്കുക, കാരണം എല്ലാവർക്കും പ്രവർത്തിക്കുന്ന ഒരു മാനേജ്മെന്റ് പാത നിങ്ങൾ തുടങ്ങിയ പ്രശ്നത്തിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു പ്രശ്നമാണ്.