Google HA VPN से Cisco राउटर तक: पहले पीयर संसाधन की योजना बनाएँ
Cisco राउटर कॉन्फ़िगर करने से पहले दोनों Google इंटरफ़ेस, पीयर संसाधन, IKEv2 अनुबंध और हर BGP सत्र का नाम दें, फिर एक पीयर या दो चुनें।
Cisco से Google तक HA VPN में पहला निर्णय यह नहीं है कि कौन-सा क्रिप्टो प्रोफ़ाइल उपयोग करना है, बल्कि यह है कि एक स्थानीय उपकरण टनल समाप्त करेगा या दो। Google के HA VPN गेटवे में दो इंटरफ़ेस हैं, और हर एक संबंधित पीयर टनल की अपेक्षा करता है। इससे आपको दो टनल मिलती हैं, चाहे आपके पास दो राउटर हों या न हों, और अंतर यह है कि क्या एक ही बिजली आपूर्ति या सॉफ़्टवेयर अपग्रेड पूरा डिज़ाइन गिरा सकता है।
निर्णय एक पीयर उपकरण या दो है
लेआउट को तीन शर्तों के आधार पर चुनें: क्या आप स्थानीय विफलता बिंदु स्वीकार कर सकते हैं, क्या दोनों क्लाउड इंटरफ़ेस उपयोग करने होंगे, और आपके वर्कलोड कितना पुनःसंयोजन सहन करते हैं। यदि तीनों में से कोई एक कठोर आवश्यकता है, तो दो पीयर उपकरण ईमानदार उत्तर है।
कंसोल खोलने से पहले यह तय करें, क्योंकि उत्तर बदलता है कि वर्कशीट को कितनी टनल और BGP सत्रों का वर्णन करना है।
किसी भी कमांड से पहले वर्कशीट लिखें
वर्कशीट में पाँच पंक्तियाँ हैं, और हर एक को मालिक चाहिए:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
बाहरी पीयर संसाधन Google Cloud के भीतर आपके इंटरफ़ेस का वर्णन करता है, और इसे बनाना Cisco राउटर को कॉन्फ़िगर नहीं करता। यह असमानता उन लोगों को चौंकाती है जो अपेक्षा करते हैं कि क्लाउड कंसोल दोनों सिरों के लिए सत्य का स्रोत होगा। यह एक घोषणा है कि Google को क्या अपेक्षा करनी चाहिए, और राउटर को अभी भी उससे मेल खाना है। Google की पीयर गेटवे मार्गदर्शिका उस घोषणा को टनल, BGP, फ़ायरवॉल और IKE कार्य से जोड़ती है जो आपको अभी भी देना है।
यदि किसी पंक्ति का कोई मालिक नहीं है, तो संक्रमण के दौरान ड्यूटी पर जो भी हो वह उसे भर देगा।
तीन पता भूमिकाओं को अलग रखें
सार्वजनिक पीयर पते बाहरी IPsec विनिमय ले जाते हैं। आंतरिक BGP जोड़ी उस संरक्षित तार्किक कनेक्शन की है जो उसके ऊपर चलता है। विज्ञापित LAN और VPC प्रीफ़िक्स उस कनेक्शन के पीछे के वर्कलोड का वर्णन करते हैं। किसी VM के आंतरिक पते को बाहरी पीयर फ़ील्ड में कॉपी करना पहली दो भूमिकाओं को मिला देता है, और विफलता डेटा प्रविष्टि त्रुटि के बजाय बातचीत की समस्या जैसी दिखती है।
हर HA VPN इंटरफ़ेस के लिए एक, दो संबंधित पीयर टनल की योजना बनाएँ। दोनों क्लाउड इंटरफ़ेस का उपयोग अपने आप स्थानीय विफलता बिंदु को नहीं हटाता, क्योंकि दोनों टनल अभी भी एक ही चेसिस पर उतर सकती हैं।
वर्कशीट में हर मान के बगल में पता भूमिका लिखें। यही एक आदत अधिकांश मिलावट रोकती है।
वर्कशीट का Cisco संस्करण में अनुवाद करें
समर्थित पीयर दस्तावेज़ीकरण या अपने प्लेटफ़ॉर्म के लिए उपयुक्त Google कॉन्फ़िगरेशन टेम्पलेट से शुरू करें, फिर हर प्लेसहोल्डर को वर्कशीट से मिलाएँ। IKEv2 प्रमाणीकरण, ESP प्रस्ताव, PFS और टनल तथा रूटिंग मॉडल को एक साथ जाँचें, क्योंकि उनमें से एक में बेमेल आमतौर पर दूसरे में बेमेल के रूप में प्रकट होता है। जो समर्थित है उसे चुनने के लिए वास्तविक प्लेटफ़ॉर्म और सॉफ़्टवेयर संस्करण का उपयोग करें, क्योंकि Classic VPN रेसिपी एक अलग प्रारंभिक बिंदु है।
साझा रहस्य को स्क्रीनशॉट, टिकट अनुलग्नकों और सहायता नोट्स से दूर रखें। किसी केस टिप्पणी में चिपकाई गई पूर्व-साझा कुंजी क्रेडेंशियल का प्रकटीकरण है, समस्या-निवारण कलाकृति नहीं।
यदि टेम्पलेट और वर्कशीट असहमत हैं, तो रुकें और इसे कागज़ पर हल करें। उपकरण आपके लिए निर्णय नहीं करेगा।
हर टनल को उसके अपने साक्ष्य पर स्वीकार करें
HA VPN को BGP सत्र चाहिए, और एक सफल IKE बातचीत केवल पहला चरण स्थापित करती है। आंतरिक सत्र ऊपर आना चाहिए, इच्छित प्रीफ़िक्स का विज्ञापन और स्वीकृति होनी चाहिए, और वर्कलोड ट्रैफ़िक के आगे बढ़ने से पहले उपयोगी रूट तथा फ़ायरवॉल अनुमतियाँ मौजूद होनी चाहिए। इन्हें एक हरी बत्ती के रूप में दर्ज करना छिपा देता है कि कौन-सा चरण वास्तव में विफल हुआ।
हर टनल के लिए स्वीकृति साक्ष्य दर्ज करें: बातचीत किए गए सुरक्षा संगठन, BGP पड़ोसी स्थिति, अपेक्षित सीखे गए प्रीफ़िक्स और इच्छित वर्कलोड पथ। फिर नियंत्रित विफलता और पुनर्प्राप्ति जाँच चलाएँ, क्योंकि जो टनल कभी विफल नहीं हुई वह ऐसी टनल है जिसका पुनर्प्राप्ति पथ परीक्षण नहीं किया गया।
यह रिकॉर्ड अगली बार डिज़ाइन बदलने पर पुनः उपयोग योग्य है, और यह एक अंतर-संचालन तथा ऐसे कमांड अंश के बीच का अंतर है जिसकी मान्यताएँ खो गईं।