Privaatsele Container Apps rakendusele juurdepääs VPN-i kaudu punktist saidile

See juhend käsitleb Container Apps keskkonda töökoormuse profiilidega ja sisemise virtuaalvõrgu sissepääsuga, milleni jõutakse sülearvutist heakskiidetud VPN-i kaudu punktist saidile, kasutades rakenduse otsest FQDN-i ja ilma keskkonnatasandi HTTP-marsruutideta. keskkonna sissepääs on kliendist kättesaadav, rakenduse sissetuleva liikluse ulatus lubab kutsujat ja hostinimi lahendatakse privaatsele sissepääsule. Iga allpool olev samm jätab kontrollitava tulemuse ja tagasipööramise, mis ei puuduta midagi, mida te ei muutnud. Läbige need etteantud järjekorras, sest ükski hilisem samm ei suuda kompenseerida sammus 1 valesti tehtud ulatuse otsust.

Enne kui DNS-i puudutate, täpsustage sõna sisemine. Selles tootes kasutatakse seda kahe erineva ulatuse jaoks ja nende vahetamine on kõige tavalisem põhjus, miks töötav nimi ikkagi midagi kasulikku ei tagasta.

Samm 1: määrake keskkonna ja rakenduse ulatus

Lugege rakenduse sissetuleva liikluse konfiguratsiooni enne mis tahes kirje muutmist:

Sisemine sissetulev liiklus on avatud keskkonna sisemise koormusjaoturi kaudu keskkonna VNet-i sees, seega küsimus ei ole, kas sülearvuti on veel üks konteinerirakendus, vaid kas see pääseb sellesse VNet-i. VPN-klient, kellel on marsruut VNet-i ja kelle keskkonna vaikedomeen lahendatakse privaatse tsooni kaudu, on sobiv kutsuja, ja just seda ehitavad ülejäänud sammud. Sisemine keskkond ilma avaliku sissepääsuta on erinev fakt kui sisemise sissetuleva liiklusega rakendus, ja rakenduse tasandi väline sissetulev liiklus ei anna keskkonnale avalikku ust. Kirjutage ulatus nii piletisse kui ka portaali, sest järgmine insener loeb kõigepealt piletit.

Kinnitage see ulatus konfiguratsiooni omanikuga enne jätkamist ja hoidke värav kitsas: kui keskkonna VNet-i marsruuti ei ole või keskkonna vaikedomeen ei lahendu privaatse tsooni kaudu, peatuge ja parandage kõigepealt see tee. Ükski hilisem samm ei asenda kutsujat, kes ei pääse VNet-i ega suuda nime lahendada.

Samm 2: koguge tegelik hostinimi ja sissepääsu aadress

Märkige üles keskkonna vaikedomeen, selle staatiline privaatne sissepääsuaadress ja rakenduse konfigureeritud FQDN, võetuna ressursist, mitte vanalt ekraanipildilt või viki lehelt:

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-i privaatse sissepääsu juhised kirjeldavad keskkonna domeeni sobitamist selle sisemise aadressiga, jättes rakenduse hostinimed puutumata. See on täpselt see vorm, mida te siin käsitsi ehitate, seega joondage tsooni sisu sellega, selle asemel et uut nimetamisskeemi leiutada.

Kui loetud domeen ei ühti rakenduse teatatud FQDN-iga, peatuge ja viige need kohe kooskõlla. Vale sufiksaatori alusel tsooni ehitamine loob hostinime, mis lahendub suurepäraselt ja maandub ikkagi valesse virtuaalhosti.

Samm 3: asetage privaatne tsoon VPN-i resolveri teele

Looge või kasutage uuesti toetatud privaatset DNS-tsooni keskkonna tegeliku vaikedomeeni jaoks, kus dokumenteeritud metamärk- ja aadressikirjed osutavad staatilisele sissepääsule. Siduge see tsoon sobiva virtuaalvõrgustikuga ja tehke privaatne volitus kättesaadavaks VPN-i heakskiidetud resolveri tee kaudu, selle asemel et eeldada, et sidest piisab.

Punktist saidile klient vajab sellesse tsooni jõudmiseks tavaliselt privaatse resolveri sissetulevat lõpp-punkti või toetatud DNS-edastajat. Tsooni sidumine muudab seda, mida Azure seotud võrkude jaoks lahendab; see ei suuna ümber iga välise sülearvuti avalikku resolverit. Ärge asendage seda teise Container Apps-i võrgumudeli privaatse lõpp-punkti DNS-tsooniga, sest kirjete nimed ja tsooni sufiks ei ühti.

Selle sammu tagasipööramine on tsooni lingi või lisatud kirje eemaldamine. Märkige üles, milline neist see oli, sest jagatud tsooni kustutamine ühe lingi tühistamiseks on tuntud viis teise keskkonna rikkumiseks.

Samm 4: testige nime, seejärel keelatud publikumit

Testige hostinime ja TLS-identiteeti koos, mitte ainult aadressi. Kontrollitud nimede vastendamise diagnostikaks saate aadressi kinnitada, säilitades hostinime:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

Asendage hostinimi rakenduse tegeliku FQDN-iga ja aadress tegeliku sisemise sissepääsuga. See mõjutab ainult seda ühte päringut ega ole DNS-i pakkumine. Ärge lisage -k, et muuta identiteediviga näiliseks õnnestumiseks, sest sertifikaadi mittevastavus on signaal, et tabate vale kuulajat.

Numbrilise aadressi otse küsimine võib valida vale virtuaalhosti või jätta valideerimise läbi kukkuma isegi siis, kui TCP 443 vastab, seega käsitlege õnnestunud IP-testi tõendina võrgu kohta ja mitte rohkem. Kavandatud sülearvutist on tavaline resolveri tee kliendi DNS-edastaja või tsooni majutava privaatse resolveri sissetulev lõpp-punkt, ja sealne tõrge on resolveri kättesaadavuse probleem, mitte puuduv kirje. Kinnitage, et sama päring õnnestub sellel teel, ja seejärel kinnitage, et keelatud publikum on endiselt keelatud.

Mida kirja panna ja mida tagasi pöörata

Konteineri sihtport ja kliendi HTTPS-port on eraldi seaded. Ärge avaldage konteineri sihtporti üle VPN-i, sest konteiner kuulab seal, ja ärge laiendage võrgureeglit, et porditest läbi läheks. Mõlemad muudatused elavad juhtumist üle ja neid on hiljem raske omistada.

Lõpetage värske rakendustehinguga kavandatud sülearvutist, kasutades selle volitatud identiteeti ja tavalist DNS-i, seejärel kontrollige, et volitamata kutsuja ikka ebaõnnestub. Rakenduse konfiguratsioonis olles kontrollige ka, kas keskkonnatasandi HTTP-marsruut paljastab selle rakenduse sihtmärgina, sest see marsruut on teine uks, mida sissetuleva liikluse ulatus ei kirjelda.

Märkige koos üles viis väärtust: keskkonna ulatus, rakenduse sissetuleva liikluse ulatus, FQDN, privaatne sissepääsuaadress ja resolveri omanik. Need viis kirjeldavad kogu juurdepääsulepingut ja järgmine inimene, kes seda silub, küsib täpselt neid.