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 जोडण्या आणि VPC च्या मालकीचे नसलेले on-premises उपसर्ग यांसाठी अतिरिक्त मार्ग आहेत। म्हणूनच तीन संबद्धता असलेला एंडपॉईंट कायदेशीरपणे सात गंतव्य नोंदी वाहू शकतो।

मार्ग जोडण्यापूर्वी 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 पूर्ण दिसतो। गटातील एका आणि बाहेरील एका वापरकर्त्यासह चाचणी करा।

एक उपसर्ग अयशस्वी झाल्यास, त्याची मार्ग नोंद अधिकृतता नियमाशी तुलना करा। अनुपस्थित अधिकृतता आणि अनुपस्थित मार्ग क्लायंट लॉगमध्ये सारखे दिसतात आणि वेगवेगळ्या संसाधनांमध्ये दुरुस्त होतात।