Достъп до частно приложение 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, частен адрес на входа и собственик на преобразувателя. Тези пет описват целия договор за достъп и следващият човек, който ще го отстранява, ще поиска точно тях.