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 ટ્રાફિક સેટિંગ તેમના પોતાના સરનામાંકન મોડેલને અનુસરે છે, તેથી તે મોડના દસ્તાવેજ વાંચ્યા વગર આ યાદીની નકલ કરશો નહીં.