AWS Client VPN का क्लाइंट CIDR VPC रेंज से ओवरलैप नहीं हो सकता

AWS Client VPN एंडपॉइंट उस पूल से क्लाइंट पते बाँटता है जिसे आप चुनते हैं, और AWS एंडपॉइंट बनाने से पहले उस पूल को लक्ष्य नेटवर्क के सामने जाँचता है। जाँच यह नहीं है कि कोई सबनेट खाली दिखता है या नहीं। जाँच यह है कि पूल VPC रेंज से ओवरलैप करता है या नहीं, और उत्तर वही रहता है चाहे आज कोई EC2 इंस्टेंस उन पतों का उपयोग करे या न करे। ओवरलैप रेंज का प्रश्न है, आवंटन का नहीं।

पाँच जाँचें क्रम से करें। पहली असफल जाँच पर रुकें, क्योंकि कोई भी बाद का चरण पहले के निर्णय को सुधार नहीं सकता।

ओवरलैप रेंज की परीक्षा है, मुक्त पतों की परीक्षा नहीं

VPC के CIDR से शुरू करें, उस सबनेट से नहीं जिसे आप जोड़ना चाहते हैं। 172.20.0.0/22 का पूल 172.20.0.0/16 के VPC के भीतर आता है और तब भी अस्वीकार होता है जब कोई सबनेट उसे न रोके, क्योंकि ओवरलैप रेंज का गुण है, वर्तमान आवंटन का नहीं। फिर उन गंतव्यों को जोड़ें जहाँ एंडपॉइंट रूट करता है: पीयर VPC, ट्रांज़िट गेटवे और साइट-टू-साइट कनेक्शन से ऑन-प्रिमाइसेस रेंज। क्लाइंट को जिस भी रेंज तक पहुँचना पड़ सकता है, वह सूची में आती है।

उन्हें स्मृति से नहीं, खाते से इकट्ठा करें: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", साथ में उस सबनेट के रूट टेबल प्रविष्टियाँ जिसे आप जोड़ना चाहते हैं।

पूल का आकार बनाने से पहले तय होता है

AWS Client VPN पर /22 से /12 के बीच IPv4 क्लाइंट पूल स्वीकार करता है। /24 बहुत छोटा है, /8 दस्तावेज़ित रेंज से बाहर है, और दोनों गलतियाँ पूल को वर्कलोड सबनेट की तरह मापने से आती हैं। अपेक्षित समवर्ती क्लाइंट और मार्जिन से इसे मापें, फिर स्वीकार्य प्रीफ़िक्स तक गोल करें।

कंसोल में लिखने से पहले गणित जाँचें, क्योंकि गलत टाइप किया गया प्रीफ़िक्स बिना किसी चेतावनी के पूल का आकार बदल देता है:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

यह पतों की संख्या, प्रीफ़िक्स की लंबाई और यह छापता है कि उम्मीदवार VPC रेंज से टकराता है या नहीं, जो बदलाव विंडो के अंत में नेटमास्क के बारे में सोचने से तेज़ है।

रिज़ॉल्वर की अपनी पता भूमिका है

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

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

निर्माण के समय आप जिन चार फ़ील्ड से बंधते हैं

क्लाइंट IPv4 CIDR निर्माण के समय स्थिर होता है। DNS सर्वर बदलना, संबद्धता जोड़ना, सुरक्षा समूह बदलना, प्राधिकरण नियम संपादित करना या split-tunnel मार्ग बदलना सभी सामान्य संपादन हैं, और इनमें से कोई भी पूल का नाम नहीं बदलता। यही असमानता इसे समीक्षा योग्य बनाती है: सस्ती सेटिंग्स वही हैं जिन्हें आप बाद में बदलना चाहेंगे, और महँगी वह है जिससे आप पहले बंधते हैं। बदलाव विंडो की योजना से पहले एंडपॉइंट का विवरण पढ़ें।

पुनर्निर्माण मानने से पहले तैनात एंडपॉइंट का निरीक्षण करें। aws ec2 describe-client-vpn-endpoints पूल, DNS, split-tunnel फ़्लैग और संबद्धताएँ एक ही प्रतिक्रिया में लौटाता है, जो सामान्यतः पुनर्निर्माण को रद्द करने के लिए पर्याप्त है।

एंडपॉइंट को पैच करने के बजाय बदलें

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

वह सत्यापन पास होने तक पुराना एंडपॉइंट चालू रखें, और ऐसा प्रशासनिक मार्ग रखें जो नए पर निर्भर न हो।

एक सीमा उल्लेखनीय है: यह IPv4 क्लाइंट पूल को कवर करता है। Client VPN पर dual-stack और IPv6 ट्रैफ़िक सेटिंग्स अपना अलग एड्रेसिंग मॉडल मानती हैं, इसलिए उस मोड का दस्तावेज़ पढ़े बिना इस सूची की नकल न करें।