Terraform में GCP Classic VPN: टनल को रूट-आधारित बनाएँ

Classic VPN में लेबल व्यवहार तय नहीं करता। रूट-आधारित का अर्थ है 0.0.0.0/0 स्थानीय सिलेक्टर, मेल खाते दूरस्थ सिलेक्टर और एक स्पष्ट रूट।

प्लान साफ़ तौर पर लागू होता है, टनल ऊपर आता है, और कंसोल इसे नीति-आधारित कहता है। ट्रैफ़िक फिर भी नहीं गुज़रता, और Terraform संसाधन में रूट-आधारित टॉगल खोजना कहीं नहीं पहुँचता क्योंकि ऐसा कोई फ़ील्ड नहीं है। Classic VPN में रूट-आधारित व्यवहार कोई मोड नहीं जिसे आप चुनते हैं। यह तब मिलता है जब स्थानीय ट्रैफ़िक सिलेक्टर 0.0.0.0/0 हो, दूरस्थ सिलेक्टर वे नेटवर्क सूचीबद्ध करें जो आप वास्तव में चाहते हैं, और एक रूट टनल की ओर इंगित करे। तीन चीज़ें, और लेबल उनके पीछे आता है।

मिथक: टनल मोड फ़ील्ड

कंसोल का लेबल दर्शाता है कि API सिलेक्टर में क्या देखता है। संसाधन में कुछ भी रूट-आधारित नहीं कहता, इसलिए सही मान पर सेट करने जैसा कुछ नहीं है।

उस फ़ील्ड को खोजने में समस्या का पहला घंटा चला जाता है, जबकि सिलेक्टर के मान पढ़ने में आख़िरी पाँच मिनट लगते हैं।

यहाँ रूट-आधारित का क्या अर्थ है

Google Classic VPN की रूट-आधारित टनलों को नीति-आधारित टनल के रूप में दस्तावेज़ित करता है जिनका स्थानीय सिलेक्टर 0.0.0.0/0 होता है। केवल दूरस्थ श्रेणियों के नाम दिए जाते हैं, और स्थानीय पक्ष को किसी भी पते की तरह माना जाता है। इसलिए आपके कॉन्फ़िगरेशन में चिह्न मोड नहीं, मान है। दोनों सिलेक्टर स्पष्ट रूप से लिखें और प्लान आउटपुट में उन्हें पढ़ें:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

उस स्निपेट में पीयर प्रीफ़िक्स उदाहरण है; आकार ही महत्वपूर्ण हिस्सा है।

रूट एक अलग ऑब्जेक्ट है

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

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

रूट को उसी मॉड्यूल में बनाएँ जिसमें टनल है, ताकि समीक्षा में दोनों अलग न हों।

पीयर पर सिलेक्टर प्रतिबिंबित करें

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

परिवर्तन समीक्षा के दौरान दोनों पक्षों के सिलेक्टर साथ-साथ छापें।

स्थिर पते को दो एप्लाई में बाँटें

आरक्षित पता और उसका संदर्भ देने वाली टनल एक ही एप्लाई में बनाना अस्थिरता का ज्ञात स्रोत है, क्योंकि फ़ॉरवर्डिंग नियम के उपयोग से पहले पता मौजूद होना चाहिए। पहले केवल पते का संसाधन लागू करें, फिर गेटवे, फ़ॉरवर्डिंग नियम और टनल जोड़कर दोबारा लागू करें। Terraform दूसरे रन में स्थिति से मौजूदा पता पढ़ता है और उसका पुनः उपयोग करता है। इसे छोड़ने पर टनल को हर एप्लाई में नया सार्वजनिक पता मिल सकता है, जो हर बार पीयर कॉन्फ़िगरेशन तोड़ देता है।

अब दो एप्लाई हर रिलीज़ में पीयर बदलने से सस्ते हैं।

लेबल नहीं, बातचीत सत्यापित करें

लागू करने के बाद तीन अलग तथ्य जाँचें: टनल स्थापित होने की सूचना देती है, रूट इच्छित अगली हॉप के साथ मौजूद है, और पीयर बताता है कि फ़ेज़ 1 और फ़ेज़ 2 दोनों ऊपर हैं।

टनल ऊपर होकर फ़ेज़ 2 नीचे होने का अर्थ है कि दोनों पक्ष सिलेक्टर पर सहमत नहीं हैं:

  • एक पक्ष ऐसा सबनेट सूचीबद्ध करता है जो दूसरा नहीं करता।
  • एक पक्ष ऐसा समुच्चय उपयोग करता है जिसे दूसरे ने सीमित किया है।
  • रूट मौजूद है पर किसी दूसरी टनल की ओर इंगित करता है।

Classic VPN एक ही टनल है जिसका SLA HA VPN से कम है, और HA VPN दो इंटरफ़ेस, दो टनल और अलग संसाधन प्रकारों वाला BGP उपयोग करता है। किसी क्लासिक उदाहरण को HA कॉन्फ़िगरेशन में कॉपी करके यह अपेक्षा करना कि सिलेक्टर फ़ील्ड वैसा ही व्यवहार करेंगे, एक अलग गलती है जिससे बचना चाहिए। टनल के फ़ील्ड स्वयं google_compute_vpn_tunnel संदर्भ में।

संबंधित लेख