Nå en privat Container Apps-app via VPN av typen punkt till plats

Den här runboken täcker en Container Apps-miljö med arbetsbelastningsprofiler och en intern virtuell nätverksingång, som nås från en bärbar dator via ett godkänt VPN av typen punkt till plats, med appens direkta FQDN och utan HTTP-rutter på miljönivå. miljöingången är nåbar från klienten, appens ingressomfattning tillåter anroparen, och värdnamnet löses till den privata ingången. Varje steg nedan lämnar ett verifierbart resultat och en återställning som inte rör något du inte ändrade. Gå igenom dem i angiven ordning, eftersom inget senare steg kan kompensera ett felaktigt fattat omfattningsbeslut i steg 1.

Innan du rör DNS måste du klargöra ordet intern. Det används för två olika omfattningar i den här produkten, och att förväxla dem är den vanligaste orsaken till att ett fungerande namn fortfarande inte returnerar något användbart.

Steg 1: fastställ omfattningen för miljön och appen

Läs appens ingresskonfiguration innan du ändrar någon post:

Intern ingress exponeras på miljöns interna lastbalanserare inne i miljöns VNet, så frågan är inte om den bärbara datorn är en annan containerapp, utan om den kan nå det VNet:et. En VPN-klient med en rutt in i VNet:et och miljöns standarddomän som löses via den privata zonen är en kvalificerad anropare, och det är precis vad de återstående stegen bygger. En intern miljö utan offentlig ingång är ett annat faktum än en app med intern ingress, och extern ingress på appnivå ger inte miljön en offentlig dörr. Skriv omfattningen i ärendet såväl som i portalen, eftersom nästa ingenjör läser ärendet först.

Bekräfta den omfattningen med konfigurationsägaren innan du fortsätter, och håll porten smal: om det inte finns någon rutt in i miljöns VNet, eller miljöns standarddomän inte löses via den privata zonen, stanna och åtgärda den vägen först. Inget senare steg kan ersätta en anropare som inte kan nå VNet:et eller lösa namnet.

Steg 2: samla in det riktiga värdnamnet och ingångsadressen

Anteckna miljöns standarddomän, dess statiska privata ingångsadress och appens konfigurerade FQDN, hämtade från resursen och inte från en gammal skärmbild eller en wikisida:

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"

Vägledningen för privat ingång i Container Apps beskriver hur miljöns domän matchas mot dess interna adress medan applikationens värdnamn hålls intakta. Det är exakt den form du bygger för hand här, så anpassa zonens innehåll till den i stället för att hitta på ett nytt namnschema.

Om domänen du läste inte matchar den FQDN som appen rapporterar, stanna och stäm av dem nu. Att bygga en zon på fel suffix ger ett värdnamn som löses perfekt och ändå landar på fel virtuell värd.

Steg 3: placera den privata zonen på VPN:ets resolverväg

Skapa eller återanvänd den stödda privata DNS-zonen för miljöns faktiska standarddomän, med de dokumenterade jokerteckens- och adressposterna som pekar på den statiska ingången. Koppla zonen till lämpligt virtuellt nätverk och gör den privata auktoriteten nåbar via VPN:ets godkända resolverväg i stället för att anta att kopplingen räcker.

En punkt-till-plats-klient behöver vanligtvis en inkommande slutpunkt för en privat resolver eller en stödd DNS-vidarebefordrare för att nå den zonen. Att koppla en zon ändrar vad Azure löser för kopplade nätverk; det omdirigerar inte varje extern bärbar dators offentliga resolver. Byt inte ut den mot en DNS-zon för privat slutpunkt lånad från en annan Container Apps-nätverksmodell, eftersom postnamnen och zonens suffix inte kommer att stämma överens.

Återställningen för det här steget är att ta bort zonkopplingen eller posten du lade till. Anteckna vilken av de två det var, eftersom att radera en delad zon för att ångra en enda koppling är ett välkänt sätt att förstöra en andra miljö.

Steg 4: testa namnet och sedan den avvisade publiken

Testa värdnamnet och TLS-identiteten tillsammans, inte bara adressen. För en kontrollerad namnmappningsdiagnostik kan du fästa adressen medan du behåller värdnamnet:

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

Ersätt värdnamnet med appens riktiga FQDN och adressen med den riktiga interna ingången. Detta påverkar bara den enda begäran och är inte DNS-etablering. Lägg inte till -k för att göra ett identitetsfel till ett till synes godkänt, eftersom en certifikatavvikelse är signalen att du träffar fel lyssnare.

Att begära den numeriska adressen direkt kan välja fel virtuell värd eller få valideringen att misslyckas även medan TCP 443 svarar, så behandla ett lyckat IP-test som bevis om nätverket och inget mer. Från den avsedda bärbara datorn är den normala resolvervägen klientens DNS-vidarebefordrare eller den inkommande slutpunkten för den privata resolver som är värd för zonen, och ett fel där är ett problem med resolverns nåbarhet, inte en saknad post. Bekräfta att samma begäran lyckas på den vägen och bekräfta sedan att den avvisade publiken fortfarande är avvisad.

Vad som ska antecknas och vad som ska återställas

Behållarens målport och klientens HTTPS-port är separata inställningar. Publicera inte behållarens målport över VPN eftersom behållaren lyssnar där, och utöka inte en nätverksregel för att få ett porttest att passera. Båda ändringarna överlever incidenten och är svåra att tillskriva senare.

Avsluta med en färsk applikationsoperation från den avsedda bärbara datorn, med dess auktoriserade identitet och normala DNS, och kontrollera sedan att en icke-auktoriserad anropare fortfarande misslyckas. Medan du är i appkonfigurationen, bekräfta också om en HTTP-rutt på miljönivå exponerar den här appen som mål, eftersom den rutten är en andra dörr som ingressomfattningen inte beskriver.

Anteckna fem värden tillsammans: miljöns omfattning, appens ingressomfattning, FQDN, privat ingångsadress och resolverns ägare. De fem beskriver hela åtkomstkontraktet, och nästa person som ska felsöka det kommer att fråga efter exakt dem.