VPN ડિક્રિપ્ટ કર્યા પછી કયો ASA નિયમ ટ્રાફિક જુએ છે

પહેલી ધારણા જે છોડવી પડે તે એ છે કે ક્રિપ્ટો ACL એક એક્સેસ નીતિ છે. તે નથી. Cisco ASA પર એ યાદી એક સાંકડા પ્રશ્નનો જવાબ આપે છે: કયા પેકેટ રક્ષણને લાયક છે, અને એ જવાબ ડિક્રિપ્ટ થયેલું પેકેટ ફાયરવોલ પાછળના સર્વર સુધી પહોંચી શકે છે કે નહીં તે વિશે કંઈ કહેતું નથી. એક્સેસનો નિર્ણય પછી થાય છે — ઇન્ટરફેસ નીતિથી, ગ્રુપ-પોલિસી ફિલ્ટરથી, અથવા બંનેથી, ટનલ કેવી રીતે બની તેના આધારે.

ક્રિપ્ટો ACL બીજા પ્રશ્નનો જવાબ આપે છે

ક્રિપ્ટો ACL એ મેચ યાદી છે. તે ટનલને કહે છે કે બે પિયર વચ્ચે શું એન્ક્રિપ્ટ કરવું; જે પેકેટ તેની સાથે મેળ ખાતું નથી તે ફક્ત સુરક્ષિત રહેતું નથી. તેને વિસ્તારવાથી રક્ષણનો વ્યાપ બદલાય છે અને બીજું કંઈ નહીં.

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

બાયપાસ સેટિંગ ખરેખર શું છોડી દે છે

sysopt connection permit-vpn રક્ષિત ટ્રાફિકને ઇન્ટરફેસ ACL ચકાસણી છોડવા દે છે જે અન્યથા ઇનબાઉન્ડ બાજુએ લાગુ થયું હોત. તે VPN જમાવટ માટે સુવિધા છે અને તે ગ્લોબલ છે. તે ગ્રુપ પોલિસીને સ્પર્શતું નથી અને પ્રતિ-વપરાશકર્તા ઓથોરાઇઝેશન ફિલ્ટરને પણ સ્પર્શતું નથી.

ધારણાને બદલે વાસ્તવિક મૂલ્ય વાંચો: show running-config all sysopt સેટિંગ છાપે છે ત્યારે પણ જ્યારે તે ક્યારેય સ્પષ્ટ રીતે ગોઠવાયું ન હોય, અને ઘણી ગૂંચવણ ત્યાંથી જ શરૂ થાય છે.

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

ડિક્રિપ્ટ દિશામાં ફિલ્ટર વાંચો

LAN-to-LAN vpn-filter ટનલના દૃષ્ટિકોણથી લખાય છે, ઇન્ટરફેસના નહીં. દૂરનું નેટવર્ક સ્રોતની જગ્યાએ જાય છે અને સ્થાનિક નેટવર્ક ગંતવ્યની જગ્યાએ, કારણ કે ડિક્રિપ્ટ પછી પેકેટ એવું જ દેખાય છે. પછી એ જ ફિલ્ટર એન્ક્રિપ્શન પહેલાં વિરુદ્ધ દિશામાં ફરી મૂલ્યાંકન પામે છે, સરનામાંની ભૂમિકા ઊંધી થઈને.

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

કયું ફિલ્ટર ખરેખર જોડાયેલું છે તેની પુષ્ટિ કરો: show running-config group-policy અને show vpn-sessiondb detail l2l સાથે મળીને કહે છે કે સેશને શું વારસામાં મળ્યું. જે ACL ને કોઈ નીતિ સંદર્ભ નથી તેને સંપાદિત કરવાથી કંઈ બદલાતું નથી.

એક ACL ઑબ્જેક્ટને બે કામ માટે ફરી વાપરશો નહીં

ઇન્ટરફેસનો access-group અને vpn-filter એક જ પ્રકારના ઑબ્જેક્ટ જેવા લાગે છે અને જુદા જુદા બિંદુએ જુદી સરનામાં-દિશા સાથે મૂલ્યાંકન પામે છે. એક યાદી બંનેને સોંપવાથી એવા ફેરફારનું આમંત્રણ મળે છે જે ટનલ સુધારે અને ભૌતિક ઇન્ટરફેસને ચૂપચાપ ઢીલું કરે.

એમને અલગ રાખો, તેમના કામ પ્રમાણે નામ આપો, અને દિશાનો ફરક નામોમાં દેખાવા દો.

નવા જોડાણો સાથે, બંને દિશામાં ચકાસો

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

નિરીક્ષણને પણ ધ્યાનમાં લો. વિક્રેતાનું દસ્તાવેજીકરણ નોંધે છે કે VPN ફિલ્ટર પ્રારંભિક જોડાણ તપાસે છે, નિરીક્ષણ એન્જિન ખોલે તે દરેક ગૌણ જોડાણ નહીં, તેથી નિયંત્રણ ચેનલ અને તેનો સંબંધિત મીડિયા પ્રવાહ જુદો વ્યવહાર મેળવી શકે છે. જો એપ્લિકેશન પ્રોટોકોલ-જાગૃત હોય, તો એક પોર્ટ પ્રોબને બદલે વાસ્તવિક પ્રવાહ ચકાસો.

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