Cloud VPN की वे सीमाएँ जिन्हें आप ट्यून नहीं कर सकते: IKE लाइफ़टाइम और पीयर NAT

रिमोट डिवाइस को 24 घंटे का फ़ेज़ 1 लाइफ़टाइम दें और Cloud VPN टनल नीचे ही रहेगा, भले ही Google के पक्ष में सब कुछ ठीक से कॉन्फ़िगर हो। पीयर ऐसा मान प्रस्तावित कर रहा है जिसे रिस्पॉन्डर स्वीकार नहीं करेगा, इसलिए बातचीत या तो पूरी तरह विफल होती है या अनिश्चित काल तक फिर से शुरू होती रहती है। Cloud VPN फ़ेज़ 1 को 36,000 सेकंड यानी दस घंटे तक सीमित करता है, और यह सीमा ऐसी सेटिंग नहीं है जिसे आप बढ़ा सकें। बदलाव रिमोट डिवाइस पर ही होना चाहिए।

पीयर पूछता है, रिस्पॉन्डर तय करता है

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

केस खोलने से पहले टनल की अपनी स्थिति पढ़ें, क्योंकि विस्तृत स्थिति आमतौर पर वह चरण बताती है जो विफल हुआ:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

जो वापस आता है उसकी तुलना अपने गेटवे प्रकार और IKE संस्करण के समर्थित समुच्चय से करें, और वहाँ रहते हुए दोनों ट्रैफ़िक सिलेक्टर दर्ज करें। सिलेक्टर का मेल न खाना उतना ही टनल-नीचे का लक्षण देता है जितना एल्गोरिदम का मेल न खाना, और एल्गोरिदम के विपरीत यह आपको ठीक करना है।

36,000 सेकंड ही सीमा है

फ़ेज़ 1 36,000 सेकंड पर रुक जाता है। 86,400 पर सेट डिवाइस ऐसा कुछ माँग रहा है जिस पर रिस्पॉन्डर कभी सहमत नहीं होगा, और दोबारा कोशिश करने से उसका मन नहीं बदलता। रिमोट प्रस्ताव को सीमा के भीतर लौटाएँ और वही कॉन्फ़िगरेशन स्थापित हो जाएगा; यह असमानता ही पूरा पाठ है, क्योंकि आप अपना मान घटा सकते हैं और Google का मान नहीं बढ़ा सकते।

चुना गया मान डिज़ाइन नोट्स में लिखें। वरना अगला इंजीनियर 24 घंटे का प्रयोग दोहराएगा और उसी दीवार तक पहुँचेगा।

समर्थित समुच्चय हर गेटवे प्रकार और IKE संस्करण के लिए यहाँ प्रकाशित होता है: Cloud VPN अवलोकनमें, इसलिए सामान्य IKE गाइड के बजाय अपनी टोपोलॉजी वाला भाग पढ़ें।

समय-सारणी से गिरने वाली टनल

फ़ेज़ 2 अलग व्यवहार करता है: जब दोनों सिरे सहमत न हों, तो कुंजी-नवीनीकरण छोटे अंतराल का पालन करता है। जो पीयर असमानता को घातक मानता है वह टनल को गिरा देता है, इसलिए एक असमानता दो असंबंधित खराबियों जैसी दिख सकती है। कुंजी-नवीनीकरण की लय देखें, केवल पहला कनेक्शन नहीं। जो टनल ऊपर आकर फिर नियमित ताल में गिरती है, वह अक्सर रूटिंग दोष नहीं बल्कि लाइफ़टाइम की असमानता होती है।

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

समुच्चय गेटवे प्रकार से आते हैं

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

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

प्रति डिवाइस एक बाहरी पता

पीयर के बाहरी पते का मेल उसके आंतरिक पते से एक-से-एक होना चाहिए। अधिभारित PAT पूल काम नहीं कर सकता, क्योंकि एक ही सार्वजनिक पते के पीछे कई होस्ट रिस्पॉन्डर को उन्हें अलग करने का कोई तरीका नहीं देते। जहाँ कई होस्ट को पता साझा करना पड़े, वहाँ टनल को ऐसी जगह समाप्त होना चाहिए जो उन्हें अलग पहचान सके।

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