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 போக்குவரத்து அமைப்புகள் அவற்றின் சொந்த முகவரி மாதிரியைப் பின்பற்றுகின்றன, எனவே அந்தப் பயன்முறையின் ஆவணங்களைப் படிக்காமல் இந்தப் பட்டியலை நகலெடுக்க வேண்டாம்.