In privee Container Apps-app berikke fia punt-nei-site-VPN
In ynterne Container Apps-omjouwing hat in privee yngong, in oerienkommende hostnamme en in resolver nedich dy't it VPN berikke kin. Fier elke stap út en ferifiearje dan de wegering.
Dizze hânlieding behannelt in Container Apps-omjouwing mei wurklêstprofylen en in ynterne firtuele-netweryngong, dy't fan in laptop ôf berikt wurdt fia in goedkard punt-nei-site-VPN, mei de direkte FQDN fan 'e app en sûnder HTTP-routes op omjouwingsnivo. de omjouwingsyngong is fan de klant ôf berikber, it ingress-berik fan 'e app lit de opropper ta, en de hostnamme wurdt nei de privee yngong oplost. Elke stap hjirûnder lit in ferifiearber resultaat en in weromrôljen efter dat neat oanrekket dat jo net feroare hawwe. Wurkje se yn 'e opjûne folchoarder ôf, want gjin lettere stap kin in beriksbeslút kompensearje dat yn stap 1 ferkeard nommen is.
Foardat jo DNS oanreitsje, moatte jo it wurd yntern dúdlik meitsje. It wurdt yn dit produkt foar twa ferskillende beriken brûkt, en se trochinoar helje is de meast foarkommende reden dat in wurkjende namme noch altyd neat nuttichs weromjout.
Stap 1: fêstigje it berik fan 'e omjouwing en de app
Lês de ingress-konfiguraasje fan 'e app foardat jo in record feroarje:
| 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 |
Ynterne ingress wurdt bleatsteld op 'e ynterne load balancer fan 'e omjouwing binnen it VNet fan 'e omjouwing, dus de fraach is net oft de laptop in oare containerapp is, mar oft er dat VNet berikke kin. In VPN-klant mei in route yn it VNet en it standertdomein fan 'e omjouwing dat troch de privee sône oplost, is in jildige opropper, en dat is krekt wat de oerbleaune stappen bouwe. In ynterne omjouwing sûnder publike yngong is in oar feit as in app mei ynterne ingress, en eksterne ingress op appnivo jout de omjouwing gjin publike doar. Skriuw it berik yn it ticket en ek yn it portaal, want de folgjende yngenieur lêst earst it ticket.
Befêstigje dat berik mei de konfiguraasje-eigner foardat jo fierder geane, en hâld de poarte smel: as der gjin route yn it VNet fan 'e omjouwing bestiet, of it standertdomein fan 'e omjouwing oplost net troch de privee sône, stopje dan en reparearje earst dat paad. Gjin lettere stap kin in opropper ferfange dy't it VNet net berikke of de namme net oplosse kin.
Stap 2: sammelje de echte hostnamme en it yngongadres
Skriuw it standertdomein fan 'e omjouwing, syn statyske privee yngongadres en de konfigurearre FQDN fan 'e app op, helle út 'e resource en net út in âlde skermprint of in 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"De rjochtline foar privee yngong fan Container Apps beskriuwt it ôfstimmen fan it domein fan 'e omjouwing op syn ynterne adres wylst de hostnammen fan 'e tapassing yntakt bliuwe. Dat is krekt de foarm dy't jo hjir mei de hân bouwe, dus stim it ynhâld fan 'e sône dêrop ôf ynstee fan in nij nammeskema te betinken.
As it domein dat jo lêzen hawwe net oerienkomt mei de FQDN dy't de app rapportearret, stopje dan en ferienigje se no. In sône op 'e ferkearde efterheaksel bouwe jout in hostnamme dy't perfekt oplost en dochs op 'e ferkearde firtuele host lânet.
Stap 3: set de privee sône op it resolverpaad fan it VPN
Meitsje of werbrûk de stipe privee DNS-sône foar it werklike standertdomein fan 'e omjouwing, mei de dokumintearre wildcard- en adresrecords dy't nei de statyske yngong wize. Keppelje dy sône oan it passende firtuele netwurk, en meitsje it privee gesach berikber fia it goedkarde resolverpaad fan it VPN ynstee fan oan te nimmen dat de keppeling genôch is.
In punt-nei-site-klant hat meastentiids in yngeand einpunt fan in privee resolver of in stipe DNS-trochstjoerder nedich om dy sône te berikken. In sône keppelje feroaret wat Azure foar keppele netwurken oplost; it ferwiist net de publike resolver fan elke eksterne laptop troch. Ferfange it net troch in DNS-sône foar privee einpunten liend fan in oar Container Apps-netwurkmodel, want de recordnammen en de sône-efterheaksel sille net oerienkomme.
It weromrôljen foar dizze stap is it fuortheljen fan 'e sônekeppeling of it record dat jo tafoege hawwe. Skriuw op hokker fan beide it wie, want in dielde sône wiskje om ien keppeling werom te draaien is in bekende manier om in twadde omjouwing te brekken.
Stap 4: test de namme, dan it wegere publyk
Test de hostnamme en TLS-identiteit tegearre, net allinnich it adres. Foar in kontrolearre namme-mappingdiagnoaze kinne jo it adres fêstsette wylst jo de hostnamme behâlde:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Ferfange de hostnamme troch de echte FQDN fan 'e app en it adres troch de echte ynterne yngong. Dit beynfloedet allinnich dy iene oanfraach en is gjin DNS-provisjonearring. Foegje -k net ta om in identiteitsfal te feroarjen yn in skynbere slagge, want in sertifikaatôfwiking is it sinjaal dat jo de ferkearde listener treffe.
It numerike adres direkt opfreegje kin de ferkearde firtuele host kieze of falidearring mislearje litte sels wylst TCP 443 antwurdet, dus behannelje in slagge IP-test as bewiis oer it netwurk en net mear. Fan 'e bedoelde laptop is it normale resolverpaad de DNS-trochstjoerder fan 'e klant of it yngeande einpunt fan 'e privee resolver dy't de sône hostet, en in fal dêr is in berikberensprobleem fan 'e resolver, net in ûntbrekkend record. Befêstigje dat deselde oanfraach op dat paad slagget, en befêstigje dan dat it wegere publyk noch altyd wegere wurdt.
Wat te notearjen en wat werom te rôljen
De doelpoarte fan 'e container en de HTTPS-poarte fan 'e klant binne aparte ynstellings. Publisearje de doelpoarte fan 'e container net oer it VPN om't de container dêr harket, en wreidzje in netwurkregel net út om in poartetest te slagjen. Beide feroarings oerlibje it foarfal en binne letter dreech ta te skriuwen.
Einigje mei in frisse tapassingsoperaasje fan 'e bedoelde laptop, mei syn autorisearre identiteit en syn normale DNS, en kontrolearje dan dat in net-autorisearre opropper noch altyd mist. Wylst jo yn 'e app-konfiguraasje binne, befêstigje ek oft in HTTP-route op omjouwingsnivo dizze app as doel bleatstelt, want dy route is in twadde doar dy't it ingress-berik net beskriuwt.
Skriuw fiif wearden tegearre op: berik fan 'e omjouwing, ingress-berik fan 'e app, FQDN, privee yngongadres en resolver-eigner. Dy fiif beskriuwe it hiele tagongsferdrach, en de folgjende persoan dy't it debúgje moat, sil krekt dêrom freegje.