Մուտք գործել մասնավոր Container Apps հավելված՝ կետից կայք VPN-ի միջոցով
Ներքին 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-ին։ VPN հաճախորդը, որը երթուղի ունի դեպի VNet, և միջավայրի լռելյայն դոմենը լուծվում է մասնավոր գոտու միջոցով, համարվում է իրավասու կանչող, և հենց դա են կառուցում մնացած քայլերը։ Առանց հանրային մուտքի ներքին միջավայրը տարբեր փաստ է, քան ներքին ներթափանցում ունեցող հավելվածը, և հավելվածի մակարդակի արտաքին ներթափանցումը միջավայրին հանրային դուռ չի տալիս։ Շրջանակը գրեք և՛ տոմսում, և՛ պորտալում, որովհետև հաջորդ ինժեները նախ կարդում է տոմսը։
Շարունակելուց առաջ հաստատեք այդ շրջանակը կարգավորման սեփականատիրոջ հետ և դարպասը նեղ պահեք. եթե միջավայրի 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-ը, մասնավոր մուտքի հասցեն և լուծիչի սեփականատերը։ Այդ հինգը նկարագրում են ողջ մուտքի պայմանագիրը, և հաջորդ մարդը, ով կվրիպազերծի այն, հենց դրանք կհարցնի։