IOS VPN એક્ઝિટ પર કઈ ઇન્ટરફેસને NAT અંદર અને બહારની ભૂમિકા મળે છે
વર્ચ્યુઅલ ઇન્ટરફેસથી અપલિંક સુધી ડિક્રિપ્ટ થયેલ ક્લાયન્ટ પેકેટને અનુસરો. અનુવાદ તે આંતરિક પ્રવાહ પર લાગુ પડે છે, ટનલના બહારના પરિવહન પર નહીં.
સંપૂર્ણ-ટનલ ઇન્ટરનેટ એક્ઝિટ આપતા રાઉટર બે કામ કરે છે, જે એક જેવા દેખાય છે. તે ટનલ સમાપ્ત કરે છે અને ડિક્રિપ્ટ થયેલ ક્લાયન્ટ પેકેટને ઇન્ટરનેટ પર મોકલે છે. ફક્ત બીજા કામને અનુવાદની જરૂર છે, અને અનુવાદ આંતરિક પ્રવાહ સાથે મેળ ખાવો જોઈએ. આ ભેદ જ નક્કી કરે છે કે કઈ ઇન્ટરફેસ NAT ભૂમિકાઓ ધરાવે છે અને નિયમમાં કઈ સરનામાં શ્રેણી દેખાય છે.
એક પેકેટને રાઉટરમાંથી અનુસરો
10.90.0.25 પરનો ક્લાયન્ટ લો, જે સાર્વજનિક HTTPS સેવા ખોલે છે. તે ગંતવ્ય ટનલમાં આવે કે નહીં તે ક્લાયન્ટની પોતાની નીતિનો નિર્ણય છે. એકવાર આવે, રાઉટર પેકેટ ડિક્રિપ્ટ કરે છે અને તેને વર્ચ્યુઅલ ઇન્ટરફેસને આપે છે, જ્યાંથી તે સાર્વજનિક અપલિંક તરફ રૂટ થાય છે.
તે વર્ચ્યુઅલ ઇન્ટરફેસ અનુવાદની અંદરની બાજુ છે. સાર્વજનિક અપલિંક બહારની બાજુ છે. જો ભૂમિકાઓ ઉલટાઈ જાય અથવા ન હોય, તો પેકેટ ક્યાં તો ખાનગી સ્રોત સાથે નીકળે છે, અથવા અનુવાદ પહેલાં જ ફેંકી દેવાય છે.
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
અનુવાદ નીતિને ક્લાયન્ટ પૂલ સાથે મેળવો
NAT નિયમે તે શ્રેણીનું નામ આપવું જોઈએ જે ક્લાયન્ટને ખરેખર મળે છે, ઓફિસ LAN નહીં જે કોઈક રીતે એ જ અપલિંક વહેંચે છે. ફક્ત સ્થાનિક સબનેટ આવરી લેતો નિયમ દૂરસ્થ ક્લાયન્ટને ચૂકી જાય છે, પછી ભલે બંને એ જ ઇન્ટરફેસમાંથી નીકળે.
ip access-list extended NAT-TUNNEL
permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overloadખાનગી સાઇટનાં અપવાદો અલગ રાખો. આંતરિક ગંતવ્યો તરફનો ટ્રાફિક તેનો મૂળ સ્રોત જાળવી રાખવો જોઈએ, નહીં તો ગંતવ્ય એવા સરનામે જવાબ આપશે જ્યાં પહોંચી શકાય નહીં, અને પરત માર્ગ રૂટિંગ લૂપ જેવો દેખાતો નિષ્ફળ જશે.
તૈનાત ડિઝાઇનની વાસ્તવિક ઇન્ટરફેસો પર ભૂમિકાઓ લાગુ કરો. જૂના Easy VPN જવાબમાંથી કોપી કરેલો Virtual-Template ટુકડો સંપૂર્ણ વર્તમાન રૂપરેખા નથી, અને વપરાતો ટનલ પ્રકાર નક્કી કરે છે કે કઈ ઇન્ટરફેસ ડિક્રિપ્ટ થયેલ પેકેટ મેળવશે.
બહારનું પરિવહન અને આંતરિક અનુવાદ અલગ રાખો
ડિક્રિપ્ટ થયેલ એપ્લિકેશન સ્રોતનો અનુવાદ કરવો એ IKE અથવા સુરક્ષિત પેકેટને ઉપર તરફ NAT ઉપકરણમાંથી પસાર કરવા જેટલી જ ક્રિયા નથી. પ્રથમ બદલે છે કે ઇન્ટરનેટ ક્લાયન્ટની વિનંતીના સ્રોત તરીકે શું જુએ છે; બીજું મધ્યવર્તી બોક્સમાંથી ટનલને જીવંત રાખે છે.
બંનેને ભેળવી દેવાથી બે જાણીતી નિષ્ફળતાઓ આવે છે. જે રાઉટર પોતાનું ટનલ પરિવહન અનુવાદિત કરે છે તે સાથી સંબંધ તોડે છે, જ્યારે જે રાઉટર આંતરિક પ્રવાહનો કદી અનુવાદ કરતું નથી તે ખાનગી સરનામાં ઇન્ટરનેટ પર મોકલે છે. નિયમ સંપાદિત કરતાં પહેલાં વાંચો કે તમે કયો પ્રવાહ જોઈ રહ્યા છો, અને તપાસો કે ફેરફાર પછી ટનલ ચાલુ રહી છે કે નહીં. જે નિયમ બ્રાઉઝિંગ સુધારે પણ ટનલ પાડી નાખે, તે સમસ્યા હલ કરવાને બદલે તેને ખસેડે છે.
બેમાંથી એકેય નિષ્ફળતા બીજાને બદલીને સુધરતી નથી. નિયમ સંપાદિત કરતાં પહેલાં વાંચો કે તમે કયો પ્રવાહ જોઈ રહ્યા છો.
બંને સીમાઓ પર ચકાસો
ઇન્ટરનેટ સીમા પર એપ્લિકેશનનો સ્રોત વાંચો, અને પરત માર્ગ પર પુનઃસ્થાપિત ગંતવ્ય. પ્રથમ કહે છે કે અનુવાદ થયો કે નહીં; બીજું કહે છે કે વ્યસ્ત મેપિંગ યોગ્ય ક્લાયન્ટ પાસે પાછું આવ્યું કે નહીં.
પછી મંજૂર સ્પ્લિટ-ટનલ માર્ગ વાપરતા ક્લાયન્ટની કસોટી કરો. તે ક્લાયન્ટ આ રાઉટરનો ઇન્ટરનેટ અનુવાદ કદી વાપરતું નથી, તેથી તેને અલગ રીતે વર્તવું જોઈએ, અને તે ફરક પુષ્ટિ કરે છે કે ટ્રાફિક કયા માર્ગે ગયો.
જો બંને ક્લાયન્ટ સરખી રીતે વર્તે, તો સ્પ્લિટ-ટનલ નીતિ ડિઝાઇન કહે છે તે કરતી નથી. વધુ અનુવાદ નિયમો ઉમેરતાં પહેલાં તેને સુધારો, કારણ કે વણવપરાયેલા માર્ગ માટે લખાયેલો નિયમ સાચી સમસ્યા છુપાવે છે.