साइट-देखि-साइट 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 विकल्प पढ्नुहोस्

त्यो फिल्ड शून्य नभएपछि सर्भरले आफ्नो जवाफ giaddr मा रहेको ठेगानामा पठाउँछ भनी RFC 2131 भन्छ। त्यसैले फर्कने बाटो रिले ठेगानातर्फ राउट हुनुपर्छ, र टनेल नीतिले सर्भरबाट रिलेतर्फको दिशा अनुमति दिनुपर्छ। अनुरोध पार भयो तर प्रस्ताव कहिल्यै आएन भने हेर्ने ठाउँ यही हो।

त्यसपछि उस्तै सुनिने दुई कुरा छुट्याउनुहोस्। setroute किवर्डले ASA ले क्लाइन्टलाई दिने पूर्वनिर्धारित-राउटर विकल्प बदल्छ वा थप्छ। यसले ASA मा कुनै रुट राख्दैन र VPN नीति बनाउँदैन। ठेगाना पाएर पनि कतै नपुग्ने क्लाइन्टमा प्रायः टनेलको होइन, setroute वा स्कोपको समस्या हुन्छ। स्थिर गेटवे नभएको क्लाइन्टसँग परीक्षण गर्नुहोस् र प्रस्तावमा कुन पूर्वनिर्धारित राउटर देखिन्छ हेर्नुहोस्।

प्रस्ताव सुरुदेखि अन्त्यसम्म पढ्नुहोस्: प्रस्तावित ठेगाना, मास्क, पूर्वनिर्धारित राउटर, DNS र लिजको समय। त्यसपछि लिज नवीकरण हुन दिनुहोस्। एक पटक काम गरेर नवीकरणमा असफल हुने रिलेमा सामान्यतया स्कोप, लिज वा फर्कने बाटोको समस्या हुन्छ, जुन पहिलो आदानप्रदानले लुकाएको थियो।

«ठीक भयो» भन्नु अघि मैले के जाँच्छु

क्लाइन्टबाट सुरु गरेर ब्रोडकास्ट समात्नुहोस्, त्यसपछि ASA ले आफ्नै ठेगानालाई giaddr बनाएर त्यो रिले गरेको पुष्टि गर्नुहोस्। टाढाको तर्फ सर्भरले त्यो अनुरोध देख्यो र शाखासँग मिल्ने स्कोप छान्यो भन्ने पुष्टि गर्नुहोस्। शाखामा फर्किएर क्लाइन्टले प्रस्ताव स्वीकार्यो र आफ्नो गेटवेसम्म पुग्छ भन्ने पुष्टि गर्नुहोस्।

कुनै चरण चुप छ भने अर्को रिले वाक्य थप्नुको सट्टा सम्बन्धित नीति वा रुट जाँच्नुहोस्। कसैले उठाउने बेलासम्म रिले कन्फिग सामान्यतया ठीकै हुन्छ; बदलिएको कुरा टनेल नीति वा फर्कने रुट हो।

तीनै चरण परिवर्तन-अभिलेखमा लेख्नुहोस्: क्लाइन्टतर्फको इन्टरफेस, रिले ट्राफिक समेट्ने VPN नीति, र सर्भरको giaddr तर्फ फर्कने रुट। यही अभिलेखले अर्को शाखा निर्माणलाई डिबगिङ सत्रको सट्टा दोहोर्याउन सकिने काम बनाउँछ। अर्को इन्जिनियरलाई पहिले कुन कमाण्ड आउटपुट जम्मा गर्ने हो भन्ने पनि यसले बताउँछ।