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

Denne kjøreboken dekker et Container Apps-miljø med arbeidsbelastningsprofiler og en intern inngang i det virtuelle nettverket, som nås fra en bærbar PC over en godkjent VPN av typen punkt-til-område, ved hjelp av appens direkte FQDN og uten HTTP-ruter på miljønivå. miljøinngangen er nåbar fra klienten, appens ingress-omfang slipper inn kalleren, og vertsnavnet løses til den private inngangen. Hvert trinn nedenfor etterlater et verifiserbart resultat og en tilbakerulling som ikke berører noe du ikke endret. Gå gjennom dem i gitt rekkefølge, fordi ingen senere trinn kan kompensere for en omfangsbeslutning som ble tatt feil i trinn 1.

Før du rører DNS, må du avklare ordet intern. Det brukes om to forskjellige omfang i dette produktet, og å bytte dem er den vanligste grunnen til at et fungerende navn fortsatt ikke returnerer noe nyttig.

Trinn 1: fastsett omfanget for miljøet og appen

Les appens ingress-konfigurasjon før du endrer noen post:

Intern ingress eksponeres på miljøets interne lastbalanserer inne i miljøets VNet, så spørsmålet er ikke om den bærbare PC-en er en annen containerapp, men om den kan nå det VNet-et. En VPN-klient med rute inn i VNet-et og miljøets standarddomene som løses gjennom den private sonen er en kvalifisert kaller, og det er nettopp dette de resterende trinnene bygger. Et internt miljø uten offentlig inngang er et annet faktum enn en app med intern ingress, og ekstern ingress på appnivå gir ikke miljøet en offentlig dør. Skriv omfanget i saken så vel som i portalen, fordi den neste ingeniøren leser saken først.

Bekreft dette omfanget med konfigurasjonseieren før du fortsetter, og hold porten smal: hvis det ikke finnes noen rute inn i miljøets VNet, eller miljøets standarddomene ikke løses gjennom den private sonen, stopper du og fikser den veien først. Ingen senere trinn kan erstatte en kaller som ikke kan nå VNet-et eller løse navnet.

Trinn 2: samle det ekte vertsnavnet og inngangsadressen

Noter miljøets standarddomene, dens statiske private inngangsadresse og appens konfigurerte FQDN, hentet fra ressursen og ikke fra et gammelt skjermbilde eller en 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"

Veiledningen for privat inngang i Container Apps beskriver hvordan miljøets domene tilpasses den interne adressen mens applikasjonens vertsnavn holdes intakte. Det er nøyaktig den formen du bygger for hånd her, så tilpass soneinnholdet til den i stedet for å finne opp et nytt navneskjema.

Hvis domenet du leste ikke samsvarer med FQDN-en appen rapporterer, stopper du og forliker dem nå. Å bygge en sone på feil suffiks gir et vertsnavn som løses perfekt og likevel lander på feil virtuell vert.

Trinn 3: sett den private sonen på VPN-ens resolvervei

Opprett eller gjenbruk den støttede private DNS-sonen for miljøets faktiske standarddomene, med de dokumenterte jokertegn- og adressepostene som peker på den statiske inngangen. Koble sonen til det riktige virtuelle nettverket, og gjør den private autoriteten nåbar gjennom VPN-ens godkjente resolvervei i stedet for å anta at koblingen er nok.

En punkt-til-område-klient trenger vanligvis et innkommende endepunkt for en privat resolver eller en støttet DNS-videresender for å nå den sonen. Å koble en sone endrer hva Azure løser for tilkoblede nettverk; det omdirigerer ikke hver ekstern bærbar PCs offentlige resolver. Ikke erstatt den med en DNS-sone for privat endepunkt lånt fra en annen Container Apps-nettverksmodell, fordi postnavnene og sone-suffikset ikke vil stemme overens.

Tilbakerullingen for dette trinnet er å fjerne sonekoblingen eller posten du la til. Noter hvilken av de to det var, fordi sletting av en delt sone for å angre en enkelt kobling er en velkjent måte å ødelegge et andre miljø.

Trinn 4: test navnet, deretter det avviste publikumet

Test vertsnavnet og TLS-identiteten sammen, ikke bare adressen. For en kontrollert navnetilordningsdiagnostikk kan du feste adressen mens du beholder vertsnavnet:

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

Erstatt vertsnavnet med appens ekte FQDN og adressen med den ekte interne inngangen. Dette påvirker bare den ene forespørselen og er ikke DNS-klargjøring. Ikke legg til -k for å gjøre en identitetsfeil til en tilsynelatende bestått, fordi et sertifikatavvik er signalet om at du treffer feil lytter.

Å be om den numeriske adressen direkte kan velge feil virtuell vert eller få valideringen til å feile selv mens TCP 443 svarer, så behandle en vellykket IP-test som bevis om nettverket og ikke noe mer. Fra den tiltenkte bærbare PC-en er den normale resolverveien klientens DNS-videresender eller det innkommende endepunktet til den private resolveren som er vert for sonen, og en feil der er et problem med resolverens tilgjengelighet, ikke en manglende post. Bekreft at den samme forespørselen lykkes på den veien, og bekreft deretter at det avviste publikumet fortsatt er avvist.

Hva som skal noteres, og hva som skal rulles tilbake

Beholderens målport og klientens HTTPS-port er separate innstillinger. Ikke publiser beholderens målport over VPN-en fordi beholderen lytter der, og ikke utvid en nettverksregel for å få en porttest til å bestå. Begge endringene overlever hendelsen og er vanskelige å tilskrive senere.

Avslutt med en fersk applikasjonsoperasjon fra den tiltenkte bærbare PC-en, med dens autoriserte identitet og normale DNS, og kontroller deretter at en uautorisert kaller fortsatt feiler. Mens du er i appkonfigurasjonen, bør du også bekrefte om en HTTP-rute på miljønivå eksponerer denne appen som mål, fordi den ruten er en andre dør som ingress-omfanget ikke beskriver.

Noter fem verdier sammen: miljøomfang, appens ingress-omfang, FQDN, privat inngangsadresse og resolver-eier. De fem beskriver hele tilgangskontrakten, og den neste personen som skal feilsøke den, vil spørre om nøyaktig dem.