Een privé Container Apps-app bereiken via punt-naar-site-VPN
Een interne Container Apps-omgeving heeft een privé-ingang, een bijpassende hostnaam en een resolver nodig die de VPN kan bereiken. Voer elke stap uit en controleer daarna de weigering.
Deze runbook behandelt een Container Apps-omgeving met workloadprofielen en een interne virtuele-netwerkinvoer, bereikt vanaf een laptop via een goedgekeurde punt-naar-site-VPN, met de directe FQDN van de app en zonder HTTP-routes op omgevingsniveau. de ingang van de omgeving is bereikbaar vanaf de client, de ingress-scope van de app laat de aanroeper toe, en de hostnaam wordt omgezet naar de privé-ingang. Elke stap hieronder laat een verifieerbaar resultaat en een terugdraaiing achter die niets aanraakt wat u niet hebt gewijzigd. Werk ze in de gegeven volgorde af, want geen enkele latere stap kan een verkeerd genomen scope-beslissing in stap 1 compenseren.
Voordat u DNS aanraakt, moet u het woord intern verduidelijken. Het wordt in dit product voor twee verschillende scopes gebruikt, en ze verwisselen is de meest voorkomende reden dat een werkende naam nog steeds niets bruikbaars teruggeeft.
Stap 1: leg de scope van de omgeving en de app vast
Lees de ingress-configuratie van de app voordat u een record wijzigt:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
Interne ingress wordt ontsloten op de interne load balancer van de omgeving binnen de VNet van de omgeving, dus de vraag is niet of de laptop een andere containerapp is, maar of hij die VNet kan bereiken. Een VPN-client met een route naar de VNet en het standaarddomein van de omgeving dat via de privé-zone wordt omgezet, is een geldige aanroeper, en dat is precies wat de resterende stappen bouwen. Een interne omgeving zonder openbare ingang is een ander feit dan een app met interne ingress, en externe ingress op appniveau geeft de omgeving geen openbare deur. Schrijf de scope in het ticket en ook in de portal, want de volgende ingenieur leest eerst het ticket.
Bevestig die scope met de eigenaar van de configuratie voordat u verdergaat, en houd de poort smal: als er geen route naar de VNet van de omgeving bestaat, of het standaarddomein van de omgeving niet via de privé-zone wordt omgezet, stop dan en repareer eerst dat pad. Geen latere stap kan een aanroeper vervangen die de VNet niet kan bereiken of de naam niet kan omzetten.
Stap 2: verzamel de echte hostnaam en het ingangsadres
Noteer het standaarddomein van de omgeving, het statische privé-ingangsadres en de geconfigureerde FQDN van de app, uit de resource en niet uit een oude schermafbeelding of een wikipagina:
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"De richtlijnen voor privé-ingang van Container Apps beschrijven het afstemmen van het domein van de omgeving op het interne adres, terwijl de hostnamen van de applicatie intact blijven. Dat is precies de vorm die u hier met de hand bouwt, dus lijn de inhoud van de zone daarmee uit in plaats van een nieuw naamgevingsschema te bedenken.
Als het domein dat u hebt gelezen niet overeenkomt met de FQDN die de app rapporteert, stop dan en stem ze nu af. Een zone op het verkeerde achtervoegsel bouwen levert een hostnaam op die perfect wordt omgezet en toch op de verkeerde virtuele host belandt.
Stap 3: zet de privé-zone op het resolverpad van de VPN
Maak of hergebruik de ondersteunde privé-DNS-zone voor het werkelijke standaarddomein van de omgeving, met de gedocumenteerde wildcard- en adresrecords die naar de statische ingang wijzen. Koppel die zone aan het juiste virtuele netwerk, en maak het privé-gezag bereikbaar via het goedgekeurde resolverpad van de VPN in plaats van aan te nemen dat de koppeling voldoende is.
Een punt-naar-site-client heeft meestal een inkomend eindpunt van een privé-resolver of een ondersteunde DNS-doorstuurder nodig om die zone te bereiken. Een zone koppelen verandert wat Azure voor gekoppelde netwerken omzet; het leidt niet de openbare resolver van elke externe laptop om. Vervang de zone niet door een DNS-zone voor privé-eindpunten die uit een ander Container Apps-netwerkmodel is geleend, want de recordnamen en het zone-achtervoegsel zullen niet overeenkomen.
De terugdraaiing voor deze stap is het verwijderen van de zonekoppeling of het record dat u hebt toegevoegd. Noteer welke van de twee het was, want een gedeelde zone verwijderen om één koppeling ongedaan te maken is een bekende manier om een tweede omgeving te breken.
Stap 4: test de naam en daarna het geweigerde publiek
Test de hostnaam en TLS-identiteit samen, niet alleen het adres. Voor een gecontroleerde naamtoewijzingsdiagnose kunt u het adres vastpinnen terwijl u de hostnaam behoudt:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Vervang de hostnaam door de echte FQDN van de app en het adres door de echte interne ingang. Dit beïnvloedt alleen die ene aanvraag en is geen DNS-inrichting. Voeg -k niet toe om een identiteitsfout in een schijnbare doorgang te veranderen, want een certificaatafwijking is het signaal dat u de verkeerde listener raakt.
Het numerieke adres rechtstreeks opvragen kan de verkeerde virtuele host kiezen of de validatie laten mislukken terwijl TCP 443 antwoordt, dus behandel een geslaagde IP-test als bewijs over het netwerk en niets meer. Vanaf de bedoelde laptop is het normale resolverpad de DNS-doorstuurder van de client of het inkomende eindpunt van de privé-resolver die de zone host, en een fout daar is een bereikbaarheidsprobleem van de resolver, niet een ontbrekend record. Bevestig dat dezelfde aanvraag op dat pad slaagt, en bevestig dan dat het geweigerde publiek nog steeds wordt geweigerd.
Wat u moet vastleggen en wat u moet terugdraaien
De doelpoort van de container en de HTTPS-poort van de client zijn afzonderlijke instellingen. Publiceer de doelpoort van de container niet via de VPN omdat de container daar luistert, en verbreed geen netwerkregel om een poorttest te laten slagen. Beide wijzigingen overleven het incident en zijn later moeilijk toe te schrijven.
Sluit af met een nieuwe applicatiebewerking vanaf de bedoelde laptop, met de geautoriseerde identiteit en de normale DNS, en controleer dan dat een niet-geautoriseerde aanroeper nog steeds faalt. Terwijl u in de app-configuratie bent, bevestig ook of een HTTP-route op omgevingsniveau deze app als doel ontsluit, want die route is een tweede deur die de ingress-scope niet beschrijft.
Noteer vijf waarden samen: scope van de omgeving, ingress-scope van de app, FQDN, privé-ingangsadres en eigenaar van de resolver. Die vijf beschrijven het hele toegangscontract, en de volgende persoon die dit moet debuggen, zal precies die vragen.