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 ट्राफिक सेटिङहरूले आफ्नै ठेगाना मोडेल पछ्याउँछन्, त्यसैले त्यो मोडको कागजात नपढी यो सूची प्रतिलिपि नगर्नुहोस्।