AWS Client VPN இணைந்துள்ளது, ஆனால் EC2 இன்னும் பதிலளிக்கவில்லை
இணைந்துள்ளது என்பது சான்றிதழ் அல்லது SAML உள்நுழைவு வேலை செய்தது மட்டுமே. அனுமதி விதிகள், endpoint வழிகள் மற்றும் பாதுகாப்புக் குழுக்கள் தனியார் ஹோஸ்டுக்கான பாதையின் ஒரு பகுதியை ஒவ்வொன்றும் காக்கின்றன.
என் மடிக்கணினி இணைந்துள்ளது எனக் காட்டியது. AWS Client VPN கிளையன்ட் அதன் பச்சை நிலையைக் காட்டியது, endpoint ஒரு அமர்வைப் பதிவு செய்தது, இருந்தும் தனியார் துணை வலையமைப்பில் உள்ள EC2 இன்ஸ்டன்ஸில் MongoDB துறையை என்னால் திறக்க முடியவில்லை. வெளிப்படையாக எதுவும் உடைந்திருக்கவில்லை: சான்றிதழ் செல்லுபடியாகும், சுயவிவரம் கன்சோலில் இருந்து வந்தது, சுரங்கப்பாதை போக்குவரத்தை எடுத்துச் சென்றது. தவறு என்னுடையது, ஏனெனில் நான் இணைந்துள்ளது என்பதை அனுமதிக்கப்பட்டது என்று படித்தேன்.
உள்நுழைவு சரியாக ஒரு கேள்விக்கு பதிலளிக்கிறது: இந்த அடையாளம் ஒரு அமர்வை நிறுவலாமா? அதன் பிறகு அனைத்தையும் உங்கள் சான்றிதழை ஒருபோதும் பார்க்காத தனி விதிகள் தீர்மானிக்கின்றன. அங்கீகாரம் பெறும் அமர்வும் வந்து சேரும் பொதியும் இரண்டு வெவ்வேறு வெற்றிகள், அவற்றுக்கு இடையிலான இடைவெளியில்தான் VPN இயங்குகிறது ஆனால் ஹோஸ்ட் அணுக முடியவில்லை என்கிற பெரும்பாலான புகார்கள் வாழ்கின்றன.
கீழே உள்ள சோதனைகள் நான் இப்போது பயன்படுத்தும் வரிசை.
இணைந்த அமர்வு உண்மையில் எதை நிரூபிக்கிறது
Handshake நேரத்தில் endpoint கிளையன்ட் சான்றிதழை அதன் trust store உடன் சரிபார்க்கிறது, அல்லது SAML உள்ளமைக்கப்பட்டிருந்தால் உலாவியை உங்கள் அடையாள வழங்குநருக்கு திருப்பிவிடுகிறது. அது தேர்ச்சி பெற்றால், கிளையன்ட் endpoint இன் கிளையன்ட் CIDR இலிருந்து முகவரியைப் பெறுகிறது, கன்சோல் செயலில் உள்ள இணைப்பைக் காட்டுகிறது. அந்தப் பரிமாற்றத்தின் எந்தக் கட்டத்திலும் 10.0.4.17 ஐ 27017 துறையில் அடைய முடியுமா என்று யாரும் கேட்பதில்லை.
ஒரு இலக்கிற்கான அனுமதி endpoint இல் தனி பொருள். ஒவ்வொரு ஓட்டமும் அனுமதி விதிகளுடன் ஒப்பிடப்படுகிறது, ஒவ்வொரு விதியும் இலக்கு CIDR ஐ விதி வழங்கப்பட்ட குழுவுடன் இணைக்கிறது. எந்த விதியும் இலக்கை மூடவில்லை என்றால், endpoint அமர்வை ஏற்றுக்கொண்டு போக்குவரத்தை தூக்கி எறிகிறது. பேனர் இல்லை, மீண்டும் இணைப்பு சுழற்சி இல்லை, மறுக்கப்பட்டது என்று சொல்லும் எதுவும் கிளையன்ட் இடைமுகத்தில் இல்லை.
அனுமதி விதியை VPC உடன் அல்ல, வளத்துடன் ஒப்பிடுங்கள்
விதிகளைப் பட்டியலிட்டு, இன்ஸ்டன்ஸுக்கு உண்மையில் உள்ள முகவரியின் அருகில் வையுங்கள்:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8வெளியீடு ஒவ்வொரு விதிக்கும் இலக்கு CIDR மற்றும் குழு ID ஐக் காட்டுகிறது. அதில் இரண்டு தோல்விகள் மறைந்துள்ளன. விதி 10.0.0.0/16 க்கு அனுமதி அளிக்கலாம், ஆனால் இன்ஸ்டன்ஸ் 10.1.0.0/16 இல் peer செய்யப்பட்ட VPC இல் இருக்கலாம்; peering வழி உள்ளது, ஆனால் இரண்டாவது வரம்பிற்கு யாரும் அனுமதி விதி எழுதவில்லை. அல்லது விதி, பயனர் அடைவில் உறுப்பினராக உள்ள ஆனால் endpoint மதிப்பிடும் குழுவில் இல்லாத அடைவுக் குழுவைச் சுட்டுகிறது.
இலக்கை மூடும் மிகக் குறுகிய விதியை எழுதுங்கள், இரண்டாவது CIDR உண்மையில் தேவைப்படும்போது மட்டுமே இரண்டாவது விதியைச் சேர்க்கவும். விரைவான தொடக்கத்திலிருந்து வரும் அகலமான 0.0.0.0/0 விதி வேலை செய்கிறது, அதனால்தான் அது உற்பத்தி வரை உயிர் பிழைத்து மாதிரியை மறைக்கிறது.
பொதி நகருமா என்பதை இரண்டு வழி அட்டவணைகள் தீர்மானிக்கின்றன
endpoint வழி இலக்கு CIDR ஐ endpoint இணைக்கப்பட்ட துணை வலையமைப்புகளில் ஒன்றுக்கு பொருத்துகிறது. அது பாதியளவு தூரம். துணை வலையமைப்பின் சொந்த வழி அட்டவணை பொதியை எப்படி அனுப்புவது என்பதை இன்னும் அறிய வேண்டும், இலக்கு peering இணைப்பு, transit gateway அல்லது site-to-site சுரங்கப்பாதை வழியாக அடையக்கூடிய ஆன்-பிரிமைசஸ் வரம்பின் பின்னால் இருக்கும் தருணத்தில் அது முக்கியமாகிறது.
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8இலக்கு வளத்தின் CIDR உடன் பொருந்தி, இலக்கு இணைக்கப்பட்ட துணை வலையமைப்பாக உள்ள வழியைத் தேடுங்கள். வழி இல்லாவிட்டால் சேர்க்கவும். இருந்து ஹோஸ்ட் இன்னும் அமைதியாக இருந்தால், இடைவெளி VPC பக்கத்தில் உள்ளது, எனவே இணைப்புத் துணை வலையமைப்பின் வழி அட்டவணையுடன் ஒப்பிடுங்கள்.
கிளையன்ட் பக்கத்தின் ஒரு அமைப்பு சுரங்கப்பாதையை உடைக்காமல் வழியமைப்பை உடைக்கிறது: route-nopull உள்ள சுயவிவரம். இந்த அறிவுறுத்தல் OpenVPN அடிப்படையிலான கிளையன்டை சேவையகம் தள்ளும் வழிகளை புறக்கணிக்கச் சொல்கிறது, எனவே இடைமுகம் endpoint இன் சொந்த முகவரியுடன் மட்டுமே எழுகிறது, இலக்கிற்கு வழியே இல்லை. Linux இல் ip route show அல்லது macOS இல் netstat -rn மூலம் tun இடைமுகம் வழியாக வழி உள்ளதா எனப் பாருங்கள். இல்லாவிட்டால், ஏற்றுமதி செய்யப்பட்ட சுயவிவரத்திலிருந்து route-nopull ஐ நீக்கி, தள்ளப்பட்ட வழிகள் பொருந்தும்படி மீண்டும் இணைக்கவும்.
பாதுகாப்புக் குழுக்கள் உங்கள் கிளையன்ட் முகவரியைப் பார்ப்பதில்லை
நான் அரை நாள் தவறாக வைத்திருந்த பகுதி இதுதான். துணை வலையமைப்புடன் இணைக்கப்பட்ட IPv4 endpoint க்கு, சேவை கிளையன்டின் மூல முகவரியை அந்தத் துணை வலையமைப்பில் உள்ள endpoint இன் வலையமைப்பு இடைமுக முகவரியாக மொழிபெயர்க்கிறது. இன்ஸ்டன்ஸை அடையும் பொதி உங்கள் கிளையன்ட் காட்டிய முகவரியைக் கொண்டு செல்வதில்லை, எனவே கிளையன்ட் தொகுப்பை, சொல்லுங்கள் 172.16.0.0/22, அனுமதிக்கும் பாதுகாப்புக் குழு விதி எதனுடனும் பொருந்தாது.
துறையை கிளையன்ட் CIDR இலிருந்து அல்ல, இணைப்பின் இடைமுகத்தில் இணைக்கப்பட்ட endpoint இன் பாதுகாப்புக் குழுவிலிருந்து அனுமதிக்கவும். குழுவைக் குறிப்பிடுவது முகவரியை கடினமாக குறியிடுவதை விட நீடித்தது, ஏனெனில் இடைமுக முகவரி உங்கள் கட்டுப்பாட்டில் இல்லை. வலையமைப்பு ACL நிலையற்றவை, எனவே விருப்ப உள்ளீடுகள் உள்ள இடங்களில் உள்வரும் மற்றும் வெளிச்செல்லும் இரு திசைகளும் ஓட்டத்தை அனுமதிக்க வேண்டும்.
இன்ஸ்டன்ஸின் தனியார் முகவரிக்கும் இணையுங்கள். பொது IP பொதியை VPC வெளியே எடுத்து வேறு விதிகளுடன் வேறு வழியாக உள்ளே கொண்டு வருகிறது, எனவே பொது முகவரியில் செய்யும் சோதனை தனியார் வழியைப் பற்றி எதுவும் சொல்லாது.
முதல் தோல்வியில் நிற்கும் தனிமைப்படுத்தல் வரிசை
இவற்றை வரிசையாகச் செய்து, ஒன்று தோல்வியடையும் இடத்தில் நிறுத்துங்கள். ஒவ்வொரு படியும் அனைத்து அடுக்குகளையும் அல்ல, ஒரு அடுக்கை விலக்குகிறது.
- அமர்வு எந்த அடையாளத்தைப் பயன்படுத்தியது, endpoint எந்தக் குழுவை மதிப்பிடுகிறது என்பதை உறுதிசெய்யுங்கள். ஒரு trust store இன் சான்றிதழ் அடைவிலிருந்து வரும் SAML உரிமைக்கோரலுக்கு இணையான ஒரே முதன்மையாளர் அல்ல.
- அனுமதி விதி அந்தக் குழுவிற்கான வளத்தின் CIDR ஐ மூடுகிறது என்பதை உறுதிசெய்யுங்கள்.
- endpoint வழி உள்ளது என்பதையும் அது இணைக்கப்பட்ட துணை வலையமைப்பை இலக்காகக் கொண்டிருப்பதையும், பின்னர் துணை வலையமைப்பின் வழி அட்டவணை மேலும் அனுப்ப முடியும் என்பதையும் உறுதிசெய்யுங்கள்.
- பாதுகாப்புக் குழு துறையை கிளையன்ட் தொகுப்பிலிருந்து அல்ல, endpoint இடைமுகத்திலிருந்து அனுமதிக்கிறது என்பதை உறுதிசெய்யுங்கள்.
- பயன்பாட்டுச் சிக்கலை கிளையன்ட் வழிச் சிக்கலிலிருந்து பிரிக்க, VPC க்கு உள்ளேயிருந்து, அதே துணை வலையமைப்பின் மற்றொரு இன்ஸ்டன்ஸில் SSM அமர்வைப் பயன்படுத்தி சோதியுங்கள்.
படிகள் உறுதியானதாக இல்லாதபோது நான் சார்ந்திருப்பது இந்த அட்டவணை:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
கணக்கின் இரண்டு விவரங்கள் அனுமதி தோல்வி போலத் தோன்றும் அறிகுறிகளை உருவாக்குகின்றன. ஒவ்வொரு பயனருக்கும் தனி கிளையன்ட் சான்றிதழ் தேவை; ஒன்றை இரண்டு இயந்திரங்களில் பங்கிட்டால் அமர்வுகள் ஒன்றையொன்று தள்ளும், முடிவு மறுப்பு அல்ல, மீண்டும் இணைப்பு சுழற்சி. புதிய endpoint உருவாக்கப்படும்போது, கன்சோல் ஒரு DNS பெயரைக் காட்டுகிறது, சில கிளையன்ட் பதிப்புகள் அதை endpoint பக்கத்தில் காட்டப்படும் சீரற்ற முன்னொட்டுடன் மட்டுமே ஏற்கின்றன, எனவே பெயரை மீண்டும் கட்டமைக்காமல் முழுப் பெயரையும் நகலெடுங்கள்.
ஐந்தாவது படி உங்களைத் தடுத்தால், எதையும் மாற்றுவதற்கு முன் endpoint இன் இணைப்புப் பதிவை எடுத்து அனுமதிப் பதிவுகளைப் படியுங்கள். பதிவு சரிபார்க்கப்பட்ட இலக்கையும் பொருந்திய அல்லது பொருந்தாத விதியையும் பெயரிடுகிறது, அது நான்கு அடுக்குக் கேள்வியை ஒரே பதிலாகச் சுருக்குகிறது.