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 ट्राफिक सेटिंग्ज त्यांचे स्वतःचे अ‍ॅड्रेसिंग मॉडेल अनुसरतात, म्हणून त्या मोडची कागदपत्रे न वाचता ही यादी कॉपी करू नका.