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 उपकरण से भेजना है। पहला बदलता है कि इंटरनेट क्लाइंट के अनुरोध का स्रोत क्या देखता है; दूसरा किसी बीच के बॉक्स से होकर टनल को जीवित रखता है।
दोनों को मिला देना दो जानी-पहचानी विफलताएँ देता है। जो राउटर अपना ही टनल परिवहन अनुवादित करता है वह साथी संबंध तोड़ता है, जबकि जो राउटर आंतरिक प्रवाह का कभी अनुवाद नहीं करता वह निजी पते इंटरनेट पर भेजता है। नियम संपादित करने से पहले पढ़ें कि आप कौन-सा प्रवाह देख रहे हैं, और जाँचें कि बदलाव के बाद टनल चालू रही या नहीं। जो नियम ब्राउज़िंग ठीक करता है पर टनल गिरा देता है, उसने समस्या हल करने के बजाय जगह बदल दी है।
दोनों में से कोई विफलता दूसरे को बदलने से ठीक नहीं होती। नियम संपादित करने से पहले पढ़ें कि आप कौन-सा प्रवाह देख रहे हैं।
दोनों सीमाओं पर जाँचें
इंटरनेट सीमा पर एप्लिकेशन का स्रोत पढ़ें, और वापसी मार्ग पर बहाल गंतव्य। पहला बताता है कि अनुवाद हुआ या नहीं; दूसरा बताता है कि उलटा मैपिंग सही क्लाइंट तक लौटा या नहीं।
फिर उस क्लाइंट को परखें जो स्वीकृत स्प्लिट-टनल मार्ग इस्तेमाल करता है। वह क्लाइंट इस राउटर के इंटरनेट अनुवाद का कभी इस्तेमाल नहीं करता, इसलिए उसे अलग व्यवहार करना चाहिए, और यही अंतर पुष्टि करता है कि ट्रैफ़िक किस मार्ग से गया।
यदि दोनों क्लाइंट एक जैसा व्यवहार करते हैं, तो स्प्लिट-टनल नीति डिज़ाइन के मुताबिक नहीं चल रही। और अनुवाद नियम जोड़ने से पहले इसे ठीक करें, क्योंकि बिना इस्तेमाल वाले मार्ग के लिए लिखा नियम असली समस्या छिपा देता है।