સાઇટ VPN દ્વારા દૂરના ASA પર SSH: પગલું દર પગલું

તમે SSH ક્લાયન્ટને દૂરના ASAના આંતરિક સરનામા પર મોકલો છો અને કનેક્ટ થતાં જ સેશન મરી જાય છે. ફાયરવોલ તેની પોતાની સાઇટથી જવાબ આપે છે, ટનલ દેખાય છે, અને તેમ છતાં પોર્ટ 22 પર કંઈ સાંભળતું નથી. આમાંના મોટાભાગના કિસ્સાઓમાં પેકેટ ક્યારેય મેનેજમેન્ટ સ્વીકૃતિ સુધી પહોંચતું નથી, કારણ કે જે પાથ ચકાસાય છે તે ક્યારેય મેનેજમેન્ટ પાથ તરીકે ડિઝાઇન કરાયો નહોતો. નીચેનો પ્રવાહ ક્રમમાં અનુસરો અને નિષ્ફળતા આગળ વધવાનું બંધ કરશે.

તમે ખરેખર જે સરનામું સંચાલિત કરો છો તે પસંદ કરો

ત્રણ ડિઝાઇન સરખી દેખાય છે અને અલગ રીતે વર્તે છે: ASAના જાહેર VPN તરફના સરનામા સુધી પહોંચવું, IPsec દ્વારા આંતરિક ઇન્ટરફેસ સુધી પહોંચવું, અને સમર્પિત મેનેજમેન્ટ ઇન્ટરફેસ સુધી પહોંચવું. કોઈપણ પરવાનગીને સ્પર્શ કરતાં પહેલાં એડમિનિસ્ટ્રેટરનું સ્રોત સરનામું, ચોક્કસ ગંતવ્ય સરનામું અને TCP 22 લખી લો. પછીનું બધું તે જોડી પર આધાર રાખે છે.

બે સર્વર VLAN વહન કરતી ટનલ ફાયરવોલના ઇન્ટરફેસ સરનામાને અથવા એડમિનિસ્ટ્રેટરના મેનેજમેન્ટ સબનેટને જરાય વહન ન કરે. સાઇટ-ટુ-સાઇટ નીતિ માટે રસપ્રદ ટ્રાફિક યાદી તપાસો અને ખાતરી કરો કે ASAનું પોતાનું સરનામું ગંતવ્ય તરીકે દેખાય છે, ફક્ત તેમાંથી પસાર થતા સબનેટ જ નહીં.

ગંતવ્ય ફાયરવોલ પોતે હોવાથી, મેનેજમેન્ટ સ્વીકૃતિ ફોરવર્ડ કરેલા ટ્રાફિકના નિયમોથી અલગ છે. જે ACL ક્લાયન્ટને ASA પાછળના સર્વર સુધી પહોંચવા દે છે તે સ્વતંત્ર રીતે ઉપકરણનું SSH સંચાલન સક્ષમ કરતું નથી, અને ફોરવર્ડ નિયમ સુધારવાથી આ નિષ્ફળતા ખસશે નહીં.

management-access ઇન્ટરફેસ-વિશિષ્ટ છે

management-access આદેશ ASAને કહે છે કે VPN દ્વારા આવતા મેનેજમેન્ટ કનેક્શનને નામ આપેલા ઇન્ટરફેસ પર સ્વીકારે. તે રૂટ બનાવતું નથી, 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 વપરાશકર્તાઓને સમાન પ્રવેશ મળ્યો નથી, કારણ કે બધા માટે કામ કરતો મેનેજમેન્ટ માર્ગ તમે શરૂ કરેલી સમસ્યા કરતાં અલગ સમસ્યા છે.