Nå en privat Container Apps-app via VPN af typen punkt-til-websted

Denne kørebog dækker et Container Apps-miljø med arbejdsbelastningsprofiler og en intern virtuel-netværksindgang, som nås fra en bærbar computer via en godkendt VPN af typen punkt-til-websted, ved hjælp af appens direkte FQDN og uden HTTP-ruter på miljøniveau. miljøindgangen kan nås fra klienten, appens ingress-omfang tillader kaldet, og værtsnavnet opløses til den private indgang. Hvert trin nedenfor efterlader et verificerbart resultat og en tilbagerulning, der ikke rører noget, du ikke ændrede. Gennemfør dem i den angivne rækkefølge, fordi intet senere trin kan kompensere for en omfangsbeslutning, der blev truffet forkert i trin 1.

Før du rører DNS, skal du afklare ordet intern. Det bruges om to forskellige omfang i dette produkt, og at bytte dem er den mest almindelige grund til, at et fungerende navn stadig ikke returnerer noget brugbart.

Trin 1: fastlæg omfanget for miljøet og appen

Læs appens ingress-konfiguration, før du ændrer nogen post:

Intern ingress eksponeres på miljøets interne load balancer inde i miljøets VNet, så spørgsmålet er ikke, om den bærbare computer er en anden containerapp, men om den kan nå det VNet. En VPN-klient med en rute ind i VNet og miljøets standarddomæne, der opløses gennem den private zone, er en kvalificeret kalder, og det er præcis, hvad de resterende trin bygger. Et internt miljø uden offentlig indgang er et andet faktum end en app med intern ingress, og ekstern ingress på appniveau giver ikke miljøet en offentlig dør. Skriv omfanget i billetten såvel som i portalen, fordi den næste ingeniør læser billetten først.

Bekræft dette omfang med konfigurationsejeren, før du fortsætter, og hold porten smal: hvis der ikke findes en rute ind i miljøets VNet, eller miljøets standarddomæne ikke opløses gennem den private zone, så stop og ret den vej først. Intet senere trin kan erstatte en kalder, der ikke kan nå VNet eller opløse navnet.

Trin 2: indsaml det rigtige værtsnavn og indgangsadressen

Notér miljøets standarddomæne, dets statiske private indgangsadresse og appens konfigurerede FQDN, taget fra ressourcen og ikke fra et gammelt skærmbillede 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"

Vejledningen om privat indgang i Container Apps beskriver, hvordan man matcher miljøets domæne med dets interne adresse, mens applikationens værtsnavne holdes intakte. Det er præcis den form, du bygger manuelt her, så tilpas zonens indhold til den i stedet for at opfinde et nyt navngivningsskema.

Hvis det domæne, du læste, ikke matcher den FQDN, appen rapporterer, så stop og forlig dem nu. At bygge en zone på det forkerte suffiks giver et værtsnavn, der opløses perfekt og alligevel lander på det forkerte virtuelle vært.

Trin 3: sæt den private zone på VPN'ens resolversti

Opret eller genbrug den understøttede private DNS-zone til miljøets faktiske standarddomæne med de dokumenterede jokertegn- og adresseposter, der peger på den statiske indgang. Knyt zonen til det relevante virtuelle netværk, og gør den private myndighed tilgængelig gennem VPN'ens godkendte resolversti i stedet for at antage, at linket er nok.

En punkt-til-websted-klient har normalt brug for et indgående slutpunkt til en privat resolver eller en understøttet DNS-videresender for at nå den zone. At knytte en zone ændrer, hvad Azure opløser for tilknyttede netværk; det omdirigerer ikke hver ekstern bærbar computers offentlige resolver. Erstat ikke med en DNS-zone til et privat slutpunkt lånt fra en anden Container Apps-netværksmodel, fordi postnavnene og zone-suffikset ikke vil passe sammen.

Tilbagerulning for dette trin er at fjerne zonekoblingen eller den post, du tilføjede. Notér, hvilken af dem det var, fordi sletning af en delt zone for at fortryde en enkelt kobling er en velkendt måde at ødelægge et andet miljø.

Trin 4: test navnet, derefter det afviste publikum

Test værtsnavnet og TLS-identiteten sammen, ikke kun adressen. Til en kontrolleret navnemapping-diagnose kan du fastgøre adressen, mens du bevarer værtsnavnet:

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

Erstat værtsnavnet med appens rigtige FQDN og adressen med den rigtige interne indgang. Det påvirker kun den ene anmodning og er ikke DNS-klargøring. Tilføj ikke -k for at gøre en identitetsfejl til et tilsyneladende bestået, fordi en certifikatfejl er signalet om, at du rammer den forkerte lytter.

At anmode om den numeriske adresse direkte kan vælge den forkerte virtuelle vært eller få valideringen til at fejle, selv mens TCP 443 svarer, så betragt en vellykket IP-test som bevis om netværket og intet mere. Fra den tilsigtede bærbare computer er den normale resolversti klientens DNS-videresender eller det indgående slutpunkt for den private resolver, der hoster zonen, og en fejl der er et problem med resolverens tilgængelighed, ikke en manglende post. Bekræft, at den samme anmodning lykkes ad den vej, og bekræft derefter, at det afviste publikum stadig afvises.

Hvad der skal noteres, og hvad der skal rulles tilbage

Containerens målport og klientens HTTPS-port er separate indstillinger. Udgiv ikke containerens målport over VPN'en, fordi containeren lytter der, og udvid ikke en netværksregel for at få en porttest til at bestå. Begge ændringer overlever hændelsen og er svære at tilskrive senere.

Afslut med en frisk applikationshandling fra den tilsigtede bærbare computer, med dens autoriserede identitet og normale DNS, og kontrollér derefter, at en uautoriseret kalder stadig fejler. Mens du er i appkonfigurationen, så bekræft også, om en HTTP-rute på miljøniveau eksponerer denne app som mål, fordi den rute er en anden dør, som ingress-omfanget ikke beskriver.

Notér fem værdier sammen: miljøomfang, appens ingress-omfang, FQDN, privat indgangsadresse og resolver-ejer. De fem beskriver hele adgangskontrakten, og den næste, der skal fejlfinde den, vil spørge om præcis dem.