பாயிண்ட்-டு-சைட் VPN வழியாக தனிப்பட்ட Container Apps பயன்பாட்டை அடையுங்கள்
உள் Container Apps சூழலுக்கு தனிப்பட்ட நுழைவு, பொருந்தும் ஹோஸ்ட்பெயர் மற்றும் VPN அடையக்கூடிய தீர்வு ஒன்று தேவை. ஒவ்வொரு படியையும் இயக்கி, பின்னர் மறுப்பைச் சரிபார்க்கவும்.
இந்த வழிகாட்டி பணிச்சுமை சுயவிவரங்களைக் கொண்ட Container Apps சூழலையும் அதன் உள் மெய்நிகர்-வலைய நுழைவையும் உள்ளடக்குகிறது; அங்கு மடிக்கணினியிலிருந்து அங்கீகரிக்கப்பட்ட பாயிண்ட்-டு-சைட் VPN வழியாக அடையலாம், பயன்பாட்டின் நேரடி FQDN ஐப் பயன்படுத்தி, சூழல் மட்டத்தில் HTTP வழிகளின்றி. சூழலின் நுழைவு கிளையண்டிலிருந்து அடையக்கூடியது, பயன்பாட்டின் இன்கிரெஸ் எல்லை அழைப்பவரை அனுமதிக்கிறது, மேலும் ஹோஸ்ட்பெயர் தனிப்பட்ட நுழைவுக்குத் தீர்க்கப்படுகிறது. கீழேயுள்ள ஒவ்வொரு படியும் சரிபார்க்கக்கூடிய முடிவையும் நீங்கள் மாற்றாத எதையும் தொடாத பின்னடைவையும் விட்டுச் செல்கிறது. கொடுக்கப்பட்ட வரிசையில் அவற்றை முடிக்கவும், ஏனெனில் படி 1 இல் தவறாக எடுக்கப்பட்ட எல்லை முடிவைப் பின்னர் எந்தப் படியும் ஈடுசெய்ய முடியாது.
DNS ஐத் தொடுவதற்கு முன் உள் என்ற சொல்லைத் தெளிவுபடுத்துங்கள். இந்தத் தயாரிப்பில் இது இரண்டு வெவ்வேறு எல்லைகளுக்குப் பயன்படுத்தப்படுகிறது, அவற்றை மாற்றுவதே வேலை செய்யும் பெயர் இன்னும் பயனுள்ள எதையும் திருப்பித் தராததற்கு மிகவும் பொதுவான காரணம்.
படி 1: சூழல் மற்றும் பயன்பாட்டின் எல்லையை நிர்ணயிக்கவும்
எந்தப் பதிவையும் மாற்றுவதற்கு முன் பயன்பாட்டின் இன்கிரெஸ் உள்ளமைவைப் படியுங்கள்:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
உள் இன்கிரெஸ் சூழலின் VNet க்குள் சூழலின் உள் சுமை சமநிலைப்படுத்தியில் வெளிப்படுத்தப்படுகிறது, எனவே கேள்வி மடிக்கணினி மற்றொரு கொள்கலன் பயன்பாடா என்பது அல்ல, அது அந்த VNet ஐ அடைய முடியுமா என்பதே. VNet க்கு வழி உள்ளவரும், சூழலின் இயல்புநிலை டொமைன் தனிப்பட்ட மண்டலம் வழியாகத் தீர்க்கப்படுபவருமான VPN கிளையண்ட் தகுதியான அழைப்பவர், மீதமுள்ள படிகள் சரியாக அதையே உருவாக்குகின்றன. பொது நுழைவு இல்லாத உள் சூழல் உள் இன்கிரெஸ் உள்ள பயன்பாட்டிலிருந்து வேறுபட்ட உண்மை, மேலும் பயன்பாட்டு மட்டத்தில் வெளிப்புற இன்கிரெஸ் சூழலுக்குப் பொது கதவைத் தராது. எல்லையை போர்ட்டலிலும் டிக்கெட்டிலும் எழுதுங்கள், ஏனெனில் அடுத்த பொறியாளர் முதலில் டிக்கெட்டைப் படிக்கிறார்.
தொடர்வதற்கு முன் அந்த எல்லையை உள்ளமைவு உரிமையாளருடன் உறுதிப்படுத்தி, வாயிலைக் குறுகலாக வைத்திருங்கள்: சூழலின் VNet க்கு வழி இல்லாவிட்டால், அல்லது சூழலின் இயல்புநிலை டொமைன் தனிப்பட்ட மண்டலம் வழியாகத் தீர்க்கப்படாவிட்டால், நிறுத்தி முதலில் அந்தப் பாதையைச் சரிசெய்யுங்கள். VNet ஐ அடைய முடியாத அல்லது பெயரைத் தீர்க்க முடியாத அழைப்பவருக்கு பின்னர் எந்தப் படியும் மாற்றாக அமையாது.
படி 2: உண்மையான ஹோஸ்ட்பெயர் மற்றும் நுழைவு முகவரியைச் சேகரிக்கவும்
சூழலின் இயல்புநிலை டொமைன், அதன் நிலையான தனிப்பட்ட நுழைவு முகவரி மற்றும் பயன்பாட்டின் உள்ளமைக்கப்பட்ட FQDN ஆகியவற்றைப் பதிவு செய்யுங்கள்; அவற்றைப் பழைய திரைப்பிடிப்பு அல்லது விக்கிப் பக்கத்திலிருந்து அல்ல, ஆதாரத்திலிருந்து எடுங்கள்:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"Container Apps இன் தனிப்பட்ட நுழைவு வழிகாட்டுதல் பயன்பாட்டின் ஹோஸ்ட்பெயர்களை அப்படியே வைத்துக்கொண்டு சூழலின் டொமைனை அதன் உள் முகவரியுடன் பொருத்துவதை விவரிக்கிறது. நீங்கள் இங்கே கையால் உருவாக்குவது சரியாக அதே வடிவம், எனவே புதிய பெயரிடல் திட்டத்தைக் கண்டுபிடிப்பதற்குப் பதிலாக மண்டலத்தின் உள்ளடக்கத்தை அதனுடன் சீரமைக்கவும்.
நீங்கள் படித்த டொமைன் பயன்பாடு தெரிவிக்கும் FQDN உடன் பொருந்தவில்லை என்றால், நிறுத்தி இப்போதே அவற்றை ஒத்திசைக்கவும். தவறான பின்னொட்டில் மண்டலத்தை உருவாக்கினால், சரியாகத் தீர்க்கப்படும் ஆனால் தவறான மெய்நிகர் ஹோஸ்டில் இறங்கும் ஹோஸ்ட்பெயர் உருவாகும்.
படி 3: தனிப்பட்ட மண்டலத்தை VPN இன் தீர்வு பாதையில் வைக்கவும்
சூழலின் உண்மையான இயல்புநிலை டொமைனுக்கு ஆதரவளிக்கப்படும் தனிப்பட்ட DNS மண்டலத்தை உருவாக்கவும் அல்லது மீண்டும் பயன்படுத்தவும், ஆவணப்படுத்தப்பட்ட வைல்ட்கார்டு மற்றும் முகவரி பதிவுகள் நிலையான நுழைவைச் சுட்டுகின்றன. அந்த மண்டலத்தைப் பொருத்தமான மெய்நிகர் வலையத்துடன் இணைத்து, இணைப்பே போதுமானது என்று கருதுவதற்குப் பதிலாக VPN இன் அங்கீகரிக்கப்பட்ட தீர்வு பாதை வழியாகத் தனிப்பட்ட அதிகாரத்தை அடையக்கூடியதாக்கவும்.
பாயிண்ட்-டு-சைட் கிளையண்டிற்கு அந்த மண்டலத்தை அடைய பொதுவாகத் தனிப்பட்ட தீர்வியின் உள்வரும் முனை அல்லது ஆதரவளிக்கப்படும் DNS அனுப்பி தேவை. மண்டலத்தை இணைப்பது இணைக்கப்பட்ட வலையங்களுக்கு Azure தீர்க்கும் விஷயத்தை மாற்றுகிறது; அது ஒவ்வொரு வெளிப்புற மடிக்கணினியின் பொது தீர்வியையும் திசைதிருப்பாது. வேறு Container Apps வலையமைப்பு மாதிரியிலிருந்து கடன் வாங்கிய தனிப்பட்ட-முனை DNS மண்டலத்தால் அதை மாற்ற வேண்டாம், ஏனெனில் பதிவு பெயர்களும் மண்டல பின்னொட்டும் பொருந்தாது.
இந்தப் படியின் பின்னடைவு நீங்கள் சேர்த்த மண்டல இணைப்பு அல்லது பதிவை அகற்றுவதாகும். அவற்றில் எது என்பதைப் பதிவு செய்யுங்கள், ஏனெனில் ஒரு இணைப்பை ரத்து செய்யப் பகிரப்பட்ட மண்டலத்தை நீக்குவது இரண்டாவது சூழலை உடைப்பதற்கான அறியப்பட்ட வழியாகும்.
படி 4: பெயரைச் சோதித்து, பின்னர் மறுக்கப்பட்ட பார்வையாளர்களை
ஹோஸ்ட்பெயர் மற்றும் TLS அடையாளத்தை ஒன்றாகச் சோதிக்கவும், முகவரி மட்டுமல்ல. கட்டுப்படுத்தப்பட்ட பெயர்-மேப்பிங் நோயறிதலுக்கு நீங்கள் ஹோஸ்ட்பெயரைத் தக்கவைத்து முகவரியைப் பின்னலாம்:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/ஹோஸ்ட்பெயரைப் பயன்பாட்டின் உண்மையான FQDN ஆல், முகவரியை உண்மையான உள் நுழைவால் மாற்றவும். இது அந்த ஒரு கோரிக்கையை மட்டுமே பாதிக்கிறது, DNS வழங்கல் அல்ல. அடையாளத் தோல்வியைத் தோற்றமளிக்கும் தேர்ச்சியாக மாற்ற -k ஐச் சேர்க்க வேண்டாம், ஏனெனில் சான்றிதழ் பொருந்தாமை நீங்கள் தவறான கேட்பவரைத் தாக்குகிறீர்கள் என்பதற்கான சமிக்ஞை.
எண் முகவரியை நேரடியாகக் கோருவது TCP 443 பதிலளிக்கும் போதும் தவறான மெய்நிகர் ஹோஸ்டைத் தேர்ந்தெடுக்கலாம் அல்லது சரிபார்ப்பைத் தோல்வியடையச் செய்யலாம், எனவே வெற்றிகரமான IP சோதனையை வலையம் பற்றிய சான்றாகக் கருதுங்கள், அதற்கு மேல் அல்ல. நோக்கம் கொண்ட மடிக்கணினியிலிருந்து வழக்கமான தீர்வு பாதை கிளையண்டின் DNS அனுப்பி அல்லது மண்டலத்தை வழங்கும் தனிப்பட்ட தீர்வியின் உள்வரும் முனை, அங்குள்ள தோல்வி காணாமல் போன பதிவு அல்ல, தீர்வியை அடைவதில் உள்ள சிக்கல். அதே பாதையில் அதே கோரிக்கை வெற்றிபெறுவதை உறுதிப்படுத்தி, பின்னர் மறுக்கப்பட்ட பார்வையாளர்கள் இன்னும் மறுக்கப்படுகிறார்கள் என்பதை உறுதிப்படுத்தவும்.
எதைப் பதிவு செய்ய வேண்டும், எதைப் பின்னடைய வேண்டும்
கொள்கலனின் இலக்கு போர்ட் மற்றும் கிளையண்டின் HTTPS போர்ட் தனித்தனி அமைப்புகள். கொள்கலன் அங்கே கேட்பதால் அதன் இலக்கு போர்ட்டை VPN வழியாக வெளியிட வேண்டாம், போர்ட் சோதனை கடக்க வலையமைப்பு விதியை விரிவுபடுத்த வேண்டாம். இரண்டு மாற்றங்களும் சம்பவத்திற்குப் பிறகும் நீடிக்கும், பின்னர் அவற்றைக் காரணம் கூறுவது கடினம்.
நோக்கம் கொண்ட மடிக்கணினியிலிருந்து அதன் அதிகாரமளிக்கப்பட்ட அடையாளத்தையும் வழக்கமான DNS ஐயும் பயன்படுத்தி புதிய பயன்பாட்டுச் செயல்பாட்டுடன் முடிக்கவும், பின்னர் அனுமதிக்கப்படாத அழைப்பவர் இன்னும் தோல்வியடைவதைச் சரிபார்க்கவும். பயன்பாட்டு உள்ளமைவில் இருக்கும்போது, சூழல் மட்டத்திலான HTTP வழி இந்தப் பயன்பாட்டை இலக்காக வெளிப்படுத்துகிறதா என்பதையும் உறுதிப்படுத்துங்கள், ஏனெனில் அந்த வழி இன்கிரெஸ் எல்லை விவரிக்காத இரண்டாவது கதவு.
ஐந்து மதிப்புகளை ஒன்றாகப் பதிவு செய்யுங்கள்: சூழலின் எல்லை, பயன்பாட்டின் இன்கிரெஸ் எல்லை, FQDN, தனிப்பட்ட நுழைவு முகவரி மற்றும் தீர்வியின் உரிமையாளர். அந்த ஐந்தும் முழு அணுகல் ஒப்பந்தத்தை விவரிக்கின்றன, இதைப் பிழைதிருத்தப்போகும் அடுத்த நபர் சரியாக அவற்றையே கேட்பார்.