Nå ein privat Container Apps-app over punkt-til-område-VPN

Denne køyreboka dekkjer eit Container Apps-miljø med arbeidsbelastningsprofilar og ein intern inngang i det virtuelle nettverket, som ein når frå ein berbar PC over ein godkjend VPN av typen punkt-til-område, ved hjelp av den direkte FQDN-en til appen og utan HTTP-ruter på miljønivå. miljøinngangen er nåbar frå klienten, ingressomfanget til appen slepp inn kallaren, og vertsnamnet blir løyst til den private inngangen. Kvart steg nedanfor etterlèt eit verifiserbart resultat og ei tilbakerulling som ikkje rører noko du ikkje endra. Gå gjennom dei i gitt rekkjefølgje, fordi ingen seinare steg kan kompensere for eit omfangsvedtak som vart teke feil i steg 1.

Før du rører DNS, må du avklare ordet intern. Det blir brukt om to ulike omfang i dette produktet, og å bytte dei er den vanlegaste grunnen til at eit fungerande namn framleis ikkje returnerer noko nyttig.

Steg 1: fastset omfanget for miljøet og appen

Les ingresskonfigurasjonen til appen før du endrar nokon post:

Intern ingress er eksponert på den interne lastbalanseraren til miljøet inne i VNet-et til miljøet, så spørsmålet er ikkje om den berbare PC-en er ein annan containerapp, men om han kan nå det VNet-et. Ein VPN-klient med rute inn i VNet-et og standarddomenet til miljøet som blir løyst gjennom den private sona er ein kvalifisert kallar, og det er nettopp dette dei resterande stega byggjer. Eit internt miljø utan offentleg inngang er eit anna faktum enn ein app med intern ingress, og ekstern ingress på appnivå gir ikkje miljøet ei offentleg dør. Skriv omfanget i saka så vel som i portalen, fordi den neste ingeniøren les saka først.

Stadfest dette omfanget med konfigurasjonseigaren før du held fram, og hald porten smal: viss det ikkje finst noka rute inn i VNet-et til miljøet, eller standarddomenet til miljøet ikkje blir løyst gjennom den private sona, stoppar du og fiksar den vegen først. Ingen seinare steg kan erstatte ein kallar som ikkje kan nå VNet-et eller løyse namnet.

Steg 2: samle det ekte vertsnamnet og inngangsadressa

Noter standarddomenet til miljøet, den statiske private inngangsadressa og den konfigurerte FQDN-en til appen, henta frå ressursen og ikkje frå eit gammalt skjermbilete eller ei wikiside:

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"

Rettleiinga for privat inngang i Container Apps skildrar korleis ein tilpassar domenet til miljøet til den interne adressa medan vertsnamna til applikasjonen blir haldne intakte. Det er nøyaktig den forma du byggjer for hand her, så tilpass soneinnhaldet til henne i staden for å finne opp eit nytt namneskjema.

Viss domenet du las ikkje samsvarer med FQDN-en appen rapporterer, stoppar du og forlikar dei no. Å byggje ei sone på feil suffiks gir eit vertsnamn som blir løyst perfekt og likevel landar på feil virtuell vert.

Steg 3: set den private sona på resolvervegen til VPN-en

Opprett eller gjenbruk den støtta private DNS-sona for det faktiske standarddomenet til miljøet, med dei dokumenterte jokerteikn- og adressepostane som peikar på den statiske inngangen. Kople sona til det rette virtuelle nettverket, og gjer den private autoriteten nåbar gjennom den godkjende resolvervegen til VPN-en i staden for å anta at koplinga er nok.

Ein punkt-til-område-klient treng vanlegvis eit innkomande endepunkt for ein privat resolver eller ein støtta DNS-vidaresendar for å nå den sona. Å kople ei sone endrar kva Azure løyser for tilkopla nettverk; det omdirigerer ikkje den offentlege resolveren til kvar ekstern berbar PC. Ikkje erstatt henne med ei DNS-sone for privat endepunkt lånt frå ein annan Container Apps-nettverksmodell, fordi postnamna og sone-suffikset ikkje vil stemme overeins.

Tilbakerullinga for dette steget er å fjerne sonekoplinga eller posten du la til. Noter kva av dei to det var, fordi sletting av ei delt sone for å angre ei enkel kopling er ein velkjend måte å øydeleggje eit andre miljø.

Steg 4: test namnet, deretter det avviste publikumet

Test vertsnamnet og TLS-identiteten saman, ikkje berre adressa. For ein kontrollert namnetilordningsdiagnostikk kan du feste adressa medan du held på vertsnamnet:

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

Erstatt vertsnamnet med den ekte FQDN-en til appen og adressa med den ekte interne inngangen. Dette påverkar berre den eine førespurnaden og er ikkje DNS-klargjering. Ikkje legg til -k for å gjere ein identitetsfeil til ein tilsynelatande bestått, fordi eit sertifikatavvik er signalet om at du treff feil lyttar.

Å be om den numeriske adressa direkte kan velje feil virtuell vert eller få valideringa til å feile sjølv medan TCP 443 svarar, så handsam ein vellukka IP-test som bevis om nettverket og ikkje noko meir. Frå den tiltenkte berbare PC-en er den normale resolvervegen DNS-vidaresendaren til klienten eller det innkomande endepunktet til den private resolveren som er vert for sona, og ein feil der er eit problem med tilgjenge til resolveren, ikkje ein manglande post. Stadfest at den same førespurnaden lukkast på den vegen, og stadfest deretter at det avviste publikumet framleis er avvist.

Kva som skal noterast, og kva som skal rullast tilbake

Målporten til beholderen og HTTPS-porten til klienten er separate innstillingar. Ikkje publiser målporten til beholderen over VPN-en fordi beholderen lyttar der, og ikkje utvid ei nettverksregel for å få ein porttest til å bestå. Begge endringane overlever hendinga og er vanskelege å tilskrive seinare.

Avslutt med ein fersk applikasjonsoperasjon frå den tiltenkte berbare PC-en, med den autoriserte identiteten og normal DNS, og kontroller deretter at ein uautorisert kallar framleis feilar. Medan du er i appkonfigurasjonen, bør du også stadfeste om ei HTTP-rute på miljønivå eksponerer denne appen som mål, fordi den ruta er ei andre dør som ingressomfanget ikkje skildrar.

Noter fem verdiar saman: miljøomfang, ingressomfanget til appen, FQDN, privat inngangsadresse og resolvereigar. Dei fem skildrar heile tilgangskontrakten, og den neste personen som skal feilsøkje han, vil spørje om nøyaktig dei.