Dostop do zasebne aplikacije Container Apps prek VPN od točke do lokacije

Ta priročnik pokriva okolje Container Apps s profili delovne obremenitve in notranjim vhodom v virtualno omrežje, do katerega se z prenosnika dostopa prek odobrene VPN od točke do lokacije, z neposrednim FQDN aplikacije in brez poti HTTP na ravni okolja. vhod v okolje je dosegljiv s strani odjemalca, obseg vhodnega prometa aplikacije dopušča klicatelja in ime gostitelja se razreši v zasebni vhod. Vsak korak spodaj pusti preverljiv rezultat in razveljavitev, ki se ne dotakne ničesar, česar niste spremenili. Opravite jih v navedenem vrstnem redu, ker noben poznejši korak ne more nadomestiti napačno sprejete odločitve o obsegu v koraku 1.

Preden se dotaknete DNS, pojasnite besedo notranji. V tem izdelku se uporablja za dva različna obsega in njuna zamenjava je najpogostejši razlog, da delujoče ime še vedno ne vrne nič koristnega.

Korak 1: določite obseg okolja in aplikacije

Preberite konfiguracijo vhodnega prometa aplikacije, preden spremenite kateri koli zapis:

Notranji vhodni promet je izpostavljen na notranjem razporejevalniku obremenitve okolja znotraj VNet okolja, zato vprašanje ni, ali je prenosnik druga vsebniška aplikacija, ampak ali lahko doseže to VNet. Odjemalec VPN s potjo v VNet in privzeto domeno okolja, ki se razreši prek zasebnega območja, je upravičen klicatelj, in prav to gradijo preostali koraki. Notranje okolje brez javnega vhoda je drugo dejstvo kot aplikacija z notranjim vhodnim prometom, zunanji vhodni promet na ravni aplikacije pa okolju ne daje javnih vrat. Obseg zapišite v zahtevek in v portal, ker naslednji inženir najprej prebere zahtevek.

Potrdite ta obseg pri lastniku konfiguracije, preden nadaljujete, in držite vrata ozka: če poti v VNet okolja ni ali se privzeta domena okolja ne razreši prek zasebnega območja, se ustavite in najprej popravite to pot. Noben poznejši korak ne more nadomestiti klicatelja, ki ne more doseči VNet ali razrešiti imena.

Korak 2: zberite resnično ime gostitelja in naslov vhoda

Zapišite privzeto domeno okolja, njegov statični zasebni naslov vhoda in konfigurirani FQDN aplikacije, vzet iz vira in ne s stare posnetke zaslona ali wiki strani:

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"

Smernice za zasebni vhod Container Apps opisujejo usklajevanje domene okolja z njegovim notranjim naslovom, pri čemer imena gostiteljev aplikacije ostanejo nedotaknjena. Prav to obliko tukaj gradite ročno, zato vsebino območja uskladite z njo, namesto da bi izumljali novo shemo poimenovanja.

Če se prebrana domena ne ujema s FQDN, ki ga poroča aplikacija, se ustavite in ju zdaj uskladite. Gradnja območja na napačni priponi ustvari ime gostitelja, ki se popolnoma razreši in vseeno pristane na napačnem virtualnem gostitelju.

Korak 3: postavite zasebno območje na pot razreševalnika VPN

Ustvarite ali znova uporabite podprto zasebno območje DNS za dejansko privzeto domeno okolja, z dokumentiranimi zapisi z nadomestnim znakom in naslovom, ki kažejo na statični vhod. Povežite to območje z ustrezno virtualno mrežo in naredite zasebno oblast dosegljivo prek odobrene poti razreševalnika VPN, namesto da bi predpostavljali, da povezava zadostuje.

Odjemalec od točke do lokacije običajno potrebuje vhodno končno točko zasebnega razreševalnika ali podprto posredovanje DNS, da doseže to območje. Povezava območja spremeni, kaj Azure razreši za povezana omrežja; ne preusmeri javnega razreševalnika vsakega zunanjega prenosnika. Ne nadomestite ga z območjem DNS zasebne končne točke, izposojenim iz drugega omrežnega modela Container Apps, ker se imena zapisov in pripona območja ne bodo ujemali.

Razveljavitev tega koraka je odstranitev povezave območja ali zapisa, ki ste ga dodali. Zapišite, katero od tega je bilo, ker je brisanje skupnega območja za razveljavitev ene same povezave dobro znan način, kako pokvariti drugo okolje.

Korak 4: preizkusite ime in nato zavrnjeno občinstvo

Preizkusite ime gostitelja in identiteto TLS skupaj, ne le naslova. Za nadzorovano diagnostiko preslikave imen lahko naslov pripnete in ime gostitelja ohranite:

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

Zamenjajte ime gostitelja z resničnim FQDN aplikacije in naslov z resničnim notranjim vhodom. To vpliva samo na to eno zahtevo in ni zagotavljanje DNS. Ne dodajte -k, da bi napako identitete spremenili v navidezno uspešnost, ker je neujemanje potrdila znak, da zadeneate napačnega poslušalca.

Neposredna zahteva za številčni naslov lahko izbere napačnega virtualnega gostitelja ali ne uspe pri preverjanju tudi medtem ko TCP 443 odgovarja, zato uspešen preizkus IP obravnavajte kot dokaz o omrežju in nič več. Z nameravanega prenosnika je običajna pot razreševalnika posredovanje DNS odjemalca ali vhodna končna točka zasebnega razreševalnika, ki gosti območje, in napaka tam je težava dosegljivosti razreševalnika, ne manjkajoč zapis. Potrdite, da ista zahteva na tej poti uspe, nato potrdite, da je zavrnjeno občinstvo še vedno zavrnjeno.

Kaj zabeležiti in kaj razveljaviti

Ciljna vrata vsebnika in vrata HTTPS odjemalca so ločene nastavitve. Ne objavljajte ciljnih vrat vsebnika prek VPN, ker vsebnik tam posluša, in ne širite omrežnega pravila, da bi preizkus vrat uspel. Obe spremembi preživita incident in ju je pozneje težko pripisati.

Končajte s svežo operacijo aplikacije z nameravanega prenosnika, z njegovo pooblaščeno identiteto in običajnim DNS, nato preverite, da nepooblaščeni klicatelj še vedno ne uspe. Medtem ko ste v konfiguraciji aplikacije, potrdite tudi, ali pot HTTP na ravni okolja izpostavlja to aplikacijo kot cilj, ker so ta pot druga vrata, ki jih obseg vhodnega prometa ne opisuje.

Zapišite pet vrednosti skupaj: obseg okolja, obseg vhodnega prometa aplikacije, FQDN, zasebni naslov vhoda in lastnika razreševalnika. Teh pet opisuje celotno pogodbo o dostopu in naslednja oseba, ki bo to razhroščevala, bo zahtevala natanko te.