दो सेवाएँ, एक सार्वजनिक पता, और एक DNS नाम जो लगता है कि किसी पोर्ट को आरक्षित करता है। ऐसा नहीं करता। ASA पर VPN प्रविष्टि के बगल में DMZ सर्वर प्रकाशित करने से पहले प्रविष्टि ट्यूपल लिख लें और उन्हें क्रम में जाँचें; किसी मौजूदा सेवा से मेल खाने वाला पहला फ़ील्ड वही जगह है जहाँ योजना रुकती है. नीचे सब कुछ मानता है कि VPN उपकरण पर ही समाप्त होता है, किसी आंतरिक सर्वर पर नहीं।

कमांड लिखने से पहले पाँच फ़ील्ड लिखें

हर सार्वजनिक प्रविष्टि के लिए पता परिवार, सार्वजनिक पता, ट्रांसपोर्ट, सार्वजनिक पोर्ट और स्वामी दर्ज करें। स्वामी या तो ASA-स्थानीय सेवा है या अनूदित आंतरिक सर्वर। दो प्रविष्टियाँ एक पता साझा कर सकती हैं और फिर भी अलग ट्यूपल हो सकती हैं, और दो प्रविष्टियाँ आरेख में अलग दिख सकती हैं जबकि उपकरण पर टकराती हैं।

असली पोर्ट के लिए दूसरा स्तंभ रखें, वह जिस पर आंतरिक सर्वर वास्तव में सुनता है। सार्वजनिक पोर्ट और असली पोर्ट स्वतंत्र चुनाव हैं, और जिस क्षण आप उन्हें एक स्तंभ में मिला देते हैं, आप बाद में अपना अनुवाद पढ़ने की क्षमता खो देते हैं।

Public entryOwnerReal side
TCP 443 on the outside addressASA VPN listenerAppliance-local, no translation
TCP 8443 on the outside addressStatic PATDMZ server TCP 443
UDP 443 on the outside addressCheck the effective listenersPossibly the VPN data path

असली और मैप किए गए स्थानों को सही ढंग से पढ़ें

जिस सर्वर को जोड़ना चाहते हैं उससे नहीं, बल्कि उस ट्यूपल से शुरू करें जो आपके पास पहले से है। एक उदाहरणात्मक विभाजन स्वीकृत VPN प्रविष्टि को सार्वजनिक TCP 443 पर रखता है और सार्वजनिक TCP 8443 पर DMZ HTTPS सर्वर प्रकाशित करता है, जबकि वह सर्वर 443 पर सुनना जारी रखता है:

Public TCP 443  -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443

तैनात कमांड में असली सेवा और मैप की गई सेवा निश्चित स्थानों पर होती हैं, और उन्हें उलटने से टूटा हुआ नहीं बल्कि अलग मैपिंग का वर्णन होता है। काम करने वाला अनुवाद पहेली बनने का यह सबसे आम तरीका है: कॉन्फ़िगरेशन वैध है, यह बस कहीं और इंगित कर रहा है।

Cisco की ASA 9.16 NAT मार्गदर्शिका स्टैटिक PAT, इंटरफ़ेस-पता के उपयोग और असली बनाम मैप किए गए पोर्ट के अर्थ का दस्तावेज़ीकरण करती है। जिस रिलीज़ को आप वास्तव में चलाते हैं उसी का खंड पढ़ें; पुराने प्लेटफ़ॉर्म से याद किया गया कमांड पूरा वर्तमान कॉन्फ़िगरेशन नहीं है।

ट्रांसपोर्ट को आरक्षण का हिस्सा गिनें

TCP 443 और UDP 443 अलग ट्यूपल हैं, और यह अंतर आपको UDP मुफ़्त नहीं देता। एक VPN के अलग TLS और DTLS लिसनर हो सकते हैं, और अन्य कॉन्फ़िगर की गई सेवाएँ पहले से वह ट्रांसपोर्ट रख सकती हैं जो आप चाहते हैं। वेब पेज को पूरी VPN प्रविष्टि मानने के बजाय प्रभावी लिसनर और एक्सेस नीति की सूची बनाएँ।

उसी पते पर हल होने वाला दूसरा होस्टनाम भी ट्रांसपोर्ट-स्तर के टकराव को नहीं सुलझाता। DNS नाम-से-पता मैपिंग है, पोर्ट ब्रोकर नहीं, और PAT से सर्वर प्रकाशित करना VPN लिसनर को दूसरे पोर्ट पर ले जाने की वही क्रिया नहीं है।

अगर VPN प्रविष्टि को सचमुच स्थानांतरित होना है, तो चार चीज़ें साथ बदलती हैं: क्लाइंट प्रोफ़ाइल, सार्वजनिक URL, अपस्ट्रीम फ़िल्टरिंग और हर वह ट्रांसपोर्ट जिसका तैनाती उपयोग करती है। उन्हें एक-एक करके नहीं, एक ही विंडो में करें। उस सेवा को छूने से पहले जिससे आप उपकरण तक पहुँचते हैं, उपकरण तक एक अलग प्रबंधन मार्ग खुला रखें। दूसरे मार्ग के बिना, स्थानांतरण ऐसा बदलाव है जिसे आप बाहर से वापस नहीं ले सकते।

बाहर से नए कनेक्शन के साथ सत्यापित करें

प्रभावी एक्सेस नीति के अंतर्गत केवल इच्छित DMZ एप्लिकेशन की अनुमति दें, फिर मेल खाता अनुवाद क्रम, सर्वर का वापसी मार्ग और प्रमाणपत्र पर होस्टनाम जाँचें। PAT नेटवर्क गंतव्य बदलता है; यह एप्लिकेशन एक्सेस नहीं देता और ऐसा प्रमाणपत्र ठीक नहीं करता जो किसी अन्य होस्ट का नाम लेता है।

अधिकृत बाहरी होस्ट से नए कनेक्शन के साथ दोनों सेवाएँ जाँचें: VPN को अब भी स्थापित होना चाहिए, और DMZ अनुरोध को अपने इच्छित लिसनर तक पहुँचना चाहिए। स्थापित सत्र पुरानी स्थिति रख सकता है, इसलिए यह उस मैपिंग के बारे में कुछ सिद्ध नहीं करता जिसे आपने एक मिनट पहले बदला था।

उपकरण पर जो तैनात किया उसे प्रविष्टि सूची में अद्यतन करके चक्र बंद करें, जिसमें वह हर लिसनर शामिल है जिसे आपने बनाया नहीं बल्कि खोजा। उस पते पर अगली बार सेवा प्रकाशित करने वाला व्यक्ति आपकी तालिका से शुरू करेगा, और वहाँ की गलत पंक्ति यहाँ के गलत कमांड से अधिक महँगी है।

संबंधित लेख