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