ASAની TACACS+ વિનંતીઓ તમારી શાખા VPN ટનલને કેમ છોડી જાય છે

શાખા ટનલ ચાલુ છે, વપરાશકર્તાઓ દૂરસ્થ TACACS+ સર્વર સામે પ્રમાણીકરણ કરે છે, અને ફાયરવોલનું પોતાનું લોગિન હજી પણ સમયસમાપ્ત થાય છે. કારણ ટનલમાં ખામી નથી: LAN-to-LAN ટનલ તે ટ્રાફિક વહન કરે છે જે તેના સિલેક્ટર સાથે મેળ ખાય છે, અને ASA પોતાના વિશે જે મેનેજમેન્ટ ટ્રાફિક ઉત્પન્ન કરે છે તે પોતાના સ્રોત સરનામા સાથેનો અલગ પ્રવાહ છે. મોટાભાગની ટીમો આ પરિવર્તન વિન્ડો દરમિયાન શોધે છે, જ્યારે એકમાત્ર એડમિનિસ્ટ્રેટર એકાઉન્ટ જ નિષ્ફળ જાય છે. ASA શરૂ કરેલા AAA સત્રને એવા પ્રવાહ તરીકે ગણો જે તમારે ડિઝાઇન કરવો પડે, પહેલેથી કામ કરતી કનેક્ટિવિટીની આડઅસર તરીકે નહીં.

ASA જ ક્લાયન્ટ છે, અને તેના પોતાના ટ્રાફિકને પોતાનો માર્ગ જોઈએ

જ્યારે ફાયરવોલ TACACS+ સર્વરનો સંપર્ક કરે છે, ત્યારે ફાયરવોલ બીજા કોઈપણ જેવો ક્લાયન્ટ છે, સિવાય કે કોઈએ જાણી જોઈને તેના માટે રૂટ ગોઠવ્યો નથી. તેના પેકેટ ઉપકરણ પરના ઇન્ટરફેસ સરનામેથી ઉદ્ભવે છે, તે ફોરવર્ડ થવાને બદલે સ્થાનિક રીતે ઉત્પન્ન થાય છે, અને વપરાશકર્તા ટ્રાફિકની જેમ તેને રૂટ, અનુવાદ અને નીતિ દ્વારા સુરક્ષિત કરવા પડે છે. વપરાશકર્તા સબનેટને સુરક્ષિત કરતી સાઇટ-થી-સાઇટ ટનલ તે મેનેજમેન્ટ સ્રોતને આપમેળે સુરક્ષિત કરતી નથી, કારણ કે ટ્રાફિક પસંદગી સરનામાં પર આધારિત છે, ઇરાદા પર નહીં.

તમે ધારો છો કે સર્વર જે સરનામું જોશે તે લખો. જો તમે તેને એક લીટીમાં કહી ન શકો, તો તમારી પાસે હજી ડિઝાઇન નથી.

aaa-server લીટીનું ઇન્ટરફેસ શણગાર નથી

ASA પર aaa-server હોસ્ટ એન્ટ્રી કૌંસમાં ઇન્ટરફેસ સંલગ્નતા લે છે, અને Ciscoનું AAA હોસ્ટ કમાન્ડ સંદર્ભ તેને એ ઇન્ટરફેસ તરીકે વર્ણવે છે જ્યાં પ્રમાણીકરણ સર્વર રહેલું છે. એ જ સંલગ્નતા વિનંતીને ઇન્ટરફેસ સાથે અને તે ઇન્ટરફેસ લાગુ કરે તે નીતિ સાથે જોડે છે. ઇન્ટરનેટ તરફ જોતા કોઈપણ ઇન્ટરફેસ દ્વારા તેને પસંદ કરવાથી, અથવા છેલ્લા માઇગ્રેશનથી જે હતું તે રહેવા દેવાથી, એવું સ્રોત સરનામું બને છે જેના માટે દૂરસ્થ સર્વર અને ટનલ કદી બનાવાયા નથી.

inside ત્યારે જ સાચો જવાબ છે જ્યારે નામ આપેલા ઇન્ટરફેસ પાસે એ સરનામું હોય જે તમારી ડિઝાઇન સ્રોત તરીકે વાપરવા માંગે છે. શાખાના ઉપકરણમાં આ ઘણી વાર હોય છે; અનેક ખાનગી સેગમેન્ટવાળા ઉપકરણમાં ન પણ હોય.

સંલગ્નતા બદલવી એટલે એન્ટ્રી ફરી બનાવવી

એ જ કમાન્ડ સંદર્ભ એક સંપાદન મર્યાદા દસ્તાવેજ કરે છે જે સ્થળાંતર વખતે લોકોને ફસાવે છે: હાલના હોસ્ટ પર ઇન્ટરફેસ બદલવા માટે હોસ્ટ એન્ટ્રી દૂર કરીને ફરી બનાવવી પડે છે. સંપાદિત દેખાતી કન્ફિગરેશન કદાચ અમલમાં ન આવી હોય, અને આગલી લોગિન કોશિશ હજી પણ જૂના સરનામેથી જ નીકળશે. તેને જગ્યાએ ફેરફાર તરીકે નહીં, પણ મૂળ એન્ટ્રીની નકલ સામે રાખીને કાઢી-ઉમેરવાનું કામ તરીકે ગોઠવો.

જો અનેક સર્વર વ્યાખ્યાયિત હોય, તો એક બદલો અને બાકીનાને સ્પર્શ કરતા પહેલાં તેને ચકાસો, જેથી એક ભૂલ એકસાથે બધા વહીવટી માર્ગ બંધ ન કરે.

સિલેક્ટર, અનુવાદ અને પરત માર્ગ સાથે ચકાસો

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

સર્વરની બાજુએ, ઉપકરણ ઓળખ, શેર કરેલ રહસ્ય અને વહીવટી નીતિ અલગ અલગ ચકાસો. TACACS+ પ્રમાણીકરણ, અધિકૃતિ અને હિસાબને અલગ ક્રિયાઓ તરીકે રાખે છે, તેથી પૂર્ણ થયેલી આપલે પછી આવતો ઇનકાર નીતિનો જવાબ છે, પરિવહન નિષ્ફળતા નથી. તેને નેટવર્ક સમસ્યા તરીકે વાંચવાથી તમે ખોટી જગ્યાએ શોધશો.

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

પોતાને લોક આઉટ કર્યા વિના ફેરફાર કરો

દૂરસ્થ વહીવટી પ્રમાણીકરણ બદલતી વખતે કન્સોલ અથવા સ્વતંત્ર મેનેજમેન્ટ માર્ગ વાપરો, અને નવો માર્ગ સાચું લોગિન ન લાવે ત્યાં સુધી મંજૂર સ્થાનિક વૈકલ્પિક રાખો. પછી સાંકડી રીતે ચકાસો: એક સર્વર, એક ઉપકરણ, બંને છેડે જોવા મળેલા સ્રોત સરનામા સાથે એક સફળ પ્રમાણીકરણ.

પ્રવાહને તેના પોતાના પૃષ્ઠ પર નોંધો: ઉદ્ભવ ઇન્ટરફેસ અને સરનામું, દૂરસ્થ સર્વર, સુરક્ષિત માર્ગ, અને અધિકૃતિ નીતિનો માલિક વ્યક્તિ. પછી પાછળનો ઇન્ટરફેસ કે ટનલ ફેરફાર બે પ્રવાહમાંથી કોને અસર કરે તે અનુમાન કર્યા વિના મૂલ્યાંકન કરી શકાય.