સાઇટ VPN કામ કરે છે, પણ ASA લોગ આવતા નથી: સ્રોત સરનામું તપાસો

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

શું આવે છે અને શું નહીં

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

ઉપકરણ પર બફર થયેલ ઘટના પણ રિમોટ ડિલિવરીનો પુરાવો નથી, કારણ કે લોગ સ્થાનિક રીતે હોઈ શકે છે અને ક્યારેય મોકલાયો ન હોઈ શકે. ટનલને દોષ આપતા પહેલાં કલેક્ટરના રિસીવ કાઉન્ટર તપાસો, કારણ કે ખાલી કાઉન્ટર વધતા કાઉન્ટર કરતાં અલગ તારણ છે.

બનાવેલ સંદેશ ફોરવર્ડ કરેલ ટ્રાફિક નથી

જ્યારે ASA પોતે પેકેટ બનાવે છે, ત્યારે તે LAN હોસ્ટનું પ્રોક્સી કરતું નથી. સ્રોત આઉટગોઇંગ ઇન્ટરફેસમાંથી કે સ્પષ્ટ સ્રોત સેટિંગમાંથી આવે છે, અને પેકેટ ઉપકરણ મોકલે છે તે બીજું બધું જેવી જ રૂટ શોધ અને નીતિ તપાસમાં પ્રવેશે છે. તેનો અર્થ એ છે કે VPN સિલેક્ટરમાં એ સરનામું હોવું જોઈએ જે ASA ખરેખર વાપરે છે, અને તે ઘણી વાર તેનું બહારનું ઇન્ટરફેસ હોય છે, અંદરનું સબનેટ નહીં.

જો નીતિ 10.20.0.0/24 ને બચાવે છે અને ASA તેના બહારના સરનામાને સ્રોત તરીકે વાપરે છે, તો લોગ પેકેટ કાં તો એવા કલેક્ટર તરફ ખુલ્લા ટેક્સ્ટમાં નીકળે છે જ્યાં પહોંચી શકતું નથી, અથવા ફેંકી દેવાય છે. કલેક્ટરની બાજુથી બંને પરિણામ એકસરખા દેખાય છે. એ જ તર્ક મેનેજમેન્ટ ટ્રાફિકને પણ લાગુ પડે છે, અને તેથી management-access અલગ ડિઝાઇન નિર્ણય છે.

ASA નેટવર્ક પર કયો સ્રોત મૂકે છે

સ્રોત ધારણાથી નહીં, પ્રયોગથી શોધો. પરીક્ષણ સંદેશ દરમિયાન આઉટગોઇંગ ઇન્ટરફેસ પર કેપ્ચર ખરેખરનો સ્રોત અને ગંતવ્ય બતાવે છે, અને તે કન્ફિગરેશનનાં ત્રણ વિભાગ વાંચવા કરતાં ઓછો સમય લે છે. તે સરનામાને ટનલના સ્થાનિક સિલેક્ટર સાથે સરખાવો.

કેટલાક વર્ઝન લોગિંગ સ્રોતને ઇન્ટરફેસ સાથે પિન કરવાની મંજૂરી આપે છે, અને તમારા વર્ઝનનું કમાન્ડ રેફરન્સ એ અધિકાર છે કે એ વિકલ્પ છે કે નહીં અને તે શું બદલે છે. બીજા Cisco પ્લેટફોર્મનો source-interface કમાન્ડ ASA પર આપોઆપ માન્ય નથી.

જો તમે સ્રોત બદલો, તો જાણી જોઈને બદલો અને નોંધ કરો, કારણ કે કલેક્ટરની ACL અને syslog પર બનેલ કોઈપણ સહસંબંધ તેના પર આધાર રાખે છે.

સિલેક્ટરને લોગ પ્રવાહ સાથે મેળવો

સ્રોત ખબર પડ્યા પછી ત્રણ વસ્તુ ક્રમમાં તપાસો: કયો ટ્રાફિક રસપ્રદ છે તે નક્કી કરતું ક્રિપ્ટો ACL કે નીતિ-આધારિત સિલેક્ટર, પેકેટ ક્યાં જાય તે નક્કી કરતો રૂટ, અને એન્ક્રિપ્શન પહેલાં સ્રોત ફરીથી લખી શકે એવો કોઈપણ NAT નિયમ. જે પેકેટ રૂટ સાથે મેળ ખાય પણ સિલેક્ટર સાથે નહીં તે ટનલ થ્રુ નથી થતું, અને NAT દ્વારા ફરીથી લખાયેલ પેકેટ બંનેમાંથી કોઈ સાથે મેળ ન ખાય શકે.

કલેક્ટરની બાજુની પોતાની જરૂરિયાતો છે: ASA ના સ્રોતને મંજૂરી આપતું ACL, પરત રૂટ, અને તમે કન્ફિગર કરેલ પોર્ટ પર સાંભળતી સેવા. પરિવહન અહીં પણ મહત્ત્વનું છે, કારણ કે આંશિક રીતે અવરોધિત માર્ગ પર TCP અને TLS લોગિંગ UDP કરતાં અલગ વર્તે છે. એક વખતે એક ઘટક બદલો, નહીં તો આગલું કેપ્ચર કહેશે નહીં કે કયો ફેરફાર મહત્ત્વનો હતો.

કલેક્ટર પર ચકાસો, પછી સ્રોત નોંધો

સંદેશ આવે છે તેની ખાતરી કરો, પછી ASA એ વાપરેલું સ્રોત સરનામું, તેને વહન કરનારું સિલેક્ટર અને જે તીવ્રતાથી તમે પરીક્ષણ કર્યું તે નોંધો.

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

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

LAN ટ્રાફિક વહન કરતી ટનલ ફાયરવોલના પોતાના સ્વરને વહન કરતી ટનલ નથી.