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

એક પેકેટ, બે ટનલ

પ્રવાહને અનુસરો અને ક્રિયાઓનો ક્રમ રહસ્યમય રહેતો નથી. પેકેટ રિમોટ-એક્સેસ ટનલની અંદર આવે છે, ડિક્રિપ્ટ થાય છે અને ક્લાયન્ટ પૂલમાંથી સ્રોત ધરાવતું સામાન્ય IP પેકેટ બને છે. પછી ASA તેને રૂટ કરે છે, સાઇટ-ટુ-સાઇટ crypto ACL સાથે મેળવે છે, ફરીથી એન્ક્રિપ્ટ કરે છે અને બહારના ઇન્ટરફેસ પરથી શાખા તરફ મોકલે છે.

નીચેનાં સરનામાં ઉદાહરણરૂપ છે, પરંતુ આકાર મહત્વનો છે: સ્રોત પૂલ છે, ASA નું આંતરિક LAN નહીં.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

આમાંથી બે વસ્તુઓ નીકળે છે. ક્લાયન્ટને તેના રિમોટ-એક્સેસ કનેક્શન દ્વારા શાખાના પ્રીફિક્સ માટે રૂટની જરૂર છે, એટલે કે split-tunnel અથવા મોકલવામાં આવેલ રૂટ યાદીમાં તે સમાવવું પડશે. અને શાખાને ખબર હોવી જોઈએ કે ટ્રાફિક 10.77.0.20 પર અથવા તમારા NAT ડિઝાઇને બદલેલા સરનામા પર કેવી રીતે પાછો મોકલવો.

hairpin પરવાનગી વૈશ્વિક છે

લોકો જે આદેશ તરફ જાય છે તે છે same-security-traffic permit intra-interface. તે ટ્રાફિકને એક જ ઇન્ટરફેસમાં પ્રવેશવા અને બહાર નીકળવા દે છે, જે આ માર્ગને બરાબર જોઈએ છે. તે વૈશ્વિક સેટિંગ પણ છે: તેને સક્રિય કરવાથી અન્ય પ્રવાહોનું વર્તન બદલાય છે જે એક જ ઇન્ટરફેસને બે વાર પસાર કરે છે.

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

સુરક્ષાનો વ્યાપ અને NAT અલગ છે

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

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

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

એન્ક્રિપ્શન અધિકૃતિ નથી

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

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

hairpin કે બીજું ઇન્ટરફેસ

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

રૂટ-આધારિત ડિઝાઇન એ જ કન્ફિગરેશન પરનું ચેકબોક્સ નહીં, અલગ ગોઠવણ છે. જો તમે તેમાં જાઓ, તો ઉપરની નીતિ-આધારિત crypto ACL ચર્ચા લાગુ પડવાનું બંધ કરે છે અને રૂટિંગ ટેબલ પસંદગીનું કામ કરવા લાગે છે.

વાસ્તવિક ક્લાયન્ટથી ચકાસો

ASA પરથી શરૂ કરાયેલ પ્રોબનું સ્રોત સરનામું અલગ હોય છે અને તે પૂલથી શાખા સુધીનો માર્ગ વાપરશે નહીં. પાંચ-ટ્યુપલ ચકાસવા packet-tracer વાપરો, પછી વાસ્તવિક રિમોટ ક્લાયન્ટથી સાચું કનેક્શન ખોલો, કારણ કે ટ્રેસર અનુકરણ કરે છે અને ક્લાયન્ટના પોતાના રૂટિંગ અને નીતિનું સ્થાન લેતું નથી.

આયોજિત ફેરફાર પછી, કામ કરવું જોઈએ તેવી સેવા સાથે જોડાઓ, પછી નકારવી જોઈએ તેવી સાથે, અને પછી શાખાનો પરત માર્ગ ખાતરી કરો. Cisco ના VPN hairpin NAT ઉદાહરણો intra-interface પરવાનગી, NAT અને ACL ને દૃશ્ય રીતે અલગ રાખે છે, અને તે જ માનસિક મોડેલ છે જેની નકલ કરવા જેવી છે.

સંબંધિત લેખો