Пристап до приватна 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 за поврзаните мрежи; тоа не го пренасочува јавниот резолвер на секој надворешен лаптоп. Не заменувајте ја со DNS зона за приватна крајна точка позајмена од друг мрежен модел на Container Apps, бидејќи имињата на записите и наставката на зоната нема да се совпаднат.
Враќање назад за овој чекор е отстранување на врската на зоната или записот што сте го додале. Забележете кое од двете беше, бидејќи бришење споделена зона за да се поништи една врска е добро познат начин да се скрши втора околина.
Чекор 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, приватната адреса на влезот и сопственикот на резолверот. Тие пет го опишуваат целиот договор за пристап, а следниот човек што ќе го отстранува проблемот ќе ги побара точно тие.