ASA साइट-टू-साइट VPN पर आंतरिक सेवा प्रकाशित करना

साइट-टू-साइट VPN के पीछे रहने वाली सेवा प्रकाशित करना पाँच विफलता बिंदुओं वाला एक काम है, और वे तय क्रम में विफल होते हैं। टनल ऊपर आती है, अनुवाद मेल खाता है, शाखा उत्तर देती है, और उत्तर उसी पथ से लौटता है। जब इनमें से कोई भी गलत हो, ब्राउज़र वही दिखाता है: अटका हुआ या रीसेट होता कनेक्शन। सूची को ऊपर से नीचे तक कीजिए और पहली विफल जाँच पर रुकिए।

जाँच 1: टनल मूल पते की रक्षा करती है

ऐसी टनल से शुरू करें जो पहले से ट्रैफ़िक पार कर रही है, फिर पुष्टि करें कि जिस पते को प्रकाशित करने की योजना है वह सुरक्षित परास के भीतर है। ASA पर वह परास क्रिप्टो ACL से या VTI के रूट से आता है, और उसे मूल के असली पते को ढकना चाहिए, न कि उस सबनेट को जो शाखा प्रबंधन के लिए उपयोग करती है। मूल को चूकने वाला सिलेक्टर आपको ऊपर खड़ी टनल और ऐसा प्रवाह देता है जो उसमें कभी प्रवेश नहीं करता।

अनुवाद छूने से पहले टनल काउंटर और रूट तालिका से इसकी पुष्टि करें। अगर हब से टनल के ज़रिए मूल तक नहीं पहुँचा जा सकता, तो इस सूची में आगे कुछ भी उसे ठीक नहीं कर सकता।

अगर सुरक्षित परास और मूल का पता मेल न खाएँ तो यहीं रुकिए।

जाँच 2: तय करें कि शाखा कौन-सा स्रोत देखेगी

शाखा या तो मूल क्लाइंट पता देखती है या अनूदित पता, और यही चुनाव वापसी पथ तय करता है। क्लाइंट पता सुरक्षित रखना मूल के लॉग में ज़्यादा साफ़ दिखता है, पर तब शाखा को सार्वजनिक क्लाइंट के उत्तर टनल से वापस भेजने पड़ते हैं; सामान्य इंटरनेट डिफ़ॉल्ट उन्हें दूसरी दिशा में भेजता है और कनेक्शन एक दिशा में मर जाता है। स्रोत का ऐसे पते में अनुवाद करना जिसे शाखा पहले से टनल से रूट करती है, यह शर्त हटा देता है।

अनुवाद यह भी बदलता है कि मूल क्या लॉग कर सकता है और स्रोत-आधारित नियम किससे मेल खा सकते हैं। अगर एप्लिकेशन को किसी अनुरोध के पीछे का व्यक्ति जानना है, तो उसका स्थान प्रमाणित रिवर्स प्रॉक्सी है, NAT का निर्णय नहीं।

जाँच 3: वास्तविक इंटरफ़ेस के मुताबिक अनुवाद लिखिए

ASA अनुवाद नियमों का मूल्यांकन क्रम में करता है और बताता है कि कौन मेल खाया, इसलिए नियम के भीतर का इंटरफ़ेस युग्म सजावटी नहीं है। बाहर से भीतर के पथ के लिए लिखा नियम ऐसे प्रवाह से मेल नहीं खाएगा जिसका प्रवेश और निकास आपकी मान्यताओं से अलग है।

जो पथ आप बना रहे हैं उसके चार भाग हैं, और चारों को मेल खाना चाहिए:

उस तालिका के परासों को प्लेसहोल्डर मानिए। महत्वपूर्ण यह है कि अनुवाद के बाद का टपल ऐसा पता हो जिसे शाखा टनल से स्वीकार करे, और NAT स्थिति में उलटा मैपिंग मौजूद हो ताकि बाहर जाते समय उत्तर बहाल हो।

जाँच 4: एक्सेस नियम को प्रकाशित पोर्ट तक सीमित रखिए

पोर्ट प्रकाशित कीजिए, होस्ट नहीं। जो नियम मूल को हर सेवा पर अनुमति देता है वह एक प्रकाशित एप्लिकेशन को मूल जो कुछ भी चलाता है उस तक के पथ में बदल देता है, जिसमें वह प्रबंधन इंटरफ़ेस भी शामिल है जिसे आपने जान-बूझकर इंटरनेट से बाहर रखा था। अनूदित स्रोत से मूल तक प्रकाशित पोर्ट की अनुमति दीजिए, और प्रशासनिक सेवाओं को उनके केवल-VPN पथ पर रहने दीजिए।

उसी समय नियमों का क्रम जाँचिए। आपके विशिष्ट नियम के ऊपर बैठी व्यापक अनुमति विशिष्ट नियम को अदृश्य बना देती है।

जाँच 5: एक अनुरोध और उसके उत्तर का पता लगाइए

ब्राउज़र से शुरू न कीजिए, क्योंकि ब्राउज़र छिपाता है कि कौन-सा भाग विफल हुआ। हब पर प्रवाह का पता लगाइए और कुछ भी बदलने से पहले परिणाम पढ़िए।

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

ट्रेस बताता है कि कौन-सा अनुवाद मेल खाया, किस एक्सेस नियम ने प्रवाह को अनुमति दी या अस्वीकार किया, और क्या पैकेट टनल में रूट हुआ। अगर वह दिखाए कि प्रवाह ऐसे इंटरफ़ेस से निकल रहा है जिसकी आपको अपेक्षा नहीं थी, तो NAT नियम का इंटरफ़ेस युग्म गलत है। अगर वह अस्वीकृति दिखाए, तो नियमों का क्रम गलत है। अगर वह टनल तक पहुँचे पर मूल कभी उत्तर न दे, तो समस्या शाखा का वापसी पथ है।

फिर बाहर से एक वास्तविक अनुरोध भेजिए और पुष्टि कीजिए कि उत्तर उसी टनल से लौटता है। प्रकाशित प्रविष्टि, अनुवाद, सुरक्षित पता युग्म और वापसी रूट को प्रकाशन अभिलेख के रूप में दर्ज कीजिए।