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 उपकरणातून ढकलण्यासारखेच ऑपरेशन नाही. पहिले इंटरनेट क्लायंटच्या विनंतीचा स्रोत म्हणून काय पाहते ते बदलते; दुसरे मध्यस्थ उपकरणातून टनेल जिवंत ठेवते.
त्यांना गोंधळल्यास दोन ठराविक बिघाड होतात. स्वतःच्या टनेल ट्रान्सपोर्टचे भाषांतर करणारा राउटर पीअर नाते तोडतो, तर आतील प्रवाहाचे कधीही भाषांतर न करणारा राउटर खाजगी पत्ते इंटरनेटवर पाठवतो. नियम संपादित करण्यापूर्वी तुम्ही कोणता प्रवाह पाहत आहात ते वाचा, आणि बदलानंतर टनेल वर राहिला का ते तपासा. ब्राउझिंग सुधारून टनेल पाडणारा नियम समस्या सोडवण्याऐवजी हलवतो.
एकही बिघाड दुसरा बदलून सुटत नाही. नियम संपादित करण्यापूर्वी तुम्ही कोणता प्रवाह पाहत आहात ते वाचा.
दोन्ही सीमांवर तपासा
इंटरनेट सीमेवर अनुप्रयोग स्रोत आणि परतीच्या टप्प्यावर पुनर्संचयित गंतव्य वाचा. पहिले सांगते भाषांतर झाले का; दुसरे सांगते उलटे मॅपिंग योग्य क्लायंटकडे परत आले का.
मग मंजूर स्प्लिट-टनेल मार्ग वापरणारा क्लायंट तपासा. तो क्लायंट या राउटरचे इंटरनेट भाषांतर कधीही वापरत नाही, म्हणून त्याने वेगळे वागले पाहिजे, आणि फरक पुष्टी करतो की रहदारी कोणत्या मार्गाने गेली.
दोन्ही क्लायंट सारखे वागत असतील तर स्प्लिट-टनेल धोरण रचनेत सांगितलेले करत नाही. अधिक भाषांतर नियम जोडण्यापूर्वी ते दुरुस्त करा, कारण वापरात नसलेल्या मार्गासाठी लिहिलेला नियम खरी समस्या लपवतो.