endpoint 10.0.8.0/24 இல் உள்ளது, எனவே resolver 10.0.8.2 ஆக இருக்க வேண்டும். இதுவே நான் அதிகம் கேட்கும் வாதம், இது இருமுறை தவறு. Route 53 Resolver முதன்மை VPC IPv4 வரம்பு கூட்டல் இரண்டில் பதிலளிக்கிறது, அது 10.0.0.0/16 இன் VPC க்கு 10.0.0.2 ஆகும், endpoint எந்த subnet ஐப் பயன்படுத்தினாலும். இரண்டாவது தவறு அமைதியானது: endpoint இல் சரியான முகவரியை வைப்பதால் client இன் இயங்குதளம் அதை எப்போதாவது எதையாவது கேட்கும் என்று அர்த்தமல்ல. இரண்டு தவறுகளும் ஒரே அறிகுறியைத் தருகின்றன: பெயர் தீர்வு சில client களில் வேலை செய்கிறது, மற்றவற்றில் தோல்வியடைகிறது.

கட்டுக்கதை subnet தொடர்பிலிருந்து தொடங்குகிறது

தொடர்பு என்பது client இணைப்புகளுக்கான elastic network interfaces எங்கே உள்ளன என்பதைப் பற்றியது, எந்த resolver முகவரி உள்ளது என்பதைப் பற்றியது அல்ல. endpoint இன் subnet கள் client களுக்கு VPC க்குள் முகவரி தருகின்றன, அவற்றில் ஒவ்வொன்றும் தனக்கென resolver வைத்திருக்கவில்லை.

அந்த இரண்டு கருத்துகளைப் பிரித்தவுடன் கணக்கு மர்மமாக இருப்பது நிற்கிறது, சிக்கல் தீர்வு client பக்கம் நகர்கிறது, இந்த நிகழ்வுகளில் பெரும்பாலானவை உண்மையில் அங்கேயே முடிகின்றன.

முதன்மை VPC வரம்பிலிருந்து முகவரியைக் கணக்கிடுங்கள்

VPC இன் முதன்மை IPv4 CIDR ஐ எடுத்து network முகவரியில் இரண்டைச் சேர்க்கவும். 10.0.0.0/16 10.0.0.2 தருகிறது, 172.31.0.0/16 172.31.0.2 தருகிறது, இரண்டாம் நிலை வரம்பு உள்ள VPC resolver ஐ முதன்மையிலேயே வைத்திருக்கிறது. அந்த VPC க்குள் உள்ள 10.0.8.0/24 subnet அதை நகர்த்தாது. endpoint ஐத் தொடுவதற்கு முன் VPC ID அருகில் முகவரியை எழுதுங்கள், ஏனெனில் இந்த எண் VPC இன் பண்பு, இணைப்பின் பண்பு அல்ல.

VPC link-local முகவரி 169.254.169.253 இலும் பதிலளிக்கிறது. இந்த முகவரி VPC க்குள் இருந்து அடையக்கூடியது, ஆனால் சுரங்கப்பாதையின் மறுமுனையில் உள்ள மடிக்கணினிக்கு இது பொதுவாக வழிப்படுத்தப்பட்ட இடம் அல்ல.

எனவே இரண்டு செல்லுபடியாகும் resolver முகவரிகள் உள்ளன, அவற்றில் எதுவும் subnet கூட்டல் இரண்டு அல்ல.

endpoint அமைப்பு என்ன செய்கிறது, என்ன செய்யாது

Client VPN endpoint இல் DNS சேவையகப் புலங்கள் உள்ளன, console VPC resolver விருப்பத்தை வழங்கும் இடத்தில் அதே கருத்தை நிரப்புகிறது. அவற்றை அமைப்பது இணைப்பு நிறுவப்படும் போது சேவை client களுக்கு என்ன தருகிறது என்பதை மாற்றுகிறது. நிர்வகிக்கப்படாத OpenVPN client அந்த மதிப்புடன் என்ன செய்கிறது என்பதை இது மாற்றாது, ஏனெனில் client அதை இயங்குதளத்தில் பயன்படுத்த வேண்டும். «என் Mac இல் வேலை செய்கிறது ஆனால் Linux பெட்டியில் இல்லை» என்பது இந்த இடைவெளியிலிருந்தே வருகிறது.

Linux இல் resolver ஒருங்கிணைப்பு இணைப்பு மேலாளருக்கு சொந்தம், பயனருக்கு அல்ல. /etc/resolv.conf ஐ கையால் திருத்துவது முகவரி ஒரு அமர்வுக்கு வேலை செய்கிறது என்று நிரூபிக்கிறது, பின்னர் மீண்டும் இணைக்கும்போது மறைந்துவிடுகிறது — அதனால்தான் சரிசெய்யப்பட்ட பல நிகழ்வுகள் அடுத்த காலையில் திரும்பி வருகின்றன.

இணைந்த பிறகு client இல் செயலில் உள்ள resolver ஐச் சரிபார்க்கவும், endpoint இன் கட்டமைப்புப் பக்கத்தை அல்ல.

split tunneling சரியான resolver ஐ வெல்லலாம்

split tunneling இல் சுரங்கப்பாதைக்குள் தள்ளப்பட்ட வழிகள் மட்டுமே பயன்படுத்தப்படுகின்றன. resolver முகவரி எந்த வழியாலும் மூடப்படவில்லை என்றால், வினவல் உள்ளூர் இடைமுகம் வழியாக வெளியேறி உங்கள் வீட்டு ரவுட்டர் பதிலளிக்கிறது. endpoint இல் உள்ள முகவரி இன்னும் சரியானது, தேடல் இன்னும் தோல்வியடைகிறது. resolver க்கான வழியைச் சேர்த்து, மீண்டும் சோதிக்கவும்.

ஒன்றையொன்று மேலெழும் உள்ளூர் வரம்புகள் அதே முடிவை மிகவும் எரிச்சலூட்டும் வகையில் தருகின்றன: வினவலுக்கு பதில் வருகிறது, ஆனால் தவறான சேவையகத்திலிருந்து.

Amazon DNS முகவரிக்காக security groups திறக்க வேண்டாம்

தேடல்கள் நேரம் முடிந்ததும் இயற்கையான போக்கு resolver முகவரிக்கு UDP 53 அனுமதிக்கும் விதியைச் சேர்ப்பது. security groups மற்றும் network ACL கள் Amazon DNS போக்குவரத்தை சொந்த DNS இன்ஸ்டன்ஸுக்கு செல்லும் போக்குவரத்தைப் போல வடிகட்டுவதில்லை என்று AWS ஆவணப்படுத்துகிறது. அந்த விதிகளைத் திறப்பது VPC resolver க்கு எதையும் மாற்றாது, காரணமின்றி எல்லையை விரிவாக்குகிறது. நீங்களே இயக்கும் resolver வேறு நிகழ்வு, அதற்கு உண்மையில் சொந்த விதிகள் தேவை.

உங்கள் வடிவமைப்பில் இரண்டும் இருந்தால், எந்த விதியையும் திருத்துவதற்கு முன் client உண்மையில் எதை நோக்குகிறது என்பதைச் சரிபார்க்கவும்.

பாதையைச் சரிபார்த்து, பின்னர் வேறொன்றை அளவிடுங்கள்

பொது பெயரைத் தீர்க்கவும், VPC உடன் இணைக்கப்பட்ட தனியார் ஹோஸ்ட் செய்யப்பட்ட மண்டலத்தில் பதிவு செய்யப்பட்ட தனியார் பெயரைத் தீர்க்கவும், இரண்டுக்கும் இடையே client இன் செயலில் உள்ள resolver ஐப் படிக்கவும். இந்த வரிசை «resolver முகவரி தவறு» என்பதை «மண்டலம் இணைக்கப்படவில்லை» மற்றும் «client அமைப்பைப் புறக்கணித்தது» என்பதிலிருந்து பிரிக்கிறது. ஒவ்வொன்றுக்கும் வெவ்வேறு தீர்வு, எதுவும் throughput சிக்கல் அல்ல.

வெற்றிகரமான தேடல் தொடர்ச்சியான பரிமாற்ற வேகத்தைப் பற்றி எதுவும் கூறாது, எனவே அறிக்கை அளிக்கும்போது இந்த இரண்டு உரையாடல்களையும் தனித்தனியாக வைத்திருங்கள்.

தொடர்புடைய கட்டுரைகள்