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

முதல் படி: IP அல்ல, திட்டத்தைப் படியுங்கள்

திட்டப் புலம் என்பது சுமை சமநிலைப்படுத்தியின் தன் எல்லை பற்றிய அதன் சொந்த அறிக்கை. aws elbv2 describe-load-balancers --names app-internal internal அல்லது internet-facing மதிப்புடைய Scheme திருப்பித் தருகிறது, மேலும் IPv4 அல்லது இரட்டை அடுக்குக்கான முகவரி வகை. இணையத்தை நோக்கிய சுமை சமநிலைப்படுத்தி தனிப்பட்ட இலக்குகளுக்கு அனுப்பலாம், எனவே தனிப்பட்ட பின்தள முகவரிகளைப் பார்ப்பது முன் பகுதி பற்றி எதையும் நிரூபிக்கவில்லை.

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

இரண்டாம் படி: பெயர் எதற்குத் தீர்கிறது எனப் பாருங்கள்

VPC க்கு வெளியே இருந்து dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com மூலம் கேளுங்கள், பதில்கள் 10.0.0.0/8, 172.16.0.0/12 அல்லது 192.168.0.0/16 இல் உள்ளதா எனக் குறிப்பிடுங்கள். பொது தீர்வியிலிருந்து தனிப்பட்ட பதில் உள் சுமை சமநிலைப்படுத்தி பெயருக்கு எதிர்பார்க்கப்படும் நடத்தை; முகவரி இணையத்திலிருந்து வழிப்பறியக்கூடியது என்பதற்கான சான்று அல்ல.

அதே பெயரை VPC உள்ளேயிருந்து தீர்த்து ஒப்பிடுங்கள். இரு பதில்களும் வேறுபட்டால், நீங்கள் ஸ்பிளிட்-ஹொரைசன் பெயரிடலைப் பார்க்கிறீர்கள், அந்த வேறுபாடு வடிவமைப்பு விவரம், கசிவு அல்ல.

மூன்றாம் படி: அதை அடையக்கூடிய பாதைகளைப் பட்டியலிடுங்கள்

தனிப்பட்ட முகவரி பாதையும் பாதுகாப்பு விதியும் உள்ள எங்கிருந்தும் அடையக்கூடியது. அவற்றை வேண்டுமென்றே பட்டியலிடுங்கள்: தளத்திற்கு-தளம் VPN, வாடிக்கையாளர் VPN, VPC பியரிங், டிரான்சிட் கேட்வே இணைப்புகள், Direct Connect மற்றும் VPC க்குள் உள்ள எந்தப் ப்ராக்ஸி அல்லது பாஸ்டியன். அவற்றில் ஒன்று நோக்கமான பாதை, மீதமுள்ளவை தாக்குபவர் தேடும் பாதைகள்.

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

நான்காம் படி: கேட்பானையும் பயன்பாட்டையும் தனித்தனியாகச் சோதியுங்கள்

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

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

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

ஐந்தாம் படி: பெயருக்கே முக்கியத்துவம் உண்டா என்று முடிவு செய்யுங்கள்

பொது தீர்வு திறன் சேவைப் பெயர், பிராந்தியம் மற்றும் முகவரி வரம்பை வெளிப்படுத்தலாம். அதைக் கொள்கைப் பதிலுடைய தகவல் வெளிப்பாடு கேள்வியாகக் கருதுங்கள், தானியங்கி சம்பவமாக அல்ல: முக்கிய வணிகச் சொற்களை வளப் பெயர்களிலிருந்து விலக்கி, பெயரிடல் மரபு நீங்கள் விரும்புவதற்கு மேல் வெளிப்படுத்தினால் ஆபத்துப் பதிவில் வெளிப்பாட்டைக் குறிப்பிடுங்கள்.

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

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

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