साइट-टू-साइट VPN पर ASA DHCP रिले: चरण-दर-चरण मार्गदर्शिका

रिले तीन चरणों में काम करता है और केवल बीच वाला चरण ही VPN पार करता है। एक क्लाइंट शाखा सेगमेंट पर ब्रॉडकास्ट भेजता है, ASA उस ब्रॉडकास्ट को DHCP सर्वर के लिए यूनिकास्ट अनुरोध में बदल देता है, और सर्वर क्लाइंट के बजाय रिले पते को उत्तर देता है। चरणों को इसी क्रम में पूरा करें, और «रिले टूटा हुआ है» के अधिकांश मामले किसी अनुपस्थित नीति या गलत पढ़ी गई setroute पंक्ति तक सिमट आते हैं।

पहला चरण: क्लाइंट की ओर वाले इंटरफ़ेस पर रिले सक्षम करें

शाखा के ASA पर रिले उस इंटरफ़ेस का गुण है जो क्लाइंट की ओर देखता है। सर्वर को उसके पहुँच-योग्य इंटरफ़ेस के साथ वैश्विक रूप से घोषित किया जा सकता है, या उसी क्लाइंट-मुखी इंटरफ़ेस के अंतर्गत, ताकि रूटिंग तालिका निकास चुने। ये दोनों रूप परस्पर विनिमेय नहीं हैं, और गलत रूप की नकल करना वह पहली जगह है जहाँ मार्गदर्शिका भटक जाती है।

कुछ भी बदलने से पहले चालू कॉन्फ़िग जाँचें: किस इंटरफ़ेस पर रिले सक्षम है, कौन-सा सर्वर रूप मौजूद है, और क्या setroute क्लाइंट इंटरफ़ेस से जुड़ा है। यदि ASA किसी दूसरे सेगमेंट के लिए DHCP सर्वर भी चलाता है, तो रुकें और प्रतिबंधों की सूची पढ़ें; एक ही बॉक्स पर सर्वर और रिले दोनों सक्षम नहीं किए जा सकते।

रिले अपना क्लाइंट-मुखी पता गेटवे-पता फ़ील्ड में डालता है। सर्वर उसी पते को उत्तर देगा, इसलिए वह केवल स्थानीय नहीं, टनल के माध्यम से दूर के साइट से भी पहुँच-योग्य होना चाहिए।

दूसरा चरण: ASA द्वारा उत्पन्न ट्रैफ़िक को टनल से ले जाएँ

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

पुष्टि करें कि रुचि का ट्रैफ़िक ASA के रिले स्रोत और सर्वर के पते को कवर करता है, और वापसी दिशा भी अनुमत है। VTI-आधारित डिज़ाइन में रूटिंग निर्णय सरल होता है, परंतु VTI पर रिले समर्थन एक विशिष्ट रिलीज़ में आया; ASA की DHCP मार्गदर्शिका 9.14(1) बताती है, इसलिए पुराने उपकरण पर VTI उदाहरण की नकल करने से पहले इमेज जाँचें।

ASA से सर्वर तक ping अपने आप में बहुत कुछ सिद्ध नहीं करता। यह किसी दूसरे पथ से, दूसरे स्रोत पते के साथ, या ऐसी नीति के अंतर्गत सफल हो सकता है जिससे रिले के पैकेट मेल नहीं खाते।

तीसरा चरण: उत्तर और setroute विकल्प पढ़ें

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

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

प्रस्ताव को शुरू से अंत तक पढ़ें: प्रस्तावित पता, मास्क, डिफ़ॉल्ट राउटर, DNS और लीज़ समय। फिर लीज़ को नवीनीकृत होने दें। जो रिले एक बार काम करके नवीनीकरण पर विफल होता है, उसमें अक्सर स्कोप, लीज़ या वापसी पथ की समस्या होती है जिसे पहले आदान-प्रदान ने छिपा दिया था।

ठीक कहने से पहले मैं क्या जाँचता हूँ

क्लाइंट से शुरू करें और ब्रॉडकास्ट पकड़ें, फिर पुष्टि करें कि ASA ने उसे अपने पते के साथ giaddr के रूप में रिले किया। दूर की ओर पुष्टि करें कि सर्वर ने वह अनुरोध देखा और शाखा से मेल खाता स्कोप चुना। शाखा में लौटकर पुष्टि करें कि क्लाइंट ने प्रस्ताव स्वीकार किया और अपने गेटवे तक पहुँचता है।

यदि कोई चरण मौन है, तो एक और रिले कथन जोड़ने के बजाय संबंधित नीति या रूट जाँचें। किसी के एस्केलेट करने तक रिले कॉन्फ़िग आमतौर पर सही ही होता है; जो बदला है वह टनल नीति या वापसी रूट है।

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