Приступ приватној апликацији Container Apps преко VPN-а од тачке до локације

Овај приручник покрива Container Apps окружење са профилима радног оптерећења и интерним улазом у виртуелну мрежу, до којег се долази са лаптопа преко одобреног VPN-а од тачке до локације, користећи директни FQDN апликације и без HTTP рута на нивоу окружења. улаз у окружење је доступан са клијента, обим улазног саобраћаја апликације прихвата позиваоца, а име домаћина се резолвира на приватни улаз. Сваки корак испод оставља проверљив резултат и враћање назад које не дира ништа што нисте променили. Прођите кроз њих датим редом, јер ниједан каснији корак не може да надокнади одлуку о обиму донету погрешно у кораку 1.

Пре него што додирнете DNS, разјасните реч интерно. У овом производу она се користи за два различита обима, а њихова замена је најчешћи разлог зашто радно име и даље не враћа ништа корисно.

Корак 1: утврдите обим окружења и апликације

Прочитајте конфигурацију улазног саобраћаја апликације пре него што промените било који запис:

Интерни улазни саобраћај је изложен на интерном балансеру оптерећења окружења унутар 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, приватну адресу улаза и власника резолвера. Ти пет описују цео уговор о приступу, а следећа особа која ће то отклањати тражиће тачно њих.