Bereik 'n private Container Apps-app oor punt-tot-werf-VPN
'n Interne Container Apps-omgewing het 'n private toegang, 'n ooreenstemmende hostnaam en 'n resolver nodig wat die VPN kan bereik. Voer elke stap uit en verifieer dan die weiering.
Hierdie draaiboek dek 'n Container Apps-omgewing met werklasprofiele en 'n interne virtuele-netwerktoegang, wat van 'n skootrekenaar oor 'n goedgekeurde punt-tot-werf-VPN bereik word, met die app se direkte FQDN en geen HTTP-roetes op omgewingsvlak nie. die omgewingstoegang is vanaf die kliënt bereikbaar, die app se ingress-omvang laat die oproeper toe, en die hostnaam wys na die private toegang. Elke stap hieronder lewer 'n verifieerbare resultaat en 'n terugrol wat niks raak wat jy nie verander het nie. Werk dit in die gegewe volgorde deur, want geen latere stap kan 'n omvangbesluit wat in stap 1 verkeerd gemaak is, vergoed nie.
Voordat jy aan DNS raak, moet jy die woord intern vasstel. Dit word vir twee verskillende omvange in hierdie produk gebruik, en om hulle te verwissel is die algemeenste rede waarom 'n werkende naam steeds niks nuttigs teruggee nie.
Stap 1: bepaal die omgewing se en die app se omvang
Lees die app se ingress-konfigurasie voordat jy enige rekord verander:
| 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 word op die omgewing se interne lasbalanseerder binne die omgewing se VNet blootgestel, so die vraag is nie of die skootrekenaar nog 'n container-app is nie, maar of dit daardie VNet kan bereik. 'n VPN-kliënt met 'n roete na die VNet en die omgewing se standaarddomein wat deur die private sone oplos, is 'n geskikte oproeper, en dit is wat die oorblywende stappe bou. 'n Interne omgewing sonder 'n openbare toegang is 'n ander feit as 'n app met interne ingress, en eksterne ingress op app-vlak gee nie vir die omgewing 'n openbare deur nie. Skryf die omvang in die kaartjie sowel as in die portaal, want die volgende ingenieur lees eerste die kaartjie.
Bevestig daardie omvang by die konfigurasie-eienaar voordat jy voortgaan, en hou die hek smal: as daar geen roete na die omgewing se VNet bestaan nie, of die omgewing se standaarddomein nie deur die private sone oplos nie, stop en maak eers daardie pad reg. Geen latere stap kan 'n oproeper vervang wat nie die VNet kan bereik of die naam kan oplos nie.
Stap 2: versamel die werklike hostnaam en toegangsadres
Teken die omgewing se standaarddomein, sy statiese private toegangsadres en die app se gekonfigureerde FQDN aan, en neem dit uit die hulpbron eerder as uit 'n ou skermskoot of 'n wiki-bladsy:
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"Die riglyne vir private toegang tot Container Apps beskryf hoe om die omgewing se domein by sy interne adres te pas terwyl die toepassing se hostname ongeskonde bly. Dit is presies die vorm wat jy hier met die hand bou, so pas die sone se inhoud daarby aan in plaas daarvan om 'n nuwe naamskema te bedink.
As die domein wat jy lees nie ooreenstem met die FQDN wat die app rapporteer nie, stop en versoen hulle nou. 'n Sone teen die verkeerde agtervoegsel bou lewer 'n hostnaam wat volmaak oplos en steeds op die verkeerde virtuele gasheer beland.
Stap 3: plaas die private sone op die VPN se resolver-pad
Skep of hergebruik die ondersteunde private DNS-sone vir die omgewing se werklike standaarddomein, met die gedokumenteerde wildcard- en adresrekords wat na die statiese toegang wys. Koppel daardie sone aan die toepaslike virtuele netwerk, en maak die private gesag bereikbaar deur die VPN se goedgekeurde resolver-pad eerder as om te aanvaar die skakel is genoeg.
'n Punt-tot-werf-kliënt benodig gewoonlik 'n inkomende eindpunt vir 'n private resolver of 'n ondersteunde DNS-aanstuurder om daardie sone te bereik. Om 'n sone te koppel verander wat Azure vir gekoppelde netwerke oplos; dit herlei nie elke eksterne skootrekenaar se openbare resolver nie. Moenie 'n private-eindpunt-DNS-sone van 'n ander Container Apps-netwerkmodel leen nie, want die rekordname en die sone-agtervoegsel sal nie pas nie.
Die terugrol vir hierdie stap is om die sone-skakel of die rekord wat jy bygevoeg het te verwyder. Hou aan om te onthou watter een dit was, want om 'n gedeelde sone te skrap om 'n enkele skakel ongedaan te maak, is 'n bekende manier om 'n tweede omgewing te breek.
Stap 4: toets die naam, dan die geweierde gehoor
Toets die hostnaam en TLS-identiteit saam, nie net die adres nie. Vir 'n beheerde naamtokenningsdiagnose kan jy die adres vaspen terwyl jy die hostnaam behou:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Vervang die hostnaam met die werklike app-FQDN en die adres met die werklike interne toegang. Dit raak daardie een versoek en is nie DNS-voorsiening nie. Moenie -k byvoeg om 'n identiteitsfout in 'n skynbare slaag te verander nie, want 'n sertifikaatwanpassing is die teken dat jy die verkeerde luisteraar tref.
Om die numeriese adres direk te versoek, kan die verkeerde virtuele gasheer kies of validasie laat misluk selfs terwyl TCP 443 antwoord, so beskou 'n geslaagde IP-toets as bewyse oor die netwerk en niks meer nie. Vanaf die bedoelde skootrekenaar is die normale resolver-pad die kliënt se DNS-aanstuurder of die inkomende eindpunt van die private resolver wat die sone huisves, en 'n fout daar is 'n probleem met resolver-bereikbaarheid eerder as 'n ontbrekende rekord. Bevestig dat dieselfde versoek op daardie pad slaag, en bevestig dan dat die geweierde gehoor steeds geweier word.
Wat om aan te teken, en wat om terug te rol
Die container se teikenpoort en die kliënt se HTTPS-poort is afsonderlike instellings. Moenie die container se teikenpoort oor die VPN publiseer omdat die container daar luister nie, en moenie 'n netwerk-reël verbreed om 'n poorttoets te laat slaag nie. Albei veranderinge oorleef die voorval en is later moeilik om toe te skryf.
Eindig met 'n vars toepassingsbewerking vanaf die bedoelde skootrekenaar, met sy gemagtigde identiteit en sy normale DNS, en kyk dan of 'n ongemagtigde oproeper steeds misluk. Terwyl jy in die app-konfigurasie is, bevestig ook of 'n HTTP-roete op omgewingsvlak hierdie app as 'n teiken blootstel, want daardie roete is 'n tweede deur wat die ingress-omvang nie beskryf nie.
Teken vyf waardes saam aan: omgewing se omvang, app se ingress-omvang, FQDN, private toegangsadres en resolver-eienaar. Daardie vyf beskryf die hele toegangskontrak, en die volgende persoon wat dit ontfout, sal presies daarvoor vra.