Arritja në një aplikacion privat Container Apps përmes VPN nga pika në vend
Një mjedis i brendshëm Container Apps kërkon një hyrje private, një emër hosti që përputhet dhe një zgjidhës që VPN mund ta arrijë. Ekzekutoni çdo hap, më pas verifikoni refuzimin.
Ky udhëzues mbulon një mjedis Container Apps me profile të ngarkesës së punës dhe një hyrje të brendshme të rrjetit virtual, që arrihet nga një laptop përmes një VPN nga pika në vend të miratuar, duke përdorur FQDN-në e drejtpërdrejtë të aplikacionit dhe pa rrugë HTTP në nivel mjedisi. hyrja e mjedisit është e arritshme nga klienti, shtrirja e hyrjes së aplikacionit e pranon thirrësin, dhe emri i hostit zgjidhet në hyrjen private. Çdo hap më poshtë lë një rezultat të verifikueshëm dhe një kthim pas që nuk prek asgjë që nuk keni ndryshuar. Kaloni nëpër to në rendin e dhënë, sepse asnjë hap i mëvonshëm nuk mund të kompensojë një vendim shtrirjeje të marrë gabimisht në hapin 1.
Përpara se të prekni DNS, sqaroni fjalën e brendshme. Në këtë produkt përdoret për dy shtrirje të ndryshme, dhe zëvendësimi i tyre është arsyeja më e zakonshme pse një emër që funksionon ende nuk kthen asgjë të dobishme.
Hapi 1: caktoni shtrirjen e mjedisit dhe të aplikacionit
Lexoni konfigurimin e hyrjes së aplikacionit përpara se të ndryshoni çdo regjistrim:
| 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 |
Hyrja e brendshme ekspozohet në balancuesin e brendshëm të ngarkesës së mjedisit brenda VNet të mjedisit, prandaj pyetja nuk është nëse laptopi është një aplikacion tjetër kontejneri, por nëse mund të arrijë atë VNet. Një klient VPN me një rrugë në VNet dhe domenin e parazgjedhur të mjedisit që zgjidhet përmes zonës private është një thirrës i pranueshëm, dhe pikërisht këtë ndërtojnë hapat e mbetur. Një mjedis i brendshëm pa hyrje publike është një fakt tjetër sesa një aplikacion me hyrje të brendshme, dhe hyrja e jashtme në nivel aplikacioni nuk i jep mjedisit një derë publike. Shkruani shtrirjen në tiketë dhe gjithashtu në portal, sepse inxhinieri tjetër lexon së pari tiketën.
Konfirmoni atë shtrirje me pronarin e konfigurimit përpara se të vazhdoni, dhe mbani portën të ngushtë: nëse nuk ekziston rrugë në VNet të mjedisit, ose domeni i parazgjedhur i mjedisit nuk zgjidhet përmes zonës private, ndaloni dhe rregulloni së pari atë rrugë. Asnjë hap i mëvonshëm nuk mund të zëvendësojë një thirrës që nuk mund të arrijë VNet ose të zgjidhë emrin.
Hapi 2: mblidhni emrin e vërtetë të hostit dhe adresën e hyrjes
Regjistroni domenin e parazgjedhur të mjedisit, adresën e tij statike private të hyrjes dhe FQDN-në e konfiguruar të aplikacionit, marrë nga burimi dhe jo nga një pamje ekrani e vjetër ose një faqe wiki:
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"Udhëzimet për hyrjen private të Container Apps përshkruajnë përputhjen e domenit të mjedisit me adresën e tij të brendshme, duke i mbajtur të paprekura emrat e hostit të aplikacionit. Pikërisht këtë formë po ndërtoni me dorë këtu, prandaj përshtatni përmbajtjen e zonës me të në vend që të shpikni një skemë të re emërtimi.
Nëse domeni që lexuat nuk përputhet me FQDN-në që raporton aplikacioni, ndaloni dhe pajtojini ato tani. Ndërtimi i një zone mbi prapashtesën e gabuar prodhon një emër hosti që zgjidhet në mënyrë të përsosur dhe gjithsesi përfundon në hostin virtual të gabuar.
Hapi 3: vendosni zonën private në rrugën e zgjidhësit të VPN
Krijoni ose riutilizoni zonën private të DNS të mbështetur për domenin aktual të parazgjedhur të mjedisit, me regjistrimet e dokumentuara të wildcard dhe të adresës që tregojnë drejt hyrjes statike. Lidhni atë zonë me rrjetin virtual të duhur dhe bëni autoritetin privat të arritshëm përmes rrugës së miratuar të zgjidhësit të VPN, në vend që të supozoni se lidhja mjafton.
Një klient nga pika në vend zakonisht ka nevojë për një pikë fundore hyrëse të një zgjidhësi privat ose një përcjellës DNS të mbështetur për të arritur atë zonë. Lidhja e një zone ndryshon atë që Azure zgjidh për rrjetet e lidhura; nuk e ridrejton zgjidhësin publik të çdo laptopi të jashtëm. Mos e zëvendësoni me një zonë DNS të pikës fundore private të huazuar nga një model tjetër rrjeti i Container Apps, sepse emrat e regjistrimeve dhe prapashtesa e zonës nuk do të përputhen.
Kthimi pas për këtë hap është heqja e lidhjes së zonës ose e regjistrimit që shtuat. Shënoni cila nga të dyja ishte, sepse fshirja e një zone të përbashkët për të anuluar një lidhje të vetme është një mënyrë e njohur për të prishur një mjedis të dytë.
Hapi 4: provoni emrin, pastaj publikun e refuzuar
Provoni emrin e hostit dhe identitetin TLS së bashku, jo vetëm adresën. Për një diagnostikim të kontrolluar të hartëzimit të emrave mund ta fiksoni adresën duke ruajtur emrin e hostit:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Zëvendësoni emrin e hostit me FQDN-në e vërtetë të aplikacionit dhe adresën me hyrjen e vërtetë të brendshme. Kjo prek vetëm atë kërkesë të vetme dhe nuk është sigurim DNS. Mos shtoni -k për ta kthyer një dështim identiteti në një kalim të dukshëm, sepse mospërputhja e certifikatës është sinjali se po goditni dëgjuesin e gabuar.
Kërkimi i drejtpërdrejtë i adresës numerike mund të zgjedhë hostin virtual të gabuar ose të dështojë vlefshmërinë edhe kur TCP 443 përgjigjet, prandaj trajtoni një provë IP të suksesshme si provë për rrjetin dhe asgjë më shumë. Nga laptopi i synuar, rruga normale e zgjidhësit është përcjellësi DNS i klientit ose pika fundore hyrëse e zgjidhësit privat që strehon zonën, dhe një dështim atje është problem i arritshmërisë së zgjidhësit, jo një regjistrim që mungon. Konfirmoni se e njëjta kërkesë ka sukses në atë rrugë, më pas konfirmoni se publiku i refuzuar është ende i refuzuar.
Çfarë të regjistrohet dhe çfarë të kthehet pas
Porta e synuar e kontejnerit dhe porta HTTPS e klientit janë cilësime të veçanta. Mos e publikoni portën e synuar të kontejnerit përmes VPN sepse kontejneri dëgjon atje, dhe mos e zgjeroni një rregull rrjeti për të kaluar një provë porte. Të dyja ndryshimet i mbijetojnë incidentit dhe më vonë është e vështirë t'i atribuohen.
Përfundoni me një operacion të ri të aplikacionit nga laptopi i synuar, me identitetin e tij të autorizuar dhe DNS-në e tij normale, më pas kontrolloni që një thirrës i paautorizuar ende dështon. Ndërsa jeni në konfigurimin e aplikacionit, konfirmoni gjithashtu nëse një rrugë HTTP në nivel mjedisi e ekspozon këtë aplikacion si synim, sepse ajo rrugë është dera e dytë që shtrirja e hyrjes nuk e përshkruan.
Regjistroni pesë vlera së bashku: shtrirja e mjedisit, shtrirja e hyrjes së aplikacionit, FQDN, adresa private e hyrjes dhe pronari i zgjidhësit. Ato pesë përshkruajnë të gjithë kontratën e aksesit, dhe personi tjetër që do ta korrigjojë do të kërkojë pikërisht ato.