Piekļūt privātai Container Apps lietotnei caur VPN no punkta uz vietu

Šī rokasgrāmata aptver Container Apps vidi ar darba slodzes profiliem un iekšēju virtuālā tīkla ieeju, kas sasniedzama no klēpjdatora caur apstiprinātu VPN no punkta uz vietu, izmantojot lietotnes tiešo FQDN un bez HTTP maršrutiem vides līmenī. vides ieeja ir sasniedzama no klienta, lietotnes ieejas apjoms pieņem izsaucēju, un resursdatora nosaukums tiek atrisināts uz privāto ieeju. Katrs solis zemāk atstāj pārbaudāmu rezultātu un atritināšanu, kas neaizskar neko, ko jūs neesat mainījis. Veiciet tos norādītajā secībā, jo neviens vēlāks solis nevar kompensēt 1. solī nepareizi pieņemtu apjoma lēmumu.

Pirms aiztiekat DNS, noskaidrojiet vārdu iekšējs. Šajā produktā tas tiek lietots diviem dažādiem apjomiem, un to sajaukšana ir visizplatītākais iemesls, kāpēc strādājošs nosaukums joprojām neatgriež neko lietderīgu.

1. solis: noteikt vides un lietotnes apjomu

Pirms maināt jebkuru ierakstu, izlasiet lietotnes ieejas konfigurāciju:

Iekšējā ieeja tiek atklāta vides iekšējā slodzes līdzsvarotājā vides VNet iekšienē, tāpēc jautājums nav par to, vai klēpjdators ir vēl viena konteineru lietotne, bet gan par to, vai tas var sasniegt šo VNet. VPN klients ar maršrutu uz VNet un vides noklusējuma domēnu, kas atrisināts caur privāto zonu, ir piemērots izsaucējs, un tieši to būvē pārējie soļi. Iekšēja vide bez publiskas ieejas ir cits fakts nekā lietotne ar iekšēju ieeju, un ārēja ieeja lietotnes līmenī nepiešķir videi publiskas durvis. Pierakstiet apjomu gan biļetē, gan portālā, jo nākamais inženieris vispirms lasa biļeti.

Pirms turpināt, apstipriniet šo apjomu ar konfigurācijas īpašnieku un turiet vārtus šaurus: ja nav maršruta uz vides VNet vai vides noklusējuma domēns netiek atrisināts caur privāto zonu, apstājieties un vispirms salabojiet šo ceļu. Neviens vēlāks solis nevar aizstāt izsaucēju, kas nevar sasniegt VNet vai atrisināt nosaukumu.

2. solis: savākt īsto resursdatora nosaukumu un ieejas adresi

Pierakstiet vides noklusējuma domēnu, tā statisko privāto ieejas adresi un lietotnes konfigurēto FQDN, ņemot tos no resursa, nevis no veca ekrānuzņēmuma vai wiki lapas:

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"

Container Apps privātās ieejas norādījumi apraksta vides domēna saskaņošanu ar tā iekšējo adresi, saglabājot lietotnes resursdatora nosaukumus neskartus. Tieši šo formu jūs šeit veidojat ar roku, tāpēc saskaņojiet zonas saturu ar to, nevis izgudrojiet jaunu nosaukumu shēmu.

Ja nolasītais domēns neatbilst FQDN, ko ziņo lietotne, apstājieties un tagad tos saskaņojiet. Zonas veidošana uz nepareiza sufiksācijas rada resursdatora nosaukumu, kas lieliski atrisinās un tomēr nonāk nepareizajā virtuālajā resursdatorā.

3. solis: ievietot privāto zonu VPN atrisinātāja ceļā

Izveidojiet vai atkalizmantojiet atbalstīto privāto DNS zonu vides faktiskajam noklusējuma domēnam, ar dokumentētajiem aizstājējzīmes un adreses ierakstiem, kas norāda uz statisko ieeju. Saistiet šo zonu ar atbilstošo virtuālo tīklu un padariet privāto autoritāti sasniedzamu caur apstiprināto VPN atrisinātāja ceļu, nevis pieņemot, ka saite ir pietiekama.

No punkta uz vietu klientam parasti nepieciešams privāta atrisinātāja ienākošais galapunkts vai atbalstīts DNS pārsūtītājs, lai sasniegtu šo zonu. Zonas saistīšana maina to, ko Azure atrisina saistītajiem tīkliem; tā nepievērš katra ārēja klēpjdatora publisko atrisinātāju. Neaizstājiet to ar privāta galapunkta DNS zonu, kas aizgūta no cita Container Apps tīkla modeļa, jo ierakstu nosaukumi un zonas sufikss nesakritīs.

Šī soļa atritināšana ir zonas saites vai pievienotā ieraksta noņemšana. Pierakstiet, kurš no abiem tas bija, jo kopīgas zonas dzēšana, lai atceltu vienu saiti, ir labi zināms veids, kā salauzt otru vidi.

4. solis: pārbaudīt nosaukumu, pēc tam atteikto auditoriju

Pārbaudiet resursdatora nosaukumu un TLS identitāti kopā, nevis tikai adresi. Kontrolētai nosaukumu kartēšanas diagnostikai varat piespraust adresi, saglabājot resursdatora nosaukumu:

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

Aizstājiet resursdatora nosaukumu ar īsto lietotnes FQDN un adresi ar īsto iekšējo ieeju. Tas ietekmē tikai šo vienu pieprasījumu un nav DNS nodrošināšana. Nepievienojiet -k, lai identitātes kļūdu pārvērstu šķietamā izpildē, jo sertifikāta neatbilstība ir signāls, ka jūs trāpāt nepareizajam klausītājam.

Tieša skaitliskās adreses pieprasīšana var izvēlēties nepareizo virtuālo resursdatoru vai neizdot validāciju pat tad, kad TCP 443 atbild, tāpēc uzskatiet veiksmīgu IP testu par pierādījumu par tīklu un neko vairāk. No paredzētā klēpjdatora parastais atrisinātāja ceļš ir klienta DNS pārsūtītājs vai zonu mitinātāja privātā atrisinātāja ienākošais galapunkts, un kļūda tur ir atrisinātāja sasniedzamības problēma, nevis trūkstošs ieraksts. Apstipriniet, ka tas pats pieprasījums šajā ceļā izdodas, pēc tam apstipriniet, ka atteiktā auditorija joprojām ir atteikta.

Ko pierakstīt un ko atritināt

Konteinera mērķa ports un klienta HTTPS ports ir atsevišķi iestatījumi. Nepublicējiet konteinera mērķa portu caur VPN tāpēc, ka konteiners tur klausās, un nepaplašiniet tīkla noteikumu, lai porta tests izietu. Abas izmaiņas pārdzīvo incidentu, un vēlāk tās ir grūti attiecināt.

Pabeidziet ar svaigu lietotnes darbību no paredzētā klēpjdatora, izmantojot tā autorizēto identitāti un parasto DNS, pēc tam pārbaudiet, ka neautorizēts izsaucējs joprojām neizdodas. Kamēr esat lietotnes konfigurācijā, apstipriniet arī, vai vides līmeņa HTTP maršruts atklāj šo lietotni kā mērķi, jo šis maršruts ir otrās durvis, ko ieejas apjoms neapraksta.

Pierakstiet piecas vērtības kopā: vides apjomu, lietotnes ieejas apjomu, FQDN, privāto ieejas adresi un atrisinātāja īpašnieku. Šīs piecas apraksta visu piekļuves līgumu, un nākamais cilvēks, kas to atkļūdos, prasīs tieši tās.