Aliri privatan aplikaĵon de Container Apps per VPN de punkto al loko

Ĉi tiu gvidlibro pritraktas medion de Container Apps kun laborkvantaj profiloj kaj internan eniron en virtuala reto, atingeblan de tekkomputilo per aprobita VPN de punkto al loko, uzante la rektan FQDN de la aplikaĵo kaj sen HTTP-itineroj sur la media nivelo. la media eniro estas atingebla de la kliento, la enira amplekso de la aplikaĵo akceptas la alvokanton, kaj la gastigantnomo solviĝas al la privata eniro. Ĉiu paŝo sube lasas kontrolan rezulton kaj malfaron, kiu tuŝas nenion, kion vi ne ŝanĝis. Trapasu ilin en la donita ordo, ĉar neniu posta paŝo povas kompensi ampleksan decidon faritan malĝuste en paŝo 1.

Antaŭ ol tuŝi DNS, klarigu la vorton interna. Ĝi estas uzata por du malsamaj ampleksoj en ĉi tiu produkto, kaj ilia interŝanĝo estas la plej ofta kialo, ke funkcianta nomo ankoraŭ redonas nenion utilan.

Paŝo 1: fiksu la amplekson de la medio kaj la aplikaĵo

Legu la eniran agordon de la aplikaĵo antaŭ ol ŝanĝi ajnan rikordon:

Interna eniro estas elmontrita sur la interna ŝarĝo-balancilo de la medio ene de la VNet de la medio, do la demando ne estas, ĉu la tekkomputilo estas alia uja aplikaĵo, sed ĉu ĝi povas atingi tiun VNet. VPN-kliento kun itinero en la VNet kaj la defaŭlta domajno de la medio solviĝanta tra la privata zono estas valida alvokanto, kaj ĝuste tion konstruas la ceteraj paŝoj. Interna medio sen publika eniro estas alia fakto ol aplikaĵo kun interna eniro, kaj ekstera eniro sur la aplikaĵa nivelo ne donas al la medio publikan pordon. Skribu la amplekson en la bileton kaj ankaŭ en la portalon, ĉar la sekva inĝeniero legas unue la bileton.

Konfirmu tiun amplekson kun la agorda posedanto antaŭ ol daŭrigi, kaj tenu la pordon mallarĝa: se ne ekzistas itinero en la VNet de la medio, aŭ la defaŭlta domajno de la medio ne solviĝas tra la privata zono, haltu kaj unue riparu tiun vojon. Neniu posta paŝo povas anstataŭi alvokanton, kiu ne povas atingi la VNet aŭ solvi la nomon.

Paŝo 2: kolektu la realan gastigantnomon kaj la eniran adreson

Notu la defaŭltan domajnon de la medio, ĝian senŝanĝan privatan eniran adreson kaj la agorditan FQDN de la aplikaĵo, prenitajn el la resurso kaj ne el malnova ekrankopio aŭ vikia paĝo:

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"

La gvidilo pri privata eniro de Container Apps priskribas kongruigon de la domajno de la medio kun ĝia interna adreso, konservante la gastigantnomojn de la aplikaĵo sendifektaj. Ĝuste tiun formon vi konstruas mane ĉi tie, do agordu la enhavon de la zono al ĝi anstataŭ elpensi novan nomigan skemon.

Se la domajno, kiun vi legis, ne kongruas kun la FQDN, kiun la aplikaĵo raportas, haltu kaj interkongruigu ilin nun. Konstrui zonon sur la malĝusta sufikso produktas gastigantnomon, kiu perfekte solviĝas kaj tamen surteriĝas sur la malĝustan virtualan gastiganton.

Paŝo 3: metu la privatan zonon sur la solvilan vojon de la VPN

Kreu aŭ reuzu la subtenatan privatan DNS-zonon por la fakta defaŭlta domajno de la medio, kun la dokumentitaj ĵokeraj kaj adresaj rikordoj montrantaj al la senŝanĝa eniro. Ligu tiun zonon al la taŭga virtuala reto, kaj faru la privatan aŭtoritaton atingebla tra la aprobita solvila vojo de la VPN anstataŭ supozi, ke la ligo sufiĉas.

Kliento de punkto al loko kutime bezonas eniran finpunkton de privata solvilo aŭ subtenatan DNS-plusendilon por atingi tiun zonon. Ligi zonon ŝanĝas tion, kion Azure solvas por ligitaj retoj; ĝi ne redirektas la publikan solvilon de ĉiu ekstera tekkomputilo. Ne anstataŭigu per DNS-zono de privata finpunkto pruntita el alia reta modelo de Container Apps, ĉar la rikordaj nomoj kaj la zona sufikso ne kongruos.

La malfaro por ĉi tiu paŝo estas forigi la zonan ligon aŭ la rikordon, kiun vi aldonis. Notu, kiu el la du ĝi estis, ĉar forigi komunan zonon por malfari unu solan ligon estas konata maniero rompi duan medion.

Paŝo 4: testu la nomon, poste la rifuzitan publikon

Testu la gastigantnomon kaj la TLS-identecon kune, ne nur la adreson. Por kontrolita diagnozo de nommapado vi povas fiksi la adreson konservante la gastigantnomon:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

Anstataŭigu la gastigantnomon per la reala FQDN de la aplikaĵo kaj la adreson per la reala interna eniro. Ĉi tio efikas nur al tiu unu peto kaj ne estas DNS-provizado. Ne aldonu -k por ŝanĝi identecan malsukceson en ŝajnan sukceson, ĉar certifikata malkongruo estas la signalo, ke vi trafas la malĝustan aŭskultanton.

Peto de la numera adreso rekte povas elekti la malĝustan virtualan gastiganton aŭ malsukcesigi validigon eĉ dum TCP 443 respondas, do traktu sukcesan IP-teston kiel pruvon pri la reto kaj nenion pli. De la celata tekkomputilo, la normala solvila vojo estas la DNS-plusendilo de la kliento aŭ la enira finpunkto de la privata solvilo, kiu gastigas la zonon, kaj malsukceso tie estas problemo de atingeblo de la solvilo, ne mankanta rikordo. Konfirmu, ke la sama peto sukcesas sur tiu vojo, poste konfirmu, ke la rifuzita publiko ankoraŭ estas rifuzata.

Kion noti kaj kion malfari

La cela pordo de la ujo kaj la HTTPS-pordo de la kliento estas apartaj agordoj. Ne publikigu la celan pordon de la ujo tra la VPN ĉar la ujo aŭskultas tie, kaj ne larĝigu retan regulon por igi pordan teston sukcesi. Ambaŭ ŝanĝoj postvivas la incidenton kaj estas malfacile atribueblaj poste.

Finu per freŝa aplikaĵa operacio de la celata tekkomputilo, uzante ĝian rajtigitan identecon kaj ĝian normalan DNS, poste kontrolu, ke nerajtigita alvokanto ankoraŭ malsukcesas. Dum vi estas en la aplikaĵa agordo, ankaŭ konfirmu, ĉu HTTP-itinero sur la media nivelo elmontras ĉi tiun aplikaĵon kiel celon, ĉar tiu itinero estas dua pordo, kiun la enira amplekso ne priskribas.

Notu kvin valorojn kune: amplekso de la medio, enira amplekso de la aplikaĵo, FQDN, privata enira adreso kaj posedanto de la solvilo. Tiuj kvin priskribas la tutan alirinterkonsenton, kaj la sekva persono, kiu sencimigos ĝin, petos ĝuste ilin.