ASA hairpin: ઇન્ટરનેટ એક્ઝિટ કે સાઇટ-ટુ-સાઇટ VPN લેગ?

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

બે લેગ, એક ઇન્ટરફેસ

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

બંનેને પહેલાં જે જોઈએ તે સમાન-ઇન્ટરફેસ પરવાનગી છે. તેના વિના ASA પેકેટ જે ઇન્ટરફેસ પર આવ્યું તેમાંથી આગળ મોકલવાનો ઇનકાર કરે છે, અને નિષ્ફળતા નીતિની સમસ્યા કરતાં રૂટિંગ સમસ્યા જેવી લાગે છે:

same-security-traffic permit intra-interface

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

લેગ A: ક્લાયન્ટને ઇન્ટરનેટ જોઈએ છે

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

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

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

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

લેગ B: ક્લાયન્ટને ખાનગી સાઇટ જોઈએ છે

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

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

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

નિયમનો ક્રમ પણ તપાસો. ઓળખ નિયમની ઉપરનો વિશાળ PAT નિયમ ખાનગી વિનિમયનું અનુવાદ ઓળખ નિયમનું મૂલ્યાંકન થાય તે પહેલાં જ કરી નાખશે, અને લક્ષણ NAT ભૂલને બદલે મેળ ખાતા SA વિનાની સાઇટ ટનલ હશે.

જે પરીક્ષણ તમને કહે છે કે તમે કયો લેગ બનાવ્યો

રૂપરેખા વાંચીને આશા રાખવાને બદલે ASA ના પોતાના પાથ મૂલ્યાંકનનો ઉપયોગ કરો. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed એક ફ્લો માટે NAT નિર્ણય, રૂટ અને ACL પરિણામ દર્શાવે છે; ખાનગી ગંતવ્ય સાથે તેને પુનરાવર્તિત કરો. જો NAT તબક્કો ખાનગીથી ખાનગી ફ્લો ફરી લખે, તો તમે એવા પેકેટ માટે લેગ A બનાવ્યો છે જેને લેગ B ની જરૂર હતી.

વધુ બે આદેશો ખાલીપો ભરે છે. show nat detail packet-tracer એ અનુસરેલો નિયમ ક્રમ છાપે છે, અને show crypto ipsec sa તમે અપેક્ષા રાખો છો તે જોડી માટે સિલેક્ટર છે કે નહીં તે દર્શાવે છે. ગુમ થયેલ SA એ સિલેક્ટર કે પીઅર રૂપરેખાની બાબત છે, NAT નિયમ સુધારી શકે તેવી વસ્તુ નથી.

દરેક લેગને તે જે ટ્રાફિકની સેવા કરે તેનાથી ચકાસો

લેગ A ને ક્લાયન્ટની સામાન્ય પબ્લિક વિનંતીથી સ્વીકારો, અને લેગ B ને ખરેખર અસ્તિત્વમાં હોય તેવા ખાનગી સંસાધનની વિનંતીથી સ્વીકારો. પછી દરેકને નકારાયેલા સંસાધન સાથે પુનરાવર્તિત કરો, કારણ કે “મંજૂર” અને “એક્સેસ પોલિસી દ્વારા મંજૂર” એક જ પુરાવો નથી, અને હબ પરથી ઉદ્ભવતું ping ક્લાયન્ટ પાથમાંથી કોઈપણને કસાવતું નથી.

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