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