Maabot ang isang pribadong Container Apps app sa pamamagitan ng point-to-site VPN
Ang panloob na Container Apps environment ay nangangailangan ng pribadong pasukan, tugmang hostname at resolver na maaabot ng VPN. Patakbuhin ang bawat hakbang, pagkatapos i-verify ang pagtanggi.
Saklaw ng gabay na ito ang isang Container Apps environment na may workload profile at panloob na pasukan sa virtual network, na naaabot mula sa laptop sa pamamagitan ng inaprubahang point-to-site VPN, gamit ang direktang FQDN ng app at walang HTTP route sa antas ng environment. naaabot ang pasukan ng environment mula sa client, tinatanggap ng ingress scope ng app ang tumatawag, at nare-resolve ang hostname sa pribadong pasukan. Bawat hakbang sa ibaba ay nag-iiwan ng na-verify na resulta at rollback na hindi ginagalaw ang anumang hindi mo binago. Gawin ang mga ito sa ibinigay na pagkakasunod-sunod, dahil walang susunod na hakbang ang makakabawi sa desisyon sa scope na nagawa nang mali sa hakbang 1.
Bago hawakan ang DNS, linawin ang salitang panloob. Ginagamit ito para sa dalawang magkaibang scope sa produktong ito, at ang pagpapalit sa mga ito ang pinakakaraniwang dahilan kung bakit ang gumaganang pangalan ay hindi pa rin nagbabalik ng anumang kapaki-pakinabang.
Hakbang 1: itakda ang scope ng environment at app
Basahin ang ingress configuration ng app bago baguhin ang anumang record:
| 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 |
Ang panloob na ingress ay nakalantad sa panloob na load balancer ng environment sa loob ng VNet ng environment, kaya ang tanong ay hindi kung ang laptop ay isa pang container app, kundi kung maaabot nito ang VNet na iyon. Ang VPN client na may ruta papasok sa VNet at ang default domain ng environment na nare-resolve sa pamamagitan ng pribadong zone ay karapat-dapat na tumatawag, at iyon ang eksaktong itinatayo ng natitirang hakbang. Ang panloob na environment na walang pampublikong pasukan ay ibang katotohanan kaysa app na may panloob na ingress, at ang panlabas na ingress sa antas ng app ay hindi nagbibigay sa environment ng pampublikong pinto. Isulat ang scope sa ticket at gayundin sa portal, dahil unang binabasa ng susunod na inhinyero ang ticket.
Kumpirmahin ang scope na iyon sa may-ari ng configuration bago magpatuloy, at panatilihing makitid ang gate: kung walang ruta papasok sa VNet ng environment, o hindi nare-resolve ang default domain ng environment sa pamamagitan ng pribadong zone, huminto at ayusin muna ang rutang iyon. Walang susunod na hakbang ang makapapalit sa tumatawag na hindi maaabot ang VNet o ma-resolve ang pangalan.
Hakbang 2: kolektahin ang tunay na hostname at address ng pasukan
Itala ang default domain ng environment, ang static na pribadong address ng pasukan nito at ang naka-configure na FQDN ng app, na kinuha mula sa resource at hindi mula sa lumang screenshot o wiki page:
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"Inilalarawan ng gabay sa pribadong pasukan ng Container Apps ang pagtutugma ng domain ng environment sa panloob na address nito habang pinapanatiling buo ang mga hostname ng application. Iyon ang eksaktong hugis na ginagawa mo nang manu-mano dito, kaya ihanay ang nilalaman ng zone dito sa halip na mag-imbento ng bagong scheme ng pangalan.
Kung ang domain na nabasa mo ay hindi tugma sa FQDN na iniuulat ng app, huminto at pagkasyahin ang mga ito ngayon. Ang pagbuo ng zone sa maling suffix ay gumagawa ng hostname na perpektong nare-resolve at gayunpaman ay napupunta sa maling virtual host.
Hakbang 3: ilagay ang pribadong zone sa ruta ng resolver ng VPN
Gumawa o gumamit muli ng sinusuportahang pribadong DNS zone para sa aktwal na default domain ng environment, na ang mga dokumentadong wildcard at address record ay tumuturo sa static na pasukan. I-link ang zone na iyon sa naaangkop na virtual network, at gawing naaabot ang pribadong awtoridad sa pamamagitan ng inaprubahang ruta ng resolver ng VPN sa halip na ipagpalagay na sapat na ang link.
Ang point-to-site client ay karaniwang nangangailangan ng inbound endpoint ng pribadong resolver o sinusuportahang DNS forwarder para maabot ang zone na iyon. Ang pag-link ng zone ay nagbabago sa nire-resolve ng Azure para sa mga naka-link na network; hindi nito nire-redirect ang pampublikong resolver ng bawat panlabas na laptop. Huwag itong palitan ng DNS zone ng pribadong endpoint na hiniram mula sa ibang Container Apps networking model, dahil hindi magtutugma ang mga pangalan ng record at ang suffix ng zone.
Ang rollback para sa hakbang na ito ay ang pag-alis ng link ng zone o ng record na idinagdag mo. Itala kung alin sa dalawa iyon, dahil ang pagbura ng shared zone para i-undo ang isang link ay kilalang paraan ng pagsira sa pangalawang environment.
Hakbang 4: subukan ang pangalan, pagkatapos ang tinanggihang audience
Subukan ang hostname at TLS identity nang magkasama, hindi lamang ang address. Para sa kontroladong diagnostic ng name mapping maaari mong i-pin ang address habang pinapanatili ang hostname:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Palitan ang hostname ng tunay na FQDN ng app at ang address ng tunay na panloob na pasukan. Apektado lamang nito ang isang kahilingang iyon at hindi ito DNS provisioning. Huwag idagdag ang -k para gawing maliwanag na pagpasa ang pagkabigo ng identity, dahil ang hindi pagtutugma ng certificate ay ang hudyat na tinatamaan mo ang maling listener.
Ang direktang paghingi ng numeric address ay maaaring pumili ng maling virtual host o mabigo ang validation kahit na sumasagot ang TCP 443, kaya ituring ang matagumpay na IP test bilang ebidensya tungkol sa network at wala nang iba pa. Mula sa inilaan na laptop, ang normal na ruta ng resolver ay ang DNS forwarder ng client o ang inbound endpoint ng pribadong resolver na nagho-host ng zone, at ang pagkabigo doon ay problema sa maabot ng resolver, hindi nawawalang record. Kumpirmahin na nagtagumpay ang parehong kahilingan sa rutang iyon, pagkatapos kumpirmahin na ang tinanggihang audience ay tinatanggihan pa rin.
Ano ang itatala at ano ang ibabalik
Ang target port ng container at ang HTTPS port ng client ay magkahiwalay na setting. Huwag ilathala ang target port ng container sa VPN dahil doon nakikinig ang container, at huwag palawakin ang network rule para pumasa ang port test. Pareho ang dalawang pagbabago ay nabubuhay pagkatapos ng insidente at mahirap i-attribute mamaya.
Tapusin sa sariwang operasyon ng application mula sa inilaan na laptop, gamit ang awtorisadong identity at normal na DNS nito, pagkatapos tingnan na nabibigo pa rin ang hindi awtorisadong tumatawag. Habang nasa configuration ng app, kumpirmahin din kung inilalantad ng HTTP route sa antas ng environment ang app na ito bilang target, dahil ang rutang iyon ay pangalawang pinto na hindi inilalarawan ng ingress scope.
Itala ang limang halaga nang magkasama: scope ng environment, ingress scope ng app, FQDN, pribadong address ng pasukan at may-ari ng resolver. Inilalarawan ng limang iyon ang buong kontrata ng access, at ang susunod na taong magde-debug nito ay hihingi ng eksaktong mga iyon.