ASA સાઇટ-ટુ-સાઇટ VPN દ્વારા આંતરિક સેવા પ્રકાશિત કરવી

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

તપાસ 1: ટનલ ઉત્પત્તિનું સરનામું સુરક્ષિત કરે છે

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

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

જો સુરક્ષિત શ્રેણી અને ઉત્પત્તિનું સરનામું મેળ ન ખાય તો અહીં અટકો.

તપાસ 2: શાખા કયો સ્રોત જોશે તે નક્કી કરો

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

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

તપાસ 3: વાસ્તવિક ઇન્ટરફેસ સામે અનુવાદ લખો

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

તમે બનાવો છો તે પથના ચાર ભાગ છે, અને ચારેય મેળ ખાવા જોઈએ:

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

તપાસ 4: ઍક્સેસ નિયમને પ્રકાશિત પોર્ટ સુધી મર્યાદિત કરો

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

તે જ સમયે નિયમોનો ક્રમ તપાસો. તમારા ચોક્કસ નિયમ ઉપર બેઠેલી વિશાળ મંજૂરી ચોક્કસ નિયમને અદૃશ્ય બનાવે છે.

તપાસ 5: એક વિનંતી અને તેના પ્રતિસાદને ટ્રેસ કરો

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

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

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