Terraform Client VPN मार्ग: सबनेट से अधिक CIDR के साथ

एक लैपटॉप Client VPN एंडपॉइंट से जुड़ता है, और terraform apply से अब भी रूट रिसोर्स पर विफल होता है। कॉन्फ़िगरेशन में आमतौर पर संबद्ध सबनेट से अधिक गंतव्य CIDR होते हैं, और रूट ब्लॉक इंडेक्स के साथ लक्ष्य चुनता है। यह मानता है कि दोनों संग्रह समांतर हैं। वे नहीं हैं, और विफलता समीक्षा के बजाय लागू करने के समय सामने आती है।

विफल होने वाले ऑब्जेक्ट का नाम बताइए

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

पहले संबद्धताएँ सूचीबद्ध करें: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0।

VPC के स्थानीय मार्ग को याद रखें

पहली संबद्धता पूरे VPC के लिए स्थानीय मार्ग जोड़ती है, इसलिए उस VPC की हर सबनेट रूट रिसोर्स के बिना ही पहुँच योग्य है। पीयर्ड VPC, Transit Gateway कनेक्शन और on-premises प्रीफ़िक्स के लिए अतिरिक्त मार्ग होते हैं जिनका VPC स्वामी नहीं है। इसलिए तीन संबद्धताओं वाला एंडपॉइंट वैध रूप से सात गंतव्य प्रविष्टियाँ रख सकता है।

मार्ग जोड़ने से पहले VPC के बाहर पड़ने वाले गंतव्यों की गिनती करें। यदि वह गिनती CIDR सूची से कम है, तो सूची ऐसी सबनेट बता रही है जिन्हें कोई मार्ग नहीं चाहिए।

इंडेक्स को मैप से बदलें

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

variable "client_vpn_destinations" {
  description = "Destination CIDR mapped to an associated subnet key"
  type        = map(string)
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_destinations
  client_vpn_endpoint_id = aws_ec2_client_vpn_endpoint.this.id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = aws_subnet.private[each.value].id

  lifecycle {
    precondition {
      condition     = contains(keys(aws_subnet.private), each.value)
      error_message = "Route target must be a subnet key in the associated map."
    }
  }
}

जब मैप संबद्धता सूची के पास हो, तो गंतव्य जोड़ने पर यह तय करना पड़ता है कि कौन-सी सबनेट उसे ले जाएगी। यही वह बातचीत है जिसे इंडेक्स छिपा रहा था।

एक अलग विफलता इंडेक्स त्रुटि के बजाय निरर्थक मान पैदा करती है। जहाँ उच्च-स्तरीय इंटरफ़ेस की अपेक्षा हो वहाँ निम्न-स्तरीय संरचना भेजने से API द्वारा पढ़े जाने वाले फ़ील्ड भरे नहीं रहते, और परिणामी CIDR अनुपयोगी हो जाता है। जब कोई स्ट्रिंग वहाँ पहुँचता है जहाँ किसी ऑब्जेक्ट की अपेक्षा हो, तो Terraform वही आकार दिखाता है। तर्क के प्रकार के लिए प्रोवाइडर स्कीमा देखें।

इसे किसी क्लाइंट से सिद्ध करें

लागू करने से पहले terraform validate और वास्तविक स्थिति के विरुद्ध योजना चलाएँ। इसके बाद सफल apply पर भरोसा करने के बजाय एंडपॉइंट की लक्ष्य-नेटवर्क सूची की मैप से तुलना करें।

स्वीकृति परीक्षण एक जुड़ा हुआ क्लाइंट है जो हर इच्छित प्रीफ़िक्स तक पहुँचता है।

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

जब कोई एक प्रीफ़िक्स विफल हो, तो उसकी रूट प्रविष्टि की प्राधिकरण नियम से तुलना करें। अनुपस्थित प्राधिकरण और अनुपस्थित मार्ग क्लाइंट लॉग में समान दिखते हैं और अलग-अलग रिसोर्स में ठीक किए जाते हैं।