Client VPN क्लाइंट को पता देता है, हैंडशेक पूरा हो जाता है, और कनेक्शन फिर भी कहीं नहीं पहुँचता। सर्टिफ़िकेट या क्लाइंट संस्करणों को छूने से पहले एंडपॉइंट की अपनी रूट तालिका देखें। AWS Client VPN एंडपॉइंट तभी पैकेट आगे भेजता है जब उसके रूटों में से कोई गंतव्य प्रीफ़िक्स ढकता हो; अगर कोई मेल नहीं खाता, तो पैकेट एंडपॉइंट पर ही गिरा दिया जाता है और लक्ष्य होस्ट को कभी SYN नहीं दिखता।

यह फ़ॉरवर्डिंग का निर्णय है, प्रमाणीकरण का नहीं। यह टनल खड़ी होने के बाद और प्राधिकरण नियमों के मूल्यांकन के बाद होता है, इसलिए वैध सर्टिफ़िकेट और वैध समूह भी मृत कनेक्शन दे सकते हैं।

एंडपॉइंट केवल वही आगे भेजता है जो उसकी रूट तालिका ढकती है

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

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

क्लासिक असंगति पीयर्ड VPC है। कोई 10.20.0.0/24 के लिए रूट जोड़ता है जबकि होस्ट 10.20.4.0/24 में रहता है, इसलिए पता हर प्रविष्टि से बाहर रह जाता है। क्लाइंट पक्ष का कैप्चर बिना उत्तर के बार-बार SYN दिखाता है, और लक्ष्य के लॉग कुछ भी नहीं दिखाते।

सर्टिफ़िकेट से पहले रूट सूची पढ़ें

एंडपॉइंट के रूट अपने अलग ऑब्जेक्ट हैं, इसलिए VPC तालिका पढ़ने के बजाय उन्हें सीधे पूछें:

aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 --query 'Routes[].{Dest:DestinationCidr,Target:TargetSubnet,Origin:Origin}'

विफल हो रहे क्लाइंट से सटीक पता और प्रीफ़िक्स लंबाई लें, फिर कवरेज अक्षर-दर-अक्षर जाँचें। सबसे लंबे प्रीफ़िक्स का मेल लागू होता है, इसलिए संकरा रूट कहीं और इशारा करे तो चौड़ा रूट आपको नहीं बचाता।

for_each के साथ हर गंतव्य के लिए एक संसाधन

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

variable "client_vpn_routes" {
  type = map(string)
  default = {
    "10.20.0.0/16"  = "subnet-0aa11bb22cc33dd44"
    "172.31.0.0/20" = "subnet-0aa11bb22cc33dd44"
  }
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_routes
  client_vpn_endpoint_id = var.client_vpn_endpoint_id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = each.value
  depends_on             = [aws_ec2_client_vpn_network_association.this]
}

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

ऐसा एंडपॉइंट अपनाना जो आपने नहीं बनाया

अधिकतर टीमें कंसोल में बना एंडपॉइंट विरासत में पाती हैं, इसीलिए कोई रूट कोड मौजूद नहीं है। सिर्फ़ रूट Terraform में लाने के लिए दूसरा एंडपॉइंट खड़ा न करें।

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

पैकेट का उसी क्रम में पीछा करें जिसमें वह यात्रा करता है

जब रूट मौजूद है और कनेक्शन फिर भी विफल है, तो ऊपरी परत पर अनुमान लगाने के बजाय पथ क्रम में चलें।

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

हर apply में एक प्रीफ़िक्स बदलें, फिर रूट सूची दोबारा पढ़ें, और गंतव्य, अधिकृत करने वाला नियम तथा वापसी पथ साथ-साथ दर्ज करें। अस्वीकृत कनेक्शन को डीबग करने वाले अगले व्यक्ति को सर्टिफ़िकेट सिद्धांत से नहीं, इसी सूची से शुरू करना चाहिए।

संबंधित लेख