AWS Client VPN-இல் இடைவிடாத அணுகல்: இணைக்கப்பட்ட ஒவ்வொரு துணைக்குழியையும் தணிக்கை செய்யுங்கள்
சில AWS Client VPN அமர்வுகள் பயன்பாட்டின் VPC-ஐ அடைகின்றன, மற்றவை நேரம் முடிந்து போகின்றன. முதலில் ஒவ்வொரு இணைப்பின் VPC வழித்தட அட்டவணையுடன் முனை வழித்தடங்களை ஒப்பிடுங்கள்.
ஒரு பயனர் இணைக்கிறார், உள் பயன்பாட்டைத் திறந்து பதிலைப் பெறுகிறார்; அதே முனையில் உள்ள சக ஊழியர் அதே Wi-Fi-இல் உள்ள ஒரே மாதிரியான மடிக்கணினியிலிருந்து நேரம் முடிந்ததைப் பெறுகிறார். இந்த முறை ஒன்றுக்கு மேற்பட்ட இணைக்கப்பட்ட துணைக்குழிகளைக் கொண்ட client VPN முனையின் அடையாளம், அங்கு பாதைகள் சமமானவை அல்ல. நான் இதைக் கன்சோலிலிருந்து வெளிப்புறமாகப் பார்க்கிறேன், ஏனெனில் மீதமுள்ள விசாரணை மதிப்புள்ளதா என்பதை இரண்டு தாவல்கள் தீர்மானிக்கின்றன. கிளையண்ட் உள்ளமைவில் இதை விளக்கும் எதுவும் இல்லை.
முனையிலிருந்து தொடங்கி இணைப்புகளைப் பட்டியலிடுங்கள்
VPC கன்சோலில் Client VPN endpoints திறந்து, முனையைத் தேர்ந்தெடுத்து Associations தாவலைப் படியுங்கள். ஒவ்வொரு இணைப்பும் கிடைக்கும் மண்டலத்தில் ஒரு துணைக்குழி, இணைப்பு உருவாக்கப்படும்போது சேவை தேர்ந்தெடுக்கும் துணைக்குழியில் கிளையண்ட் இறங்குகிறது. துணைக்குழி ID-களையும் ஒவ்வொன்றும் உண்மையில் பயன்படுத்தும் வழித்தட அட்டவணையையும் குறித்துக்கொள்ளுங்கள், ஏனெனில் அந்த இரண்டு பட்டியல்களே நீங்கள் செய்யப்போகும் ஒப்பீடு.
முனை ஒரே ஒரு இணைப்பைக் காட்டினால், இந்தக் கோட்பாடு தவறு, கிளையண்டே சிறந்த சந்தேகநபர்.
முனை வழித்தட அட்டவணையை ஒவ்வொரு இணைப்புடனும் ஒப்பிடுங்கள்
அதே முனையில் Route table தாவலைத் திறங்கள். அங்குள்ள ஒவ்வொரு இலக்கு CIDR-க்கும் ஒரு இலக்கு உள்ளது, client VPN-இல் இலக்கு நுழைவாயில் அல்ல, இணைப்பு. AWS ஒவ்வொரு இணைக்கப்பட்ட துணைக்குழிக்கும் இலக்குப் பதிவைக் கோருகிறது, எனவே அவற்றில் ஒன்றை மட்டும் இலக்காகக் கொள்ளும் வழித்தடம் அணுகலை அமர்வு எங்கு இறங்கியது என்பதைச் சார்ந்ததாக்குகிறது. உங்களுக்கு உண்மையில் முக்கியமான இலக்கைச் சரிபார்த்து, பிறகு அதன் அனுமதி விதியைச் சரிபாருங்கள், ஏனெனில் வழித்தடம் பாதையை வழங்குகிறது, விதி யார் பயன்படுத்தலாம் என்பதைத் தீர்மானிக்கிறது.
இரண்டு அடுக்குகளையும் அட்டவணையாக்கிய பிறகு, தோல்வியைத் தவறவிடுவது கடினம்.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
பெரும்பாலான டிக்கெட்டுகளில் இரண்டாவது வரியே முழுப் பிழை. முனை வழித்தடம் உள்ளது, எனவே யாரும் மேலே பார்க்கவில்லை, மேலும் தொகுப்பு ஒரு தாவலுக்குப் பிறகு VPC-க்குள் இறந்துவிடுகிறது.
ஒவ்வொரு துணைக்குழியையும் அதன் பயனுள்ள வழித்தட அட்டவணை வரை பின்தொடருங்கள்
வெளிப்படையான வழித்தட அட்டவணை இணைப்பு இல்லாத துணைக்குழி VPC-இன் முதன்மை அட்டவணையை மரபுரிமையாகப் பெறுகிறது. உண்மையில் நடைமுறையில் உள்ள அட்டவணையைப் படியுங்கள், பெயர் சரியாகத் தெரியும் அட்டவணையை அல்ல, வரியின் லேபிளுக்குப் பதிலாக இலக்கையும் இலக்கு மதிப்பையும் ஒப்பிடுங்கள்.
AWS-இன் இடைவிடாத அணுகல் வழிகாட்டி இதை இணைப்புகள் முழுவதும் வழித்தட பரவல் என்று விவரிக்கிறது, அதுவே சரியான மாதிரி. முனை தொகுப்பை ஒரு துணைக்குழிக்கு எடுத்துச் செல்கிறது, அந்தத் துணைக்குழியின் அட்டவணை இன்னும் பயன்பாட்டு வலையமைப்பு எங்கே உள்ளது என்பதை அறிந்திருக்க வேண்டும்.
விடுபட்ட வரியை அதைச் சொந்தமாகக் கொண்ட அட்டவணையில் சரிசெய்யுங்கள். வேலை செய்யும் துணைக்குழியிலிருந்து முழு வழித்தட அட்டவணையையும் நகலெடுப்பது இதற்காக ஒருபோதும் நோக்கப்படாத இணையம், சாதனம் மற்றும் தனிமைப்படுத்தல் தேர்வுகளையும் நகலெடுக்கிறது, அந்தப் பரிமாற்றம் பொதுவாக நீங்கள் தொடங்கிய இடையூறை விட மோசமானது.
அனுமதி விதிகளைச் சரிபார்த்து, பிறகு திரும்பும் பாதை
அனுமதி விதிகள் ஒவ்வொரு இலக்கிற்கும் ஒவ்வொரு குழுவிற்கும் உள்ளன, வழித்தடங்களிலிருந்து தனித்து மதிப்பிடப்படுகின்றன. எல்லா இடங்களிலும் வழித்தடங்கள் இருந்தும் பயனரின் குழுவிற்கு விதி இல்லாத இலக்கு, ஆரோக்கியமாகத் தெரியும் வழித்தட அட்டவணையுடன் ஒரு கருந்துளை போல நடந்துகொள்கிறது.
திரும்பும் பாதையும் அதே கவனத்திற்குரியது. peering இணைப்பிற்கு பயன்பாட்டு VPC-இல் கிளையண்ட் CIDR-ஐ நோக்கித் திரும்பும் வழித்தடம், இரு முனைகளிலும் போக்குவரத்தை அனுமதிக்கும் பாதுகாப்புக் குழு விதிகள், அதை வீழ்த்தாத வலையமைப்பு ACL-கள் தேவை. ஒரு-திசை அணுகல், அதாவது ping வேலை செய்கிறது ஆனால் TCP கைகுலுக்கல் செய்யவில்லை, பொதுவாக VPN-ஐ அல்ல, ACL அல்லது பாதுகாப்புக் குழுவைச் சுட்டிக்காட்டுகிறது.
முனையின் சொந்தப் பாதுகாப்புக் குழுக்கள் இணைப்பின் மீள்திறன் வலையமைப்பு இடைமுகங்களில் அமைந்துள்ளன, எனவே கிளையண்ட் CIDR-இலிருந்து பயன்பாட்டு துறையை அனுமதிக்கும் விதி நிகழ்வுடன் மட்டுமல்ல, இணைப்புடனும் இணைக்கப்பட வேண்டும்.
ஒரு அதிர்ஷ்டமான கோரிக்கையால் அல்ல, மீண்டும் இணைப்பதன் மூலம் சரிபாருங்கள்
split tunnel-இல், இணைப்பு நிறுவப்படும்போது முனை வழித்தடங்கள் தள்ளப்படுகின்றன, எனவே மாறிய வழித்தடத் தொகுப்பு இணைந்திருக்கும் கிளையண்டை ஒருபோதும் அடையாது. ஆதரவு பெற்ற கிளையண்ட் வழியாகத் துண்டித்து மீண்டும் இணையுங்கள், பிறகு புதிய வழித்தடங்கள் இயந்திரத்தில் உள்ளதை உறுதிசெய்யுங்கள்.
இறுதியாக, இணைப்புப் பதிவைக் கிளையண்ட் பெற்ற முகவரியுடன் தொடர்புபடுத்துங்கள், ஒன்றுக்கு மேற்பட்ட இணைப்புகளைத் தொடுமளவுக்குத் தேர்வை மீண்டும் செய்யுங்கள். சரிசெய்தலுக்குப் பின் ஒரு வெற்றிகரமான கோரிக்கை ஒரு பாதை வேலை செய்கிறது என்பதை நிரூபிக்கிறது, டிக்கெட் மற்றொன்றைப் பற்றியது.